There aren't many comments here, so I'll take the liberty of adding a thing or two.
This is a CAESAR submission by Rogaway and friends. It is essentially a construction that uses AES and transforms it into a block cipher of arbitrary size. The authentication comes for free by appending zeroes at the end of the message and checking that they remain zeroes after decryption.
This is a nice scheme for users, since it provides strong misuse guarantees. Repeating nonces won't be catastrophic like in many of the other CAESAR ciphers, and the speed is quite nice (mostly owing to the hardware-accelerated AES-NI instructions). For implementers it's not so nice, as it seems rather complicated (especially if you do not have constant-time hardware AES instructions).
Like the majority of AES-based schemes, security starts to break down once you encrypt around 2^64 blocks with the same key. This is not AES's or AEZ's fault, it's a consequence of AES's small 128-bit block size. As a result, the authors do not recommend encrypting over 4 petabytes of data under the same key.
It would be nice if AEZ was defined in terms of a generic block cipher, but as far as I understand the scheme is quite tied to AES.
Does somebody wanna give the layman's version of why I would use this?
I don't blame the site for this, given that it doesn't appear designed to be read by a layperson, but without some kind of I'm-Not-A-Crypto-Wizard translation it just reads like big-word-bingo to me.
The goal of an encryption scheme is to provide confidentiality. It is important to know that most traditional encryption schemes, like block ciphers in CBC, CTR, OFB modes, do not provide any authenticity, i.e. while you cannot recover the plaintext from a ciphertext, you might be able to feed the decryption algorithm a ciphertext that you crafted, without the decryption algorithm having a means for detecting its lack of authenticity (e.g. flipping a bit in ciphertext generated with CTR mode will result in a flipped bit in decrypted plaintext), and in effect, making the system do things that an adversary wants it to do. In practice, this can often be more dangerous than loss of confidentiality.
In order to add authenticity to an encryption scheme, you would traditionally apply a separate message authentication algorithm to the ciphertext and the initialization vector to generate an authentication tag, which you can then use to verify if the ciphertext was tampered with.
There are many ways this combination can go wrong (and has gone) due to design and implementation mistakes, like sharing the key for the MAC and encryption algorithms, not authenticating the IV, not verifying the tag correctly and exposing yourself to timing attacks, applying the MAC to plaintext, as opposed to the ciphertext, etc.. For this reason, and performance implications, it is desirable to have encryption schemes that also somehow provide authenticity almost "for free", as a natural byproduct of the ciphertext generation. Encryption schemes that achieve that, like OCB, CCM, CWC, and GCM modes, are called Authenticated Encryption.
Most of the regular authenticated encryption schemes rely on passing a unique number when encrypting each message, called nonce or initialization vector. For instance, encrypting more than one message with AES in GCM mode with the same nonce will result in total loss of authenticity, among other things. Therefore, they are not very resistant to accidental misuse, and extreme care should be taken while using them.
AEZ, on the other hand, strives to be a more robust authenticated encryption scheme in the face of nonce reuse (misuse), that is, it will not face a catastrophic loss of security if a nonce is accidentally reused.
3 comments
[ 4.0 ms ] story [ 20.8 ms ] threadThis is a CAESAR submission by Rogaway and friends. It is essentially a construction that uses AES and transforms it into a block cipher of arbitrary size. The authentication comes for free by appending zeroes at the end of the message and checking that they remain zeroes after decryption.
This is a nice scheme for users, since it provides strong misuse guarantees. Repeating nonces won't be catastrophic like in many of the other CAESAR ciphers, and the speed is quite nice (mostly owing to the hardware-accelerated AES-NI instructions). For implementers it's not so nice, as it seems rather complicated (especially if you do not have constant-time hardware AES instructions).
Like the majority of AES-based schemes, security starts to break down once you encrypt around 2^64 blocks with the same key. This is not AES's or AEZ's fault, it's a consequence of AES's small 128-bit block size. As a result, the authors do not recommend encrypting over 4 petabytes of data under the same key.
It would be nice if AEZ was defined in terms of a generic block cipher, but as far as I understand the scheme is quite tied to AES.
I don't blame the site for this, given that it doesn't appear designed to be read by a layperson, but without some kind of I'm-Not-A-Crypto-Wizard translation it just reads like big-word-bingo to me.
The goal of an encryption scheme is to provide confidentiality. It is important to know that most traditional encryption schemes, like block ciphers in CBC, CTR, OFB modes, do not provide any authenticity, i.e. while you cannot recover the plaintext from a ciphertext, you might be able to feed the decryption algorithm a ciphertext that you crafted, without the decryption algorithm having a means for detecting its lack of authenticity (e.g. flipping a bit in ciphertext generated with CTR mode will result in a flipped bit in decrypted plaintext), and in effect, making the system do things that an adversary wants it to do. In practice, this can often be more dangerous than loss of confidentiality.
In order to add authenticity to an encryption scheme, you would traditionally apply a separate message authentication algorithm to the ciphertext and the initialization vector to generate an authentication tag, which you can then use to verify if the ciphertext was tampered with.
There are many ways this combination can go wrong (and has gone) due to design and implementation mistakes, like sharing the key for the MAC and encryption algorithms, not authenticating the IV, not verifying the tag correctly and exposing yourself to timing attacks, applying the MAC to plaintext, as opposed to the ciphertext, etc.. For this reason, and performance implications, it is desirable to have encryption schemes that also somehow provide authenticity almost "for free", as a natural byproduct of the ciphertext generation. Encryption schemes that achieve that, like OCB, CCM, CWC, and GCM modes, are called Authenticated Encryption.
Most of the regular authenticated encryption schemes rely on passing a unique number when encrypting each message, called nonce or initialization vector. For instance, encrypting more than one message with AES in GCM mode with the same nonce will result in total loss of authenticity, among other things. Therefore, they are not very resistant to accidental misuse, and extreme care should be taken while using them.
AEZ, on the other hand, strives to be a more robust authenticated encryption scheme in the face of nonce reuse (misuse), that is, it will not face a catastrophic loss of security if a nonce is accidentally reused.