W3C home > Mailing lists > Public > public-webcrypto@w3.org > May 2014

[Bug 25431] Error names allow RSAES-PKCS1-v1_5 oracle attack against wrapped keys

From: <bugzilla@jessica.w3.org>
Date: Fri, 09 May 2014 18:50:07 +0000
To: public-webcrypto@w3.org
Message-ID: <bug-25431-7213-620MJ1tMJy@http.www.w3.org/Bugs/Public/>

--- Comment #5 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Mark Watson from comment #4)
> Regarding the attack in the title of this bug, is it not a general issue
> that where several primitive operations are concatenated it is a problem if
> the error codes indicate at which stage the combined operation failed ?


A "secure" algorithm will be independent of how these errors are reported.

An "insecure" algorithm - such as RSA-ES or, for that matter, RSA-OAEP - WILL
be particularly sensitive.

> Or, is it the case that RSAES with unwrap is the one example where there is
> a known attack (due to the particular weakness of RSAES padding) which can
> exploit this knowledge of which stage failed ?

So, any RSAES decryption is at risk. As I explained in comment #1, any
combination - whether it be simply 'encrypt' or 'unwrap' - will fail if there
is any structure to the key OR if any internal state leaks.

> Wouldn't it be prudent to eliminate the distinction and just return a single
> error code in the case of any operation that can fail in multiple distinct
> ways ?

Not in any meaningful way that will improve security, no.

> Regarding the timing attack mentioned by Ryan, it seems it is a general
> quality-of-implementation issue to mitigate such attacks with constant-time
> implementations. And it seems to me this could apply to many other
> operations, although it may be the case - as above - that RSA-ES may be the
> one example where there is a well-known attack.

No, it's not a "quality of implementation" issue - it's a fundamental API

The API, as written, *cannot* provide a safe decrypt or unwrap operation. The
mitigation for this - such as that employed by TLS - involves additional
behaviours that would fundamentally alter the nature of the API.

That is, we would make it such that RSAES needs to know the key length, cannot
unwrap keys with structure (ergo, it's only suitable for symmetric keys), has
to ALWAYS succeed (returning a random key), and then, and even then, it's
*still* possible for security to be botched (eg: in the case of XML DSig &
friends, the failure to decrypt using the unwrapped key is itself a signal that
the key unwrap failed).

Compare this with AES-KW or RSA-KEM, in which revealing success or not does not
provide an oracle. RSA-OAEP still provides an oracle (Manger's attack), but
that CAN be mitigated by a quality of implementation (of which most libraries -
including Botan, Crypto++, and OpenSSL, do NOT have quality implementations)
such that the success/failure is not an oracle.

Considering that at this point, any hope of allowing a 'safe' implementation
would require a breaking API change to accomodate RSA-ES, I think it's
reasonable to remove entirely. This is, however, why it was included in the
list of algorithms to begin with - to explore all algorithms and their
interaction with the API, and to ensure that the API would "fit". It's clear
that the API we have does not "fit", and I am not convinced we can reasonably
"break" the API such that it would. It's also clear, from this bug and mailing
list discussion, that no one would be upset if it was removed.

You are receiving this mail because:
You are on the CC list for the bug.
Received on Friday, 9 May 2014 18:50:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:22 UTC