[2888] in cryptography@c2.net mail archive
Re: PKCS#1 Attack Summary
daemon@ATHENA.MIT.EDU (Eric Young)
Mon Jun 29 14:58:25 1998
Date: Sun, 28 Jun 1998 20:11:54 +1000 (EST)
From: Eric Young <eay@cryptsoft.com>
To: Bill Stewart <bill.stewart@pobox.com>
cc: cypherpunks@cyberpass.net, cryptography@c2.net
In-Reply-To: <3.0.5.32.19980626202649.0098fdf0@popd.ix.netcom.com>
On Fri, 26 Jun 1998, Bill Stewart wrote:
> The cheap test is to check how long the decrypted PadString and
> Data fields are, by looking for the first 00 byte -
> usually the Data field is some known length, like 128 bits,
> so if the 00 shows up sooner, or later, or not at all,
> then the recipient should reject the packet as bad,
> just as it would for a decrypted packet not starting with 00 02.
> This is claimed to increase the number of tries to about 20 million,
> which is some help.
Now an interesting variant on this is that there is a bug in all SSLeay
variants that check PKCS#1 padding such that the library reported the PKCS#1
padding as ok if the decrypted message started with 0 or more 0x00 followed by
0x02. So,
0x02,
0x00,0x02
0x00,0x00,0x02
all report the padding as ok (assuming there was also at least 8 padding bytes
before the first 0x00). I was having a bugger of a time implementing the
attack using an RSA oracle based on SSLeay because of the false positives
being reported :-). I'm still to think about how much harder this makes the
attack.
So anyone wanting to play with implementing the attack should not use current
SSLeay versions for their RSA code unless they fix the bug (I convert a bignum
to a binary value (no-leading 0 bytes) without a subsequent length check.
eric
