Re: Using WebCrypto to implement security protocol

On 10/9/2013 12:34 PM, Ryan Sleevi wrote:
> 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 specification I'm working with is one that I have no control over. 
Since there is already a large body of software using this specification 
that supports DSA keys, I'd need to be able to support them as well. 
 From reading mailing list archives, there is an idea to support ECDSA, 
but implementation is held off to being "problematic patent-wise" (I 
stand no opinion on this issue).

> 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
Consider me as someone asking for it. :-) As the specification currently 
doesn't seem to be leaning towards a mandatory set of algorithms for 
implementation, it might be advisable to at least specify what the 
interface for key parameters should look like for those who do desire to 
implement it.

>> 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"}, ...);

I think that looks like it should do what I desire. I might advise 
including an example in the document. :-)

>> 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.
>
It is almost certainly possible to develop a keystore over local storage 
and the cryptographic primitives, but what that lacks is integration 
with the browser's keystore (such as where it stores passwords). It 
seems like it would be a good idea to me to have an API that could let 
websites store private keys in the same or a similar key storage so that 
it could be easily integrated with features such as, e.g., a master 
password.

-- 
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

Received on Wednesday, 9 October 2013 18:49:14 UTC