- From: Kelsey Cairns <kelsey.cairns@inria.fr>
- Date: Wed, 19 Mar 2014 15:40:02 +0100 (CET)
- To: public-webcrypto@w3.org
- Message-ID: <319303951.9953446.1395240002241.JavaMail.zimbra@inria.fr>
Dear W3C Crypto API WG, Here at INRIA we're starting a security analysis on the current draft of the Crypto API, co-funded by INRIA and W3C. The idea is to try to get some results in before the end of the last call period. Doing analysis of an API spec is a slightly unusual activity, it can often lead to conclusions like "if the API is implemented this way.." or "if the application program uses the API like this.." which can seem a bit superficial, but we will aim to produce something concrete output in terms of implementation advice, test cases for implementations, etc. As an example of the kind of things we find, one of the things we were looking at in the spec this morning was padding oracles on key unwrap operations. These are common in implementations of PKCS#11, for example. Following the current WebCrypto spec, if you were to unwrap a key using AES-CBC or RSA PKCS1v1.5, incorrect padding would lead to "DataError" or " OperationError" respectively. Meanwhile, the error if the ciphertext is correctly padded but the key is too long or too short, the error is "SyntaxError". The fact that these are different *could* be enough to allow a network attacker to obtain the encrypted key by chosen ciphertext attack, which would be relevant say for use case 2.2 (Protected Document Exchange). As a first step we were planning to look in more detail at the key management subset of the API, but if there are any areas that are of specific concern where you'd like us to take a closer look and you haven't had time please let us know. All feedback welcome. Best, Graham Steel & Kelsey Cairns
Received on Thursday, 20 March 2014 07:46:58 UTC