RSA padding scheme

[brian m. carlson]

On Sun, Jan 22, 2012 at 11:29:54PM +0400, Sergey Matveev wrote:
> >If the standard allowed different padding schemes, then all
> >implementations would have to support multiple padding schemes, which
> >would be burdensome without providing significantly more security.
> Hmm, I see. However does it really won't provide much higher security?
> Just theoretically very interested in all of that. According to
> Wikipedia, there are several kind of attacks against plain RSA (just
> some of them):
> * sending ciphertext with the same "e" to several recipients

This depends on a small message.  All secure padding schemes avoid this
problem because the pad the message so it is not small.

> * no randomness

All secure padding schemes provide this, as well.

> * problems with the product of two ciphertexts

This is not a problem with OpenPGP because the attacker never gets to
see the value encrypted with RSA because it's the symmetric key.

> So, padding should close all of those problems. As I can see, PKCS #1
> 1.5 just adds random pad to satisfy length requirements. Is those
> randomness sufficient to solve above three issues? OAEP, comparing to
> PKCS #1 1.5, is much more "mature" and looks really cool with dependent
> on each other X and Y.

The existence of PGP predates the invention of OAEP by at least three
years.  So it really wasn't an option, and PKCS #1 v1.5 is not insecure,
so there's no reason to break backwards compatibility.

> If PKCS #1 1.5 is sufficient, then OAEP just brings "all-or-nothing"
> additionally? Or because of RSA's ciphertext "payload" is always pretty
> random data (symmetric keys), then (probably) bad padding won't deal any
> damage?

Basically.  The issue is that if the padding is incorrect, the message
is rejected.  So the attacker can't manipulate the message without
risking corrupting the structure of the method.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: </pipermail/attachments/20120123/c55a4811/attachment.pgp>