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:51:19 +0000
To: public-webcrypto@w3.org
Message-ID: <bug-25431-7213-SqdEDdJ5YQ@http.www.w3.org/Bugs/Public/>

--- Comment #11 from Mark Watson <watsonm@netflix.com> ---
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).

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 ?

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.

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.

[* 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:51:20 UTC

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