Re: Comments on SP800-108

2008-05-06 Thread Peter Gutmann
Jack Lloyd [EMAIL PROTECTED] writes:

As a standard, this is specification is a disaster.

Somewhat more strongly worded than my comments :-), but I had the same
feeling: Why yet another bunch of arbitrary PRF/KDFs to implement?  We now
have ones for SSL, for TLS, for SSH, for IKE, for PGP, for S/MIME, for... well
I don't know every crypto protocol in existence but I'm sure there's plenty
more.  What's wrong with PBKDF2, which seems to do the job quite nicely?
Whoever dies with the most KDFs wins?

There just doesn't seem to be any reason for this document to exist except
NIH.  PBKDF2 is a well-specified KDF, is relatively easy to implement (and
implement in an interoperable manner), has been around for years, and has
numerous interoperable implementations, including OSS ones if you don't want
to implement it yourself.  What's the point of SP800-108?  What
requirement/demand is this meeting?

Peter.


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Comments on SP800-108

2008-05-05 Thread Jack Lloyd
Hi,

As a standard, this is specification is a disaster. Just from a quick
read, I see the following:

However, alternative orders for the input data fields may be used for
a KDF.

with a length specified by the function, an algorithm, or a protocol
which uses T as an input.

In feedback mode, the output of the PRF is computed using the result
of the previous iteration and, optionally, using a counter as the
iteration variable(s).

With sufficient options, all implementations are non-interoperable. I
think you've managed to reach that point here. As an implementor, my
instinct is to stay well away from this entire mess and just use IEEE
1363's KDF2, which is:

  - simple enough that anyone can implement it easily and without
 interop difficulties, or requiring protocol negotiations (and
 then the implementor has to do the negotiation properly - which
 opens up new avenues for security holes)

  - secure enough that it doesn't matter (ie, that the likelyhood
 that a security flaw in the KDF is the critical problem is far
 lower than a security flaw elsewhere in the system)

My recommendation: choose something that will work for nearly
everyone, and mandate it directly. For instance, why make the counter
length configurable? In 99% of implementations, the thing that will
make sense is a 32-bit counter (to paraphrase the famous if apocryphal
Bill Gates quote, 4 gigabytes of keying material should be enough for
anybody), but by refusing to mandate this behavior, you force every
implementor and application designer to choose something and then
negotiate on the off chance that some other length was chosen, or that
the other side is using variable length encodings - something which is
allowed by the spec, as best as I can tell, and which opens up some
pretty big (at least theoretical) holes.

I have no comments about the actual security aspects of it; it looks
fine to my eye, but given the interoperability issues listed above I
don't plan on implementing any of these KDFs anyway, so I can't say I
much care whether they are actually secure or not. I would advise you
to remember that crypto does not exist in a vacuum, and should help,
not hinder, the overall security of a system.

Regards,
  Jack Lloyd

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]