At 6:50 PM +1200 5/13/08, Peter Gutmann wrote:
Paul Hoffman <phoffman(_at_)imc(_dot_)org> writes:
You'll need to justify this one, Peter. Show me some examples where any
previous version of S/MIME, none of which have "sane" lower limits, was used
by any organization to justify a stupid key size.
How many would you like?
Only real ones that relate to this thread, thank you.
Without naming names (if anyone really insists I
could perhaps name them in private), there's an organisation using 128-bit RSA
keys for access control to significant amounts of power switching gear because
everyone knows that 128-bit keys are good so it should be fine for RSA. Since
this is in the US I'm not that fussed about someone using it to take out their
power transmission systems :-), but I think some other people might be. Uhh,
Canadian health board using RSA in ECB mode to encrypt patient data, and they
ended up using either 128- or 64-bit keys because otherwise things ran too
slowly. Signing using 384-bit keys by a european government organisation...
how many do you want, and how long have you got? I haven't got them all
committed to memory so I'd have to dig back through old email and whatnot.
...and none of these relate to the S/MIME standard, right?
I realise these aren't all specificially for S/MIME (the signing one was, at
least for PKCS #7) but they're examples of just what people will do if the
standards don't disallow it.
I'll take that as a "right, they don't relate to the S/MIME standard,
they're general key-size blunders". That is, the current S/MIME
standard mandates being able to sign with 512-bit keys, but your
examples above show that the blunderers don't do that. Please explain
why you think that changing the standard will have any effect on them
at all.
A number of the examples came from talking to
other IETF security folks so there's probably a lot more like this floating
around (every time I post one of these horror-story comments I tend to get a
bunch of email saying "That's nothing, you should hear this one...").
Fully agree.
In the
case of two of the three above the justification given was some variation on
"if these really were no good then they'd be explicitly disallowed. Since
they aren't, it's perfectly OK to do this".
I'm skeptical, to say the least. If you have actual quotes of people
saying that, fine; quoting someone third-hand through an IETF
security geek is not a good way to get accurate results.
>Please suggest specific text that would meet your criteria.
The original (proposed) MUST NOT text.
There was no verb in that text. Are you supporting "MUST NOT sign
with keys under 512 bits", "MUST NOT verify signatures whose keys are
under 512 bits", or both?
There's no point in verifying a
signature that you know is insecure because you know no more about the
validity of the data after the verification than you did before.
Fully agree. Please say why you know that every signature with keys
of 511 bits is insecure, yet ones with 512 bits are secure enough.
If the
signature can't tell you anything about the validity of the data that's been
signed then it should be rejected as an invalid signature because it's not
serving the purpose for which it was intended.
Fully agree.