Applied Systems Programming Implementing a Low-Level Encryption Library
My deep interest in Machine Learning and “AI Engineering” converges with the complex and intriguing world of Systems Programming and Information Security. I mean, Information Security and ML is a perfect fit. Huge amounts of data, needle in a haystack? Sounds like a machine job to me! The human aspect of infosec is what draws me to the highly technical field and has since I was pre-teen. Recently, I’ve found myself increasingly drawn toward Systems Programming explorations and the intricate details of working “close to the metal.” Understanding silicon-based computation at a level that’s only slightly abstracted from Machine Code, which ultimately runs on the operating system, brings me great satisfaction.
Until now, the languages I’ve used have been interpreted and single-threaded. I often describe concurrency (as distinct from multiprocessing and parallelism) using the analogy of ants consuming bread. In a single-threaded language, it’s like having one “worker ant” responsible for retrieving bread, and while this ant is working, it blocks all other ants from doing any work. In Python, the language I’m most familiar with, everything is done sequentially with a single thread. While there are libraries that allow for multiprocessing, even simple logging can block the main thread without careful implementation. Although modern hardware with immense processing power and memory, even in phones, mitigates this issue, there was a time when it mattered greatly. Performance-oriented languages are often written in a systems programming derivative of Python called Cython, based on C, one of the first and arguably most efficient programming languages.
In an era where consumer hardware often boasts CPUs with 20+ cores and incredible memory capacity, relying solely on single-threaded, interpreted languages seems inefficient. One reason Python suffices for most workloads is its use of GPUs (Graphical Processing Units) in Machine Learning, which is where Python has found a strong foothold. However, I won’t delve into GPUs and CUDA as I’m not deeply familiar with the specific hardware architecture that offloads operations to the GPU. An interesting fact, though, is that during the training of foundation models like GPT, GPUs operate at approximately 50% utilization. The reasons behind this are beyond my current recall, but they are easily researchable.
To delve deeper into Systems Programming and Information Security, I decided to implement an encryption library in Rust and build a bitwise audit system to verify the hashing component.
This library is purely experimental, and I harbor no illusions about its novelty or utility. However, it reflects my enduring interest in information security and the clandestine world of statecraft, where espionage and information security are as old as time itself. History’s most famous method for securing data in motion and at rest is the Caesar cipher, where characters are shifted by a fixed index. For example, with an index of 3 (starting from 0), ‘a’ becomes ‘d,’ ‘b’ becomes ‘e,’ and so forth. This is rudimentary compared to modern encryption methods, such as the Signal Protocol, which underpins many modern consumer end-to-end messaging services. In fact, the Signal Protocol is now entering a phase where quantum resistance is critical. While the current use cases for quantum computers are limited, one area where they excel is breaking the encryption techniques currently employed by protocols like Signal, password managers, and banks.
Here is my feature plan for this encryption experiment:
- Theoretical Explorations: I’ll not only delve into the mathematical implementations to the extent of my knowledge but also explore how these concepts translate into code and machine operations. A significant challenge with logic-based encryption is the lack of true randomness—everything a computer does is pseudo-random due to its very architecture. Understanding this deeply would be fascinating.
- Symmetric Encryption: This involves using a key to encrypt data, with the same key being used to decrypt it. It’s similar to how TLS/SSL works to encrypt your web data (via certificates), this technology is what gives you the lock icon on your web browser (soon to be retired!)
- Asymmetric Encryption: Here, a public and private key pair is generated using complex algorithms. I plan to implement RSA using the RSA crate in Rust while exploring how the algorithm works, including its origins and implementation. RSA is one of the oldest digital asymmetric transmission algorithms and involves the use of large prime numbers. It’s a fascinating application of number theory, where multiplying two large prime numbers is easy, but factoring them is exceedingly difficult. In this system, the public key can be widely shared and used to encrypt data, but only the private key can decrypt it.
- Hashing: Hashing is the “trap door” of data security—one-way functions using a sufficiently complex key. These functions are easy to verify when the correct answer is found but require computational work proportional to the complexity of the keys. Bitcoin enthusiasts will be familiar with hashing, as it’s a fundamental component of the cryptocurrency’s security model.
- Bitwise Hash Auditing: To deepen my understanding of low-level systems programming, I plan to implement a bitwise comparison of a hash to its original file to verify its authenticity during authentication. Most commonly, this is done using MD5 hashes as a quick and less computationally expensive operation. This technique is widely used in sensitive environments to verify the authenticity of data downloaded from the internet. Even incredibly small changes at the bit level can lead to substantial differences in hashes, making tampering easy to detect. Bitwise comparison however is immensely inefficient but is a great introduction heading even deeper into the stack.
With this plan in place, I’m excited to start exploring. Systems Programming is particularly relevant as a complement to Machine Learning implementation because, as the use of models becomes ubiquitous and multiple models are used in tandem, the infrastructure connecting these inference pipelines will require robust security measures.
This implementation may be a toy program, but the lessons learned will undoubtedly be applicable in the future. They always are. I’ll report back on my findings, and as always, trust no one—not even me. This is a layman’s interpretation of a critical world full of hardcore mathematicians and nefarious wizards.
— Snyata
Aylex Riom 