

AEZ: An Easy-to-Use Authenticated Encryption Scheme - mehrdada
http://www.cs.ucdavis.edu/~rogaway/aez/index.html

======
pbsd
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.

------
akerl_
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.

~~~
mehrdada
Relatively short description of the design goal:

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.

