Paul Hoffman <phoffman(_at_)imc(_dot_)org> writes:
At 4:56 PM +1200 5/3/08, Peter Gutmann wrote:
>>(The "or shorter" attached to the "1024" is also going to prove
problematic
with FIPS-evaluated crypto implementations, since you can't do < 1024 bits
for those).
That's just plain wrong. Nothing in the FIPS evaluation says that you cannot
verify signatures shorter than what they require.
I didn't say you couldn't verify sigs, I said you couldn't get the code to do
that evaluated because the minimum they'll accept is 1024 bits. In other
words you'd be using non-evaluated code (or code run in a non-evaluated mode)
to do the sig. verification.
I admit that I haven't gone through a FIPS evaluation myself, but what you
say seems wrong.
I've gone through several, and talked to numerous others who have as well.
It's the usual crapshoot, some labs will allow < 1024-bit keys and some won't.
For my own code I've had one lab pass 512-bit keys OK and another one say that
any ability to use keys of less than 1024 bits would mean it couldn't be
evaluated. In another, more amusing case reported to me by someone else, they
got one lab to OK it at 512 bits, then a second lab required them to submit
paperwork showing that they blocked all keys of less than 1024 bits, and after
they did that the first lab complained that they were failing their tests on
512-bit keys. In the end they just declared that their product didn't support
any keys less than 1024 bits and everything was OK.
If someone from NIST or from a test lab wants to chime in here, that would be
grand.
What really matters is what the labs in sum total enforce, not what NIST
thinks or what one individual lab does. As the above examples show, you can
jury-shop your lab to get 512-bit keys passed if you like, but it only works
in some cases and to be safe you need to use a minimum key size of 1024 bits.
Peter.