- From: <bugzilla@jessica.w3.org>
- Date: Tue, 13 May 2014 16:51:19 +0000
- To: public-webcrypto@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25431 --- 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