Re: Using WebCrypto to implement security protocol

On Wed, Oct 9, 2013 at 9:59 AM, Joshua Cranmer <pidgeot18@gmail.com> wrote:
> 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.

Given the size limitations of DSA (mod DSA2), is there a reason not to
migrate towards ECDSA - which is supported?

The reasons for omitting DSA (or more aptly, questioning
implementation), which themselves are quite weak and subject to
change:
1) Smaller security parameters (unless you've implemented DSA2)
2) No one asked for it

>
> 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.

Correct. A long and hard decisions, particularly since many of the
vanity and esoteric security protocols want this, but the only
sensible path given our group and the trajectory.

>
> 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.

Correct. Alternatively, could refer to RFC2631 SEction 2.1.1, which
itself references X9.42 as describing, as they describe the same
shared secret calculation IIRC.


>
> 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.

I'm not sure I follow the question. Is the issue the lack of
specification for key formats?

For importing a sequence of bytes as an HMAC key

var promise = window.crypto.subtle.importKey("raw", m1, { name:
"HMAC", hash: "SHA-256"}, ...);

>
> 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.

I'm not sure I fully understand this request. Key storage is something
we've (intentionally) omitted, but I'm trying to understand what the
actual properties are that you would desire/expect from such a store,
to see if this is something already addressed by the spec.

Received on Wednesday, 9 October 2013 17:34:37 UTC