RE: 2nd try at Algorithms Section

## See my opinions at ##

(1) Should a stream cipher be added?  "OTP", BBS, RC4, and ISAAC have
been suggested. There is clearly almost no support of having a mandatory
stream cipher but one or more could be optional or recommended.

## Real One Time Pads are logistically impractical. Pseudo-OTPs should
not be called that but should be named after the actual generative
algorithm. So, in my mind, "OTP" or the like is out.

## Blum Blum Shub has interesting security properties but is
computationally intensive, while the usual idea of stream ciphers
is to be fast. I've never heard of BBS being supported as a
normal option in any widely deployed system. I'm against it.

## RC4 is fairly common and easy to implement, even though you have
to call it by a different name to avoid legal problems. Apparently
it has a very minor security flaw while ISAAC, which is equally
easy to implement, has not yet had one found. However I had never
heard of ISAAC before so it is obviously not widely deployed.

## My conclusion: Adding RC4 as Optional would be OK, though I don't
feel that strong either way.

(2) Should we add a European hash algorithm or algorithms such as
RIPEMD-160?

## Perhaps I should have listed some other options there but SHA-1
is the most heavily used hash algorithm in the current spec and
RIPEMD-160 seems like a natural alternative. There are no stronger
RIPEMD hashes although there are -256 and -320 version that produce
more bits.

## This seems like a political question. I certainly don't think
RIPEMD-160 should be mandatory but we could add it as recommended
or optional if we want to be more eclectic. If we think that people
in Europe are just going to go ahead and use it anyway, we might as
well add it as at least Optional...

(3) On Diffie-Hellman, the attached makes specification of the hash
function orthogonal (since we have separate hash algorithm URIs anyway)
as well as "P" but rolls the Mask Generation Function into the DH URI to
avoid bothering to create a new class of algorithms and additional
verbosity when I don't think there will be much need for a different MGF
any time soon.  And when there is, we can define a new DH-MGF2 URI or
whatever.  This could be changed either way. The MGF could be broken out
as an additional explicit parameter. Or we could remove the ability to
specify an arbitrary "P" and just have it be null and/or fix the hash
algorithm at SHA1 or something...

## I guess I incorporated my opinions in the draft, which I don't think
needs to change in regards to the questions above  :-)

(4) On the Symmetric Key Wrap algorithms, I have assumed that the
consensus is still to follow the CMS algorithms exactly. However,
especially now that I have written it up, it seems very odd that we have
RC2 CMS wrap mandatory, which requires the implementation of the RC2
cipher, when that ciper isn't even optional for data encrytion. Should
this be made consistent and if so how?

## The current situation in the spec makes no sense. Requiring implementation
of RC2 just for key wrap while not including it for data encryption makes
no sense from the point of view of limiting the code load on small devices,
etc.  Is RC2 encumbered?  If so, I would definitely say to toss it.  If it
is unencumbered, I could see making BOTH RC2 key wrap and RC2 data encryption
Optional.

## On the key wrap algorithm structures themselves, they seem a bit kludgy
to me but they are a deployed standard and I don't think we want to try
to come up with a new structure.

(5) Additional Block Ciphers. It has been suggested that all the other
AES finalists be added as at least optional except possibly RC6 which is
encumbered.  (I suggested that, since we already have 3DES and AES, we
add a block cipher that was a composition of them but there seems to be
no net support for that which was probably a bad idea.)

## Forget encumbered stuff like RC6. Of the other three (Twofish, MARS,
and Serpent), I don't see much reason to choose between them and adding
three is excessive so I suggest we leave it as it is.  (If there had
been an announced "runner up" or 2nd place AES winner, I'd say we should
add it as Optional, but there isn't.)

(6) Additional chaining modes. It has been suggested that at least
provision be made for specifying other chaining modes (other than by
definining new URIs) and/or that a counter mode be added.

## CBC is clearly the dominant chaining method now. If and when there
is enough demand for an alternative, it can be added via new URIs.
I don't think we need any change here.

## SUMMARY:
	I can see adding ARCFOUR as optional.
	I can see adding RIPEMD-160 as optional.
	We should either drop RC2 key wrap or add RC2 data encryption and
if we go the add route, I think they should be Optional.
	Those are the only changes I currently support. I don't think
these minor additions would overburden the specification and there
are reasons that support them.

## Thanks,
## Donald

Received on Wednesday, 23 May 2001 12:13:10 UTC