[45235] in cryptography@c2.net mail archive
RE: Exponent 3 damage spreads...
daemon@ATHENA.MIT.EDU (Kuehn, Ulrich)
Thu Sep 21 15:58:05 2006
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Thu, 21 Sep 2006 09:55:08 +0200
In-Reply-To: <E1GQ7VA-00012r-00@medusa01.cs.auckland.ac.nz>
From: "Kuehn, Ulrich" <Ulrich.Kuehn@telekom.de>
To: <pgut001@cs.auckland.ac.nz>, <cryptography@metzdowd.com>,
<daw@cs.berkeley.edu>
Peter,
> From: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz]=20
>=20
> David Wagner <daw@cs.berkeley.edu> writes:
>=20
> >(a) Any implementation that doesn't check whether there is=20
> extra junk=20
> >left over after the hash digest isn't implementing the PKCS#1.5=20
> >standard correctly. That's a bug in the implementation.
>=20
> No, it's a bug in the spec:
>=20
> >9.4 Encryption-block parsing
> >
[...]
>=20
> Nothing in there about trailing garbage.
>=20
Actually, this part is about _encryption_, we are talking here about =
signature padding. But the PKCS#1 spec talks about building up the =
complete padded signature input at the verifier, and then comparing it. =
However, there is a note saying that alternatively one could parse the =
padding without saying how this would be done. The reason to use such a =
thing is given as saving intermediate memory. Oh well!
So in fact what a lot of implementors do, parsing the padding, is not =
specified in sufficient detail to get it right. I would consider this =
buggy implementation resulting from buggy specification.
Regards,
Ulrich
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
