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