- From: Joshua Cranmer <pidgeot18@gmail.com>
- Date: Wed, 09 Oct 2013 11:59:09 -0500
- To: public-webcrypto-comments@w3.org
Hello, I have been looking into the feasibility of using the WebCrypto API as specified in the current draft in order to implement a pre-existing security protocol, that of the Off-the-Record protocol supported in some chat clients. A link to the full specification of this protocol may be found here: <https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html>; I am not involved in creating or modifying this specification in any way, and I merely wish to implement this using WebCrypto. The biggest issue in WebCrypto that I have found is that it lacks the ability to support DSA, which the OTR specification uses as the sole supported algorithm for the final two steps of the authenticated key exchange. In searching the archives of the mailing lists, it seems that this omission is intentional and not accidental, but I have found no explicit indication of why this is the case. Since implementations are free to add extra algorithms, I was also wondering if anyone was planning on adding support For DSA in their implementations. Another missing feature from WebCrypto is the lack of big integer arithmetic, which is needed to execute the Socialist Millionaire Protocol (a zero-knowledge proof of equality). Since this interaction is not strictly necessary for the protocol, I don't consider it a high priority. It strikes me that it might be advisable to provide a big integer library that supports constant-time arithmetic to avoid timing attacks. I've read the meeting notes of the latest face-to-face, and it sounds like the consensus there is to leave big integers to the JS language. I have other issues with the current specification, but I think this is due to the still-developing nature of the specification rather than any actual lack of functionality. The first of these is in the Diffie-Hellman exchange. As I understand it, if I say: let dhe = crypto.generateKey({name: "DH", prime: ..., generator: 2}); then the value of dhe.privateKey would be the value x and dhe.publicKey g^x (in big-endian order; these are the only values that make sense). However, when I want to derive the value of s = g^(xy) given x and g^y, it's not clear what I should use. I think: crypto.deriveBits({name: "DH", public: gy}, dhe.privateKey) would give me this value, but it's not clear from the specification as written, especially given the age of the PKCS#3 specification that is referred to. As a side note, the link given for PKCS#3 appears to be off; <http://www.emc.com/emc-plus/rsa-labs/standards-initiatives/pkcs-3-diffie-hellman-key-agreement-standar.htm> was the one I found via searching on the internet. Another complication I found was in trying to use the AES and HMAC algorithm. The specification derives the keys as byte arrays from the results of other algorithms, but it is not immediately clear to me how to use these byte arrays as keys. I have been provisionally filling these in as: crypto.importKey({name: "HMAC", hash: "SHA-256"}, m1) but the general lack of specification here makes it hard to tell if this is a correct mode or not. A final point of interest is that I would like, in general, to have support for a browser-secured keystore (which would presumably integrate more or less with a system keystore), but it's not clear to me if that is in scope for this working group. -- Joshua Cranmer News submodule owner DXR coauthor
Received on Wednesday, 9 October 2013 16:59:38 UTC