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: Tue, 13 May 2014 16:59:53 +0000
To: public-webcrypto@w3.org
Message-ID: <bug-25431-7213-IAXPnU23sS@http.www.w3.org/Bugs/Public/>

--- Comment #12 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Mark Watson from comment #11)
> Ok, so at least we are clear now that we are talking specifically about the
> unwrapKey API with RSA-ES, as per the title of the bug, and not the
> decryptKey API (if you still maintain there is a problem with decryptKey,
> please raise a separate bug - it's a very different attack if it has to be
> done over the network rather than with direct access to the API).

No, it doesn't, but considering that I'm not advocating support for RSA-ES,
it's likely not worth exploring that in detail.

> You claim that there is still a viable timing attack if the error codes for
> padding failure and parsing failure were the same. Whether that's true
> depends on the implementation: an implementation could certainly take care
> to make the combined operation constant-time*. I'm not sure what changes we
> could make to the API to require that, though ?

And that's what I was exploring in Comment 1. However, as written, it's *not* a
quality of implementation issue. The spec makes NO requirements on how this
needs to be constant-time.

Your proposal of a hardcoded-key still fail to address the timing issues, but I
feel like this is going to be a bit back-and-forth detailing why the proposals
are not constant time. (In this case, you still have cache lines, you still
have memory access patterns, and you still have the possibility of
distinguishing whether or not the hardcoded key is the same size as the
expected key).

Mark, constant-time implementations are hard. Real hard. For example, of the
open-source RSA-OAEP implementations I've seen, there's only one constant-time
implementation not susceptible to Manger's attack. For many open-source
implementations not named "NSS" or "OpenSSL", cache-safe AES and AES-GCM remain
pipe dreams.

> However, as I explained, this attack is only of interest for the case where
> the attacker is not present when the RSA key is generated / imported /
> unwrapped: if the attacker is present at that time they can replace
> webcrypto with their own polyfill and obtain the key directly - much easier.
> So, I accept that for the specific case where an application persists an
> RSA-ES unwrapping key across browser sessions and on a browser with a
> sufficiently non-constant-time unwrapKey implementation, there is a relevant
> timing-based version of the padding oracle attack.

Which is, you know, a presumed major use case and part of making sure the API
is safe with respect to implementation behaviours. After all, ensuring
constant-time safe access to primitives was one of the key motivations for the

> I want us to be clear about the technical rationale here and despite your
> strongly-worded assertions above, this limited scenario seems to be the only
> one left.

I disagree, if only because your mitigations proposed are demonstrably not
safe, and certainly NOT part of the specification.

> [* for example, if the padding check fails, the implementation could call
> importKey with a hard-coded JWK, discard the result and return the same
> error as it does for parsing failure.]

You are receiving this mail because:
You are on the CC list for the bug.
Received on Tuesday, 13 May 2014 16:59:57 UTC

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