Even if you want to know Internet security basics, it can take a while to learn “the least you need to know.” Here’s a rush overview of Advanced Encryption System 256 (AES256), the most popular unbroken encryption you can use today, summarized for a fast mind meld.
When you use virtual private networks (VPNs), login to modern Active Directory authenticated networks, or just encrypt your files on box.com, the encryption algorithm used is likely to be AES256. The reason is simple: So far as is known, AES256 has not been cracked—although faulty implementations have been successfully attacked, and are under constant crack attempts. The motivation for cracking AES256 is simple: It protects everything from banking transactions, to the classified secrets of many governments, to personal health data in most developed countries.
Why AES256 is Safe
AES256 is a symmetrical encryption algorithm that has become ubiquitous, due to the acceptance of the algorithm by the U.S. and Canadian governments as standards for encrypting transited data and data at rest. Because of the length of the key (256 bits) and the number of hashes (14), it takes a murderously long time for a malware hacker to perform a dictionary attack. Inferences of a stream or stored data won’t likely happen in your lifetime, or in the next hundred lifetimes.
Plus, it’s straightforward for developers to use. Much of the AES256 plumbing has already been done for you in the form of numerous libraries that call this encryption methodology in a way that’s easy to implement. Just don’t lose the keys. If you lose the keys, you lose the data at rest or the conversation completely and irrevocably. It’s that simple.
Advanced Encryption System 256 uses a 256-bit encryption key, which is the same key for both directions of data encrypted. That is, to and from uses the same key, and at-rest written and read uses the same key. There is also an AES128 and not oddly, AES 192 (and more), but these aren’t often implemented; a longer key length is more difficult to crack and therefore a longer key is more desirable.
Hashing data makes it iteratively more difficult to be revealed. More hashing is better. Hashing data 14 times, as done with AES256, used to take up a lot of CPU time, but as systems become faster and with more cores, it’s become transparent in use for at least the client side of notebooks, desktops, tablets, and even smartphones. Servers running multiple instances of the algorithm can be slowed, depending on the duty cycle of transactions and their concurrency.
It’s believed you cannot crack the encryption behind correctly implemented AES256 unless you employ binoculars, have a really good psychic, or you’re measuring keystroke bounces. The algorithm’s implementations and related processes have been cracked, now and again, due to mistakes someone made when using the algorithms incorrectly or by making non-random key seeds. As a race to processing power attacks the algorithm, it’s still impossible to crack within a lifetime without extraordinary (and highly unlikely) processing power. Only the NSA knows in certainty, however, if it’s rationally uncrackable.
This faith in the AES256 encryption results, combined with its many programming libraries and compatible applications implementations, has made it the most popular algorithm of its type. However, while it’s easy to use in the software you write that needs encryption, and it’s tough to crack without unobtainable muscularity, you need to understand how it works and test it before you unleash it on an world that believes you know what you’re doing.
Developing with AES256
Data has two states in the context of encryption: plaintext and ciphertext. Plaintext is what we all start with, be it a packet about to enter a VPN tunnel or a file at rest in a folder or data within a buffer. Ciphertext is plaintext that has been encrypted by an algorithm as a process. Your work product starts as plaintext, and goes to a destination as ciphertext, where it may lay at rest, or be recalled, or acted upon. It becomes plaintext again with the same key, hence the description: symmetrical algorithm.
Your code starts with the buffers, inodes, or just plain data. It is subsequently acted upon by the AES256 encryption libraries associated with your code and underlying language, and at the end of the process, the library’s code ejects a buffer of ciphertext. The same key initially used then returns ciphertext buffers to plaintext for your processing delights.
In many program languages, the encryption/decryption process is a streaming function; or it may be an object with a child as either ciphertext or plaintext products that link to buffers of one or the other data types. Remembering the states is mandatory, because if you allow one to be represented as the other, mayhem ensues. Much data will spill on the floor in the form of error codes, WTFs, and other head-desk failures. The keys are unique, hopefully, to different user streams. Therefore, key management becomes the crux of certificate-based chains of authorities in the traditional scheme of public/private key management (which isn’t covered here as it’s application-specific, and fraught with its own distinctive processes). See TLS and AES256.
There is a performance tax to processing AES256. As the calculations require iterative processing just to get a decrypted tuple from a stream, communicated data processed on-the-fly puts a sometimes noticeable load on slower CPUs and therefore perceived/actual performance.
In the old days of computing, you could expect a 20% or higher CPU load from processing AES256 streams, but that’s not the case with modern consumer gear, including most tablets and smartphones. In any case, programming libraries and OS- and platform-specific aids assist in the decryption processes needed to move data.
Servers are different, however, as they may process many multiple concurrent instances of encryption streams, all having different keys—sometimes thousands of open sessions per server. When streams are used, both sides need the key. When data is at rest, only one side needs the key, as the ciphertext at rest isn’t needed. Servers that simply store data don’t have to know anything about AES; they’re not going to encrypt or decrypt, as that’s a function of the calling application or process.
The burden of processing a stream of bi-directionally encrypted data is sometimes undertaken by CPUs that have AES instructions built-in; both AMD and Intel have server-focused CPUs/processors that manage large workloads of encryption processing essentially on-the-fly. Here, it’s important to choose underlying operating systems and hypervisor families that report the correct availability of AES offloading and processing. Often, the library functions are well-known to compilers, and the compiler checks at runtime to use the processing power of the hardware on which the code is running.
Oracle/Sun’s UltraSparc T2/T2+ CPU also contains AES (and other cipher) processing. Sadly, the support is only for SunOS/Solaris, but it’s possible to do quite a bit of work with libraries that call the UltraSparc processor functions. How either family of CPU makes a server more efficient is difficult to test, however, without products that simulate encrypted transactions and transactional duty cycles. Spirent’s WebAvalance is an example of a real-time operating system frame that can assault implementations to develop profiling for high-transaction-cycle hosts, such as VPN gateways and other high-rate transactional devices.
The code you write to processes ciphers like AES needs to probe the operating system (and/or its hypervisor) to ascertain whether the CPU supports the AES-related libraries for CPU family-specific code. There are, sadly, no guarantees that a CPU can do an arctangent and AES processing in hardware. Some languages just toss the process to the OS, its kernel, a runtime library, or other objects, and get the returned desired stream.
Cross-compiling code for consumer devices may also gain you an advantage if you know the target device’s hardware. Libraries are available for Systems On a Chip (SoCs) co-processors such as those found in residential network gateways, border firewalls, and even specialized cipher gateway systems that do nothing but AES (and often other) algorithm decoding/encoding. Specific SoCs grafted onto ARM processors, as an example, can speed overall operations dramatically if you add libraries at compile time to use the decryption features on SoC device architectures.
However, these gateway devices, including VPN gateways, may have an unknown presence of plaintext in places between gateway devices and internal server hosts. The path between a device and a server host then becomes the crux of potential compliance and policy or regulatory concerns. Unencrypted data can be so easily sniffed and filtered that external encryption offloading devices, while providing a circuit encryption between borders, remits plaintext on internal network wires in some constructions. Those wires can often be tapped by nefarious processes. Policy-driven decisions are organizationally-specific, so prior to passing the framework stage, check both the physical infrastructure and the company’s legal and policy needs.
Don’t Forget the Keys!
Encryption keys for data files, streams, stored objects, and other ciphertext is governed by key storage and management within an application instance or underlying OS framework. Key storage management can be specific to an operating system instance, application instance, or in some cases, language. On the client side, keys can be stored in the Windows Registry, Apple’s Keychain, or in other keychains associated by the authenticated user. If the client becomes unavailable and data is stored elsewhere, the ciphertext data becomes useless. Keystores, therefore, must be available, and not locked in any way. Backups are mandatory.
Oracle/Sun’s Java Cryptography Architecture is one example of a key storage methodology that employs a comparatively simple object class called the KeyStore. It stores keys in an operating system-specific location. Although it uses RSA random initial keys, keys can always be “salted” to thwart pseudo-random key fears.
Summarizing
Data at rest can be preyed upon, but to repeat: So far as we know, AES256 ciphertext is invulnerable to attack when properly implemented.
Some organizations go to comparatively gruesome lengths, and add cipher/algorithms even more iteratively, hashing data in ways that only they can recognize. This has the effect of unnecessarily thwarting decryption, as iterative keys and hashing must be correctly processed to render plaintext. Even though it ought to be unnecessary, some are tempted by zeal to gild the lily that is AES. The popularity of AES256 also given rise to hardware aids that offload some of the load that the algorithm imposes. It’s easier to use than most programmers believe, and extensive support for implementations means that you’ll run into it sooner than later.
And I hope your lunch was great!
See also:
[dfads params='groups=934&limit=1&orderby=random']
[dfads params='groups=937&limit=1&orderby=random']