RE: RSA Signature Padding

[Peter Gutmann <pgut001@xxxxxxxxxxxxxxxxx>]

"Santosh Chokhani" <SChokhani@xxxxxxxxxxxx> writes:

>Any how did that go?
>
>I suspect fell on deaf ears?

Well, if you mean "after careful analysis the conclusion was that it was, at
best, going to be a pointless gesture", then I guess, yes.  My summary was:

-- Snip --

No matter how cool/interesting/useful/mandated in standards a new design is,
it won't be used if it requires redeployment of all existing hardware and
software for little apparent gain.  Two illustrative examples of this are
X9.42 DH and OAEP with AES.

An Internet standard RFC required that implementors support X9.42 DH key
agreement, and provided RSA as an option (in IETF terms, "MUST X9.42, MAY
RSA").  However, no existing software supported X9.42, no CAs would issue
certificates for it, even if they did no-one wanted to renew all of their
certificates ($$$) for an algorithm that provided no advantages over RSA, and
no hardware (either crypto accelerators or smart cards) supported it (there
was some token support after a few years, although even now there are problems
being found with the X9.42 test vectors which indicate that no-one has really
looked at them).  As a result, even though the standard mandated use of X9.42,
everyone treated it as if it said "MUST RSA, SHOULD NOT X9.42", pretending to
do X9.42 while running business as usual with RSA.

OAEP is in a similar situation.  In order to get it usefully deployed, it
would be necessary to issue certificates that would only work with OAEP
otherwise everyone would just keep using them with PKCS #1 v1.5.  This would
have exactly the same effect as X9.42.

An attempt was made to force OAEP through by tying it to AES.  In other words,
in order to use AES you also had to use OAEP.  Apart from the list of issues
already mentioned with X9.42 above, this was also going to be deployed in an
area where it was necessary to use crypto hardware for performance reasons
(this area is almost always glossed over in crypto designs).  Most crypto
hardware does RSA in hardware and either leaves the symmetric crypto for
software to do (cheaper hardware) or leaves further key management to software
and provides hardware acceleration for bulk data encryption once all further
key processing has been performed (more expensive hardware).  In addition a
few rather specialised crypto engines do everything in hardware.

In all cases except the most primitive accelerators that consist of nothing
but a bignum engine, moving to OAEP would require replacing the crypto
hardware.  Crypto hardware boxes typically cost $10,000-$20,000 each, assuming
you can find one that supports OAEP.  A server farm needs a great many of
these $20,000 boxes.  Smaller devices like smart cards may only cost $10-$20
each, but then you've got 100,000 of them to replace.  Some devices can upload
new firmware, but will zeroise their keys when this occurs for security
reasons, requiring a complete redeployment from scratch of all keys and
certificates ($$$).

As a result, a vendor would have two options: Supply a non-compliant solution
that uses AES with PKCS #1 v1.5, or supply a compliant solution that uses AES
with OAEP and requires rebuilding the entire infrastructure (hardware,
software, and certificates) from the ground up.

The standards group abandoned the idea of tying OAEP to AES ("It's X9.42 all
over again").

-- Snip --

Peter.