Sriram Keelveedhi | 9 Oct 22:00 2011

Optimized implementation of EME2

Hi all,


Are there any optimized implementations of EME2? I came across an implementation written by Hal Finney and Shai Hallevi, and another by Brian Gladman. But both of these seem to be reference implementations.

Thanks,

Sriram Keelveedhi
PhD Student
University of California San Diego
_______________________________________________
Cfrg mailing list
Cfrg <at> irtf.org
http://www.irtf.org/mailman/listinfo/cfrg
David McGrew | 11 Oct 13:36 2011
Picon

Universally Composable Security Analysis of OAuth v2.0

Of possible interest: a security analysis of draft-ietf-oauth-v2-20

http://eprint.iacr.org/2011/526
David McGrew | 31 Oct 16:28 2011
Picon

New Version Notification for draft-mcgrew-iv-gen-01.txt

Hi,

an updated version of the draft just went in.  It has text to address  
some comments from reviewers; there is a diff below with the new text.

regards,

David

Begin forwarded message:

>
> A new version of I-D, draft-mcgrew-iv-gen-01.txt has been  
> successfully submitted by David McGrew and posted to the IETF  
> repository.
>
> Filename:	 draft-mcgrew-iv-gen
> Revision:	 01
> Title:		 Generation of Deterministic Initialization Vectors (IVs)  
> and Nonces
> Creation date:	 2011-10-31
> WG ID:		 Individual Submission
> Number of pages: 25
>
> Abstract:
>   Many cryptographic algorithms use deterministic IVs, including CTR,
>   GCM, CCM, GMAC.  This type of IV is also called a (deterministic)
>   nonce.  Deterministic IVs must be distinct, for each fixed key, to
>   guarantee the security of the algorithm.  This note describes best
>   practices for the generation of such IVs, and summarizes how they  
> are
>   generated and used in different protocols.  Some problem areas are
>   highlighted, and test considerations are outlined.  This note will  
> be
>   useful to implementers of algorithms using deterministic IVs, and to
>   protocol or system designers using them.
>

< Internet-Draft         Deterministic IV Generation             July  
2011
---
 > Internet-Draft         Deterministic IV Generation          October  
2011
343,345c343,345
<    [RFC4106], TLS [RFC5288], SSH [RFC5647], and SRTP .  The way that
<    these protocols define their IVs is outlined in this section and is
<    summarized in Table 1.
---
 >    [RFC4106], TLS [RFC5288], SSH [RFC5647], and SRTP [RFC3711].   
The way
 >    that these protocols define their IVs is outlined in this  
section and
 >    is summarized in Table 1.

 >    The partially implicit format can save on bandwidth or data  
storage
 >    requirements, because it avoids sending or storing the implicit  
part
 >    of the IV.  However, it limits the number of IVs that can be
 >    generated, because the implicit part is fixed, and it adds  
complexity
 >    to the system, by making the system coordinate the implicit part
 >    through out-of-band means.  Thus, new protocol and system designs
 >    SHOULD NOT use the partially implicit format unless a review of  
all
 >    of the issues shows that the bandwidth or storage savings are  
worth
 >    the complexity.  (An alternative strategy for bandwidth savings is
 >    discussed in Section 7.4.)
 >

<    Fixed field and the Counter field are concatenated, then they are
<    bitwise exclusive-ored with the Salt field, and the resulting value
<    is the IV.  The Counter is incremented, treating it as an unsigned
<    integer with the most significant byte on the left, and the stored
<    Counter field is set to the incremented value.  Then the IV is
<    returned.
---
 >    stored Counter value MUST be checked to determine if an IV can be
 >    generated; an IV can only be generated if the value of Counter + 1
 >    does not exceed the maximum allowable value of the Counter  
field.  If
 >    an IV cannot be generated, then the operation returns an  
indication
 >    that there are no more IVs that are available.  Otherwise, the  
Fixed
 >    field and the Counter field are concatenated, then they are  
bitwise
 >    exclusive-ored with the Salt field, and the resulting value is the
 >    IV.  The Counter is incremented, treating it as an unsigned  
integer
 >    with the most significant byte on the left, and the stored Counter
 >    field is set to the incremented value.  Then the IV is returned.

 > 7.4.  Bandwidth Use
 >
 >    An implicit or partially implicit IV uses less bandwidth than a  
full-
 >    sized IV.  But as noted above, the (partially) implicit IV format
 >    reduces the number of IVs that can be generated and adds  
complexity
 >    to the system.
 >
 >    An alternative approach to bandwidth savings in a protocol  
design is
 >    to use a predictable IV format, such as that of Section 4.1, and  
then
 >    apply header compression to the IV.  Header compression is often  
used
 >    on bandwidth-constrained links, and it can be applied to encrypted
 >    packets [RFC3095].  The format of Section 4.1 can easily be  
handled
 >    by header compression.  This approach has several benefits: it  
makes
 >    IV generation simpler, it allows bandwidth savings for  
environments
 >    in which it matters while putting the complexity burden onto the
 >    systems that opt to realize those savings, and it increases the
 >    number of IVs that can be used.  Specifications that use this  
design
 >    alternative SHOULD require the use of the IV format in Section  
4.1.
 >

 >
 >    Almost all cryptographic systems can implement counter-based
 >    deterministic IVs.  In many cases, it is straightforward to  
generate
 >    deterministic IVs associated with a short-term key in use by a  
single
 >    encrypter, as in a typical point-to-point protocol.  Complications
 >    can arise, however, when there are multiple encrypters, or when  
a key
 >    is used for an extended period of time.  Cryptographic systems  
that
 >    cannot ensure IV distinctness should not use deterministic IVs,  
and
 >    should instead use a misuse-resistant mode of operation such as  
the
 >    Synthetic Initialization Vector (SIV) Authenticated Encryption  
mode
 >    of operation [RFC5295], or a randomized algorithm such as the CBC
 >    mode of operation (though an additional authentication mechanism  
must
 >    be used with that option).  If authentication but not encryption  
is
 >    required, then it is possible to use an algorithm that does not
 >    require an IV, such as HMAC [RFC2104].
 >

Gmane