Re: [Cfrg] new authenticated encryption draft

["David A. McGrew" <[e-mail]>]

Hi Hal,

On Aug 20, 2006, at 11:47 AM, Hal Finney wrote:

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

That's a great point.

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

You're right, there is not a sufficient motivation for the IV  
contribution, nor advice on what to put in it.   That field is needed  
so that 1) for each fixed key, each distinct invocation of the  
authenticated encryption operation can have a distinct IV value (e.g.  
to ensure distinct counter values), and 2) some of the existing uses  
of CCM and GCM include a fixed value in the l.s.b. of their IV  
values.    I'll need to come up with some text on this.

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

True; I'd expect that in practice an IV contribution could be much  
smaller though.  For RFCs 4106 and 4309, the contribution could be as  
small as 4 and 3 bytes, respectively, leaving 64 bits for the micro- 
scale IV.

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

Good catch!  I lifted the CBC+HMAC definition from an existing spec  
for which the AAD length was fixed, and introduced an error by not  
authenticating the location of the AAD/plaintext boundary.  (I think  
I violated my own advice here too :-)

David

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