The AES algorithm is widely used today, whether it’s for encrypting a connection to a website, encrypting data on your hard drive, or storing passwords in your favorite password manager. It has been battle-tested for many decades and is still recommended as one of the most secure algorithms. In this article, I explain how AES encryption works and how the algorithm is implemented.
In this article, I explain how AES encryption works and how the algorithm is implemented.
Now forget you read that and never ever implement that yourself in production situations. Instead rely on hardware implementations and established libraries.
AES is practically impossible to implement without introducing huge side channels. Verification of side channel resistance is a huge issue.
The side channel resistance includes such matters as ensuring that the cypher takes the same amount of time, regardless of the key, but also such super-sneaky insights as the amount of power used to run the cypher, which can be measured from the CPU temperature. Every bit of the cypher that you can be sure of makes it easier to guess the rest. And even if you coded this algorithm in assembly, the CPU will interpret it as microcode and run that, potentially leaving you vulnerable - this is not straightforward stuff.
Like vzq says, implementing this properly is for a cross-disciplinary team of experts in their fields.
Yes, but (there is always a but) it does not apply if you implement off-line encryption. Meaning no on-line service encrypting / decrypting attacker provided data (such as SSL / TLS / HTTPS). Meaning if you are running the cipher on your own computer with your own keys / plaintexts / ciphertexts. There is nobody to snoop time differences or power usage differences when using different key / different ciphertext. Then I would suggest this is fine. The only one who can attack you is yourself. In fact, I implemented AES from scratch in C89 language, this source code is at the same time compatible with C++14 constexpr evaluation mode. I also implemented the Serpent cipher, Serpent was an AES candidate back then when there were no AES and Rijndael was not AES yet. The code is on my GitHub page.
That’s a very good explanation.
Now forget you read that and never ever implement that yourself in production situations. Instead rely on hardware implementations and established libraries.
AES is practically impossible to implement without introducing huge side channels. Verification of side channel resistance is a huge issue.
The author says almost exactly the same thing at the end. Maybe it should have been at the beginning.
The side channel resistance includes such matters as ensuring that the cypher takes the same amount of time, regardless of the key, but also such super-sneaky insights as the amount of power used to run the cypher, which can be measured from the CPU temperature. Every bit of the cypher that you can be sure of makes it easier to guess the rest. And even if you coded this algorithm in assembly, the CPU will interpret it as microcode and run that, potentially leaving you vulnerable - this is not straightforward stuff.
Like vzq says, implementing this properly is for a cross-disciplinary team of experts in their fields.
Yes, but (there is always a but) it does not apply if you implement off-line encryption. Meaning no on-line service encrypting / decrypting attacker provided data (such as SSL / TLS / HTTPS). Meaning if you are running the cipher on your own computer with your own keys / plaintexts / ciphertexts. There is nobody to snoop time differences or power usage differences when using different key / different ciphertext. Then I would suggest this is fine. The only one who can attack you is yourself. In fact, I implemented AES from scratch in C89 language, this source code is at the same time compatible with C++14 constexpr evaluation mode. I also implemented the Serpent cipher, Serpent was an AES candidate back then when there were no AES and Rijndael was not AES yet. The code is on my GitHub page.