Subject: Re: [saag] Request for review: NIST key transport specification

From: [email-masked] (Peter Gutmann)
Date: Sun, 14 Dec 2008 14:12:56 +1300

Actually from a quick look through this doc (to see if it's as bad as Derek 
pointed out), there's some really bizarre stuff in here.  For example 6.4.1.2 
is completely backwards, in normal RSA keygen you generate p and q and take it 
from there.  Section 6.4.1.2 assumes you have a d and then work backwards from 
there to get p and q (!!?!?!) and then apply primality tests to them... this 
is almost exactly backwards from how you'd normally get an RSA key, and in any 
case can't ever work in devices that use the CRT for which there's never any d 
present to begin with (although in that case I guess you'd use the CRT-only 
validation given later).  And that's not even beginning to touch on some of 
the other problems, e.g. the fact that under this scheme the cost of loading a 
key is now as high or higher than generating it was in the first place because 
you have to repeat all of the keygen primality checks and whatnot.

That's just from a quick glance so far... it looks like the doc consists of a
few good ideas mixed in with a huge amount of... really weird... confusion.

Peter.
_______________________________________________
saag mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/saag