RE: [Cfrg] new authenticated encryption draft

["Santosh Chokhani" <[e-mail]>]

" Is SHA1-HMAC FIPS-140 approved as a method for deriving two keys from
a single key?  If FIPS-140 approves SHA1-HMAC but not AES-CMAC for this
purpose, and if FIPS-140 conformance is important, well, I'll confess I
don't have any solution to that."

FIPS 140 does not specifically address derivation of keys from a single
key.  FIPS Pseudo RNG permits use of SHA-1 function and AES ECB for
pseudo randomizing.

-----Original Message-----
From: David Wagner [mailto:[e-mail]] 
Sent: Tuesday, August 29, 2006 1:22 PM
To: [e-mail]
Subject: Re: [Cfrg] new authenticated encryption draft

David McGrew  wrote:
>Making the IV an output rather than an input was a conscious  
>design choice intended to trade some flexibility off for ease of use  
>and security.

Ok.

>The problem that the IV contribution is addressing is the need for  
>CTR-based modes to be useable in a situation in which there are  
>multiple devices doing encryption with a single key.

Ok, makes sense.

>For a deterministic AEAD algorithm, the IV contribution could contain  
>a field that needs to be authenticated, such as an address or some  
>other identifier.

Alternatively, one could tell users to include that field as part of
the AAD.

>It is not always explicitly described, but it is often there.   
>Consider the definition of "Authenticity of AEAD Schemes" in Section  
>6 of "The EAX Mode of Operation", http://www.cs.ucdavis.edu/~rogaway/ 
>papers/eax.pdf.  An adversary that succeeds in getting the  
>verification oracle to return 1 by submitting a query (N, H, CT), in  
>which (N, H, CT) was never submitted as query to the encryption  
>oracle, is committing a forgery.  This is true even if (N', H, CT)  
>was submitted as a query to the encryption oracle, as long as N' != N.

I've been hoist by my own petard!

Yes, it's true.  Here is the distinction I was thinking of.  If the
AEAD scheme is proven to meet the INT-CTXT condition, then yes, I think
you'll be able to count on the authenticity of the IV.  However, if the
AEAD scheme is proven to meet INT-PTXT, then I don't think you'll be
able to count on this.  As you say, EAX was proven to be INT-CTXT.
I don't recall off the top of my head whether the security proofs for
the other AEAD modes in your spec prove INT-CTXT or INT-PTXT.  However,
I can easily imagine future modes being proven INT-PTXT.  INT-PTXT is
not an unreasonable criteria for a mode of operation; it appears to be
perfectly adequate so long as the application never inspects the
ciphertext directly (including the IV).  It seemed to me that your
spec would be more general if it works for any INT-PTXT scheme, but
that would mean that applications should not be examining the IV and
should not be counting on its authenticity.

Alternatively, if you want to require that AEAD modes be proven to
be INT-CTXT before they can be used within your framework, you might
want to mention that, and I think you would then need to go check
the security theorems for CCM, GCM, etc., to make sure that each of
the modes mentioned in your document have been proven to be INT-CTXT
(and not just INT-PTXT).

>It's better to use a definition of an AEAD algorithm that's  
>consistent with IV authentication, since algorithms with that  
>property will be easier to use, even if there are other AEAD  
>definitions and algorithms that don't provide that facility.

Perhaps.  But this might prevent you from using some AEAD algorithm
that doesn't provide IV authentication (e.g., because it is INT-PTXT
but not INT-CTXT) but has other beneficial properties not shared by
its competitors.  It's a defensible choice, but I'm not sure yet
whether it is the optimal choice.

>I personally like this idea, though there is a potential problem for  
>users that want FIPS-140 conformance, in that AFAIK there is no  
>FIPS-140 approved method for deriving an encryption key and a MAC key  
>from a single key using AES.

Well, I would use CMAC for that task.  CMAC is a NIST-approved mode.
If AES is secure, then AES-CMAC is a secure PRF.  And any secure PRF is
perfectly fine for deriving an encryption key and a MAC key.

Is SHA1-HMAC FIPS-140 approved as a method for deriving two keys from
a single key?  If FIPS-140 approves SHA1-HMAC but not AES-CMAC for this
purpose, and if FIPS-140 conformance is important, well, I'll confess I
don't have any solution to that.

>Do you consider it appropriate to use EAX with random IVs?  If so,  
>that might be a better solution than generic composition.  It doesn't  
>address the FIPS-140 issue, of course, but it would be technically  
>appealing.

Sure.  I mean, I don't see why not.  As far as I know, you can use EAX
with random IVs if you want -- you can use it with any kind of IVs,
as long as they don't repeat.  Or did I misunderstand the question?

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

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