RE: Algorithm Selections

The sizes have not been dtermined yet, in part because I don't know what
NIST is saying about this in the FIPS.  The proposal that I am putting into
the S/MIME working group is 128 and 256 MUST, 192 SHOULD, following by a
statement that 128 is sufficent for most needs and should be the default.
This is going to be subject to debate I am sure.

jim

-----Original Message-----
From: hal@finney.org [mailto:hal@finney.org]
Posted At: Wednesday, November 15, 2000 12:54 PM
Posted To: XML-Encryption
Conversation: Algorithm Selections
Subject: Re: Algorithm Selections


Jim Schaad, <jimsch@nwlink.com>, writes about crypto algorithms.
I thought it looked very good overall.  A few comments:

> Recomendation:  AES is MUST in the same key lengths as CMS adopts.  AES in
> other key lengths and TripleDES are MAY.

Do you know which key lengths CMS is going to use?  I assume when you say
"AES in other key lengths" you still just mean 128, 192 or 256 bits, right?

> Recommendation:  RSA-OEAP should be used with AES.  RSA-v1.5 should be
used
> with TripleDES.

Do we really need to have a legacy mode here?  Can't we just go with OAEP
alone?  It is cryptographically superior.

> Diffie-Hellman is the CMS defined key agreement algorithm.  It should be
> noted that several patent claims have been made againist improvements on
the
> base DH algorithm to prevent some known attacks.  (The IETF S/MIME working
> group has put out an informational document on these attacks.)  There is
no
> need to differenentate between the Ephemeral-Static and Static-Static
> variants in the XML Encryption standard  as the same syntax and processing
> can be used for both variants. (All that differs is how the Originator
> KeyInfo is specified.)

I wonder if we would consider modifying this to eliminate the need for
ASN.1 construction and parsing.  I love this line from RFC2631, which
defines the DH key agreement algorithm:

     KeySpecificInfo ::= SEQUENCE {
       algorithm OBJECT IDENTIFIER,
       counter OCTET STRING SIZE (4..4) }

   Note that these ASN.1 definitions use EXPLICIT tagging. (In ASN.1,
   EXPLICIT tagging is implicit unless IMPLICIT is explicitly
   specified.)

In general, ASN.1 and XML seem to have somewhat overlapping goals of
abstractly specifying data structures.  We could use an XML schema in
place of ASN.1 to define the data structures and get the same functional
effect.

> Recommendation:  Unless there is a strong reason for putting in a Key
> Agreement algorithm, no key agreement algorithm should be proposed.

Key Agreement is basically just public key encryption based on discrete
logs rather than factoring.  I would like to see us include a discrete
log based encryption algorithm as an option.  Just as the DSig spec has
both DSS (discrete log) and RSA (factoring) signatures, we should have
both as well.

> Recommondation.:  Make the AES keywrap from the NSA be the manditory when
it
> appears.

Maybe need to specify CMS-keywrap as a fallback?

Hal Finney
PGP Security