Re: [Cfrg] New Version Notification for draft-mcgrew-aead-aes-cbc-hmac-sha2-03.txt

["Paterson, Kenny" <[e-mail]>]

Watson,

Yes, that proof idea should work out.

It’s related to the proof for AES-CCM by Jonsson (this scheme uses CBC-MAC on top of CTR mode; the same issue about avoiding colliding counters/CBC chaining variable crops up there too): http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/ccm-ad1.pdf

Cheers,

Kenny

From: Cfrg [mailto:[e-mail]] On Behalf Of Watson Ladd
Sent: 14 February 2014 15:55
To: David McGrew
Cc: [e-mail]
Subject: Re: [Cfrg] New Version Notification for draft-mcgrew-aead-aes-cbc-hmac-sha2-03.txt



On Fri, Feb 14, 2014 at 3:05 AM, David McGrew <[e-mail]<mailto:[e-mail]>> wrote:
On 02/13/2014 08:44 PM, Watson Ladd wrote:


On Thu, Feb 13, 2014 at 4:49 PM, David McGrew <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

the latest version of this draft is out.  Thanks are due to Jim Schaad and Rob Napier for their feedback on version 02.

The goals of this draft are to provide an authenticated encryption scheme suitable for use in those cases where CBC and HMAC are available, but no dedicated AE schemes are available.   Also, it doesn't require deterministic nonces, which itself is useful in some situations.

It might be nice to add a description of how IVs can be pseudorandomly generated.   It would be especially useful to generate the IV using the same key as used for encryption, with an unpredictable counter, or something like that.   Is anyone aware of a security proof that could be cited for that sort of technique?   I think that some systems would have a much easier time maintaining a counter than they would generating truly random IVs, which is reasonable motivation in my opinion.   Glad to hear other thoughts on this subject.

Doesn't the usual PRF definition give you exactly this?

Yes; the only tricky bit is showing that using the CBC encryption key to generate pseudorandom IVs doesn't affect CBC encryption security.   I'm sure that it can be done securely, but I don't know of a proof of security (for using a single key for both CBC and to generate IVs) that I can point to.

Okay, I didn't realize we needed a single key. Then I think the following proof works, but I don't know how strong the result is. Replace the PRP with a PRF by Bernstein's lemma. Then so long as we've never encrypted a block equal to the counter, life is good. Show this can't happen with more than negligible probability for the ideal PRF. Conclude that an attacker who breaks the scheme turns into one who can distinguish the PRF from an ideal PRF with some loss.

Sincerely,
Watson Ladd

David





David

--


A new version of I-D, draft-mcgrew-aead-aes-cbc-hmac-sha2-03.txt

has been successfully submitted by David McGrew and posted to the

IETF repository.



Name:             draft-mcgrew-aead-aes-cbc-hmac-sha2

Revision:  03

Title:            Authenticated Encryption with AES-CBC and HMAC-SHA

Document date:    2014-02-13

Group:            Individual Submission

Pages:            29

URL:            http://www.ietf.org/internet-drafts/draft-mcgrew-aead-aes-cbc-hmac-sha2-03.txt

Status:         https://datatracker.ietf.org/doc/draft-mcgrew-aead-aes-cbc-hmac-sha2/

Htmlized:       http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-03

Diff:           http://www.ietf.org/rfcdiff?url2=draft-mcgrew-aead-aes-cbc-hmac-sha2-03



Abstract:

   This document specifies algorithms for authenticated encryption with

   associated data (AEAD) that are based on the composition of the

   Advanced Encryption Standard (AES) in the Cipher Block Chaining (CBC)

   mode of operation for encryption, and the HMAC-SHA message

   authentication code (MAC).



   These are randomized encryption algorithms, and thus are suitable for

   use with applications that cannot provide distinct nonces to each

   invocation of the AEAD encrypt operation.












Please note that it may take a couple of minutes from the time of submission

until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.



The IETF Secretariat



.





_______________________________________________
Cfrg mailing list
[e-mail]<mailto:[e-mail]>
http://www.irtf.org/mailman/listinfo/cfrg



--
"Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin




--
"Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin