Re: [Cfrg] new authenticated encryption draft

["Hal Finney" <[e-mail]>]

On 8/18/06, David A. McGrew <[e-mail]> wrote:
> Hello,
>
> I've recently submitted a new Internet Draft pertinent to this group,
> and I'd like to ask for your review.  The pre-publication draft is
> online at http://www.mindspring.com/~dmcgrew/draft-mcgrew-auth-
> enc-00.txt
>
> Authenticated Encryption (draft-mcgrew-auth-enc-00.txt)
>
> Abstract.  This draft defines algorithms for authenticated encryption
> with additional authenticated data (AEAD), and defines a uniform
> interface and a registry for such algorithms. The interface and
> registry can be used as an application independent set of
> cryptoalgorithm suites. This approach provides advantages in
> efficiency and security, and promotes the reuse of crypto
> implementations.

Hi, David - That looks very interesting, but I have a few comments.

As a general philosophical point, I am not sure that the name
"authenticated encryption" accurately defines the security properties
for the lay reader. He may think it means that there is authenticity
that the message came from a particular sender, for example. Recently
I have been involved with some disk encryption work which uses
authenticated encryption. In this context, it only means that the
authenticated data was written to the sector at some time in the past.
It doesn't guarantee that what you read from the disk is what was
written there, when you are reading multiple sectors at once (each of
which has its own tag, and each of which might have been rolled back
differently by an attacker). So I think you might want to say
something in more detail about the security properties this encryption
aims to meet, and perhaps mention some caveats about attacks that are
still possible even with AEAD.

In a lot of ways, I think that AEAD is better thought of simply as
providing confidentiality, and nothing more. The purpose of the
"authentication" is to improve the confidentiality guarantee, by
preventing active attacks like chosen ciphertext. Without it, many of
our encryption modes do not provide confidentiality against a
sufficiently powerful attacker.

Another point is that you say that deterministic AEAD algorithms MUST
take an input which goes into the IV. I am not sure I fully understand
the reason for this requirement, but more to the point, I don't think
it is going to be clear to the layman what he should put into this
input. What security properties must his input meet, in order to use
the underlying abstraction safely? Without this guidance, providing
such an input may even be dangerous.

It is outside the scope of your document, but I have found from my
disk experience that the approach in these algorithms of letting the
AEAD algorithm manage uniqueness of IVs at the "micro scale" while the
caller manages uniqueness at the "macro scale" can actually lead to
very inefficient allocation of IV space. For example, with GCM taking
an external IV contribution of 64 bits, if the caller is encrypting a
lot of short messages in a context where it must be stateless and pass
in a random IV contribution, it can only encrypt 2^32 such messages
under a given key. The seemingly vast IV space is eroded to a very
significant limitation similar to what we had in the old days of DES.

One final comment is regarding your proposal AEAD_AES_128_HMAC_SHA1,
for CBC encryption with HMAC authentication. Basically it looks OK,
but when you do the HMAC you "apply it" to the AAD, IV and ciphertext.
This is ambiguous but it sounds like you might mean to concatenate
these fields and HMAC them. If so, that would be unsafe, because it
could be vulnerable to an attack where the boundaries between these
fields are changed by an attacker. For example, he could create AAD'
as AAD||IV, IV' as the first 16 bytes of ciphertext, and ciphertext'
as the remainder of the ciphertext. This would authenticate OK at the
decryption end but would not produce correct plaintext. So you should
be sure to include some length fields inside the HMAC here to assure
unambiguous parsing.


> Comments welcome.  FYI, I'll be in Santa Barbara next week.

Hey, while you're there you should stop in at the Crypto conference... ;-)

Hal

_______________________________________________
Cfrg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/cfrg