Re: [Cfrg] new authenticated encryption draft

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

Hi Scott,

thanks for your comments, more inline:

On Aug 23, 2006, at 7:24 PM, Scott Fluhrer wrote:

>
>
>> -----Original Message-----
>> From: David A. McGrew [mailto:[e-mail]]
>> Sent: Monday, August 21, 2006 7:37 PM
>> To: Hal Finney
>> Cc: [e-mail]
>> Subject: Re: [Cfrg] new authenticated encryption draft
>>
>> 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.
>
> I don't entirely agree - AEAD does give you something more than
> confidentiality; it gives the guarantee that the data was encrypted by
> someone who has the key (and with that exact additional data).

In the draft I didn't make the point that authentication helps to  
achieve confidentiality goals - I should have though.  Since most  
users understand confidentiality, but many may not appreciate the  
importance of authentication/integrity, this consideration is worth  
stating.  That's what I'd meant.

> Now, as Hal
> has pointed out, in some scenarios, this can be less than what  
> someone who
> hears "authentication" may expect (and so perhaps "integrity" would  
> be a
> better term).  However, this is something that can be spelled out,  
> rather
> than just letting the user assume that this doesn't provide any  
> sort of
> integrity assurance.

I agree, adding definitions would be the best way to go.

David

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