Design threadsafe Crypto API callable via ChromeWorkers for DOMCrypt

RESOLVED WONTFIX

Status

()

Core
Security: PSM
RESOLVED WONTFIX
7 years ago
2 years ago

People

(Reporter: ddahl, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

7 years ago
The current implementation of DOMCrypt calls into NSS directly, which is frowned upon by our security team, also there are unexpectedly weird bugs that pop up from this practice, so it will be better to provide some new thread-safe APIs to use from js-ctypes or directly from a ChromeWorker
(Reporter)

Updated

7 years ago
Assignee: nobody → ddahl
If we're using js-ctypes, I don't need IDL, I just need the prototypes/declarations of the stable API that DOMCrypto would expect.

Also, we should work out where these declarations and their implementations should live. I have changed the component to Security:PSM since that is where all the NSS-touching code currently lives, and AFAICT there would be nothing DOM-specific about it.
Assignee: ddahl → nobody
Component: DOM: Mozilla Extensions → Security: PSM
QA Contact: general → psm
(Reporter)

Comment 2

7 years ago
(In reply to comment #1)
> If we're using js-ctypes, I don't need IDL, I just need the
> prototypes/declarations of the stable API that DOMCrypto would expect.
I think we should start with an API we can call from a ChromeWorker - it does not have to be js-ctypes. I'm unsure how much it will buy us in this case. My prototype code used js-ctypes as that was the easiest way for me at the time.
> 
> Also, we should work out where these declarations and their implementations
> should live. I have changed the component to Security:PSM since that is
> where all the NSS-touching code currently lives, and AFAICT there would be
> nothing DOM-specific about it.

That makes sense. I wasn't sure where to put it.
(Reporter)

Comment 3

7 years ago
Created attachment 538923 [details]
DOMCrypt WeaveCrypto wrapper object

Attached is the WeaveCrypto 'wrapper' that DOMCrypt uses. A modified API that follows this basic form would be a good model for a chrome-privileged API for Identity and DOMCrypt APIs to use. 

Some differences here: Instead of referencing the private key, you would use the current host's domain name. This way we can allow NSS to do its own, proper key handling via the key3.db. In which case, will there be some changes required with the way that NSS gets and uses keys? 

Brian: what is the format of the keys in key3.db? is there a search API or way to get the keys via a named attribute?
(Reporter)

Comment 4

7 years ago
(In reply to comment #3)
> Created attachment 538923 [details]
> DOMCrypt WeaveCrypto wrapper object
> 
> Attached is the WeaveCrypto 'wrapper' that DOMCrypt uses. A modified API
> that follows this basic form would be a good model for a chrome-privileged
> API for Identity and DOMCrypt APIs to use. 
> 
Forgot to add the link to the modified WeavCrypto I have been using: https://github.com/daviddahl/domcrypt/blob/master/extension/domcrypt/content/domcrypt_worker.js#L381
(Reporter)

Updated

7 years ago
Summary: Create IDL(s) for new PSM/NSS apis for DOMCrypt to call via js-ctypes safely → Design threadsafe Crypto API callable via ChromeWorkers for Identity and DOMCrypt
(Reporter)

Comment 5

7 years ago
Changed the title as I only care that the API is threadsafe and does things safely - js-ctypes should not be a requirement.
(Reporter)

Comment 6

7 years ago
Created attachment 539830 [details]
Internal IDL 1st pass

Just a first pass IDL that describes the interfaces we will need to cleanly and safely talk to NSS with for Identity and DOMCrypt consumers
Attachment #538923 - Attachment is obsolete: true
Attachment #539830 - Flags: feedback?(bsmith)

Comment 7

7 years ago
(In reply to comment #6)
> Created attachment 539830 [details]

David, do you speak about crypto facilities that work at Mozilla JavaScript level ? I know a very few about, but I have heard that builtin crypto facilities are already there ( - window.crypto? ). What is the difference between them and DOMCrypt ? This information is not available on Add-Ons/DOMCrypt home page.

The reason I am asking for is : designing crypto interfaces is a very complicated task, and, at first glance, your proposal looks naive. E.g.

--  int CipherMessage::algorithm ?!!!
    Algorithms aren't just numbers, they may have a parameters. What these parameters are depends on algorithm. How to represent these parameters is a painfull question.

--  AString SymmetricAPI::Encrypt(in AString aKey) ?!!!
    Hmmm... plain-text key ??? Unbelievable. Input to some PBE algorithm ? Which one ?

Etc, etc...
(Reporter)

Comment 8

7 years ago
(In reply to comment #7)
> (In reply to comment #6)
> > Created attachment 539830 [details]
> 
> David, do you speak about crypto facilities that work at Mozilla JavaScript
> level ? I know a very few about, but I have heard that builtin crypto
> facilities are already there ( - window.crypto? ). What is the difference
> between them and DOMCrypt ? This information is not available on
> Add-Ons/DOMCrypt home page.

DOMCrypt performs public key encryption, signing and hashing. The spec has a symmetric encryption API as well. window.crypto is quite limited when it comes to general purpose crypto - you can generate a cert and sign but that is about it. 

> 
> The reason I am asking for is : designing crypto interfaces is a very
> complicated task, and, at first glance, your proposal looks naive.

No doubt, I am the first to admit that this is a naive, ignorant proposal, but the power we can deliver to users is unparalleled - we are past the point where a fast, async crypto API should be in the browser.

> --  int CipherMessage::algorithm ?!!!
>     Algorithms aren't just numbers, they may have a parameters. What these
> parameters are depends on algorithm. How to represent these parameters is a
> painfull question.

not really, NSS already defines them here: http://mxr.mozilla.org/mozilla-central/source/security/nss/lib/util/secoidt.h#300
> 
> --  AString SymmetricAPI::Encrypt(in AString aKey) ?!!!
>     Hmmm... plain-text key ??? Unbelievable. Input to some PBE algorithm ?
> Which one ?

I'm glad you asked, as I am not sure yet - I was thinking it would be a symmetric key generated via PK11_KeyGen - then wrapped with a public key for safe keeping. What ideas do you have?
I filed bug 665057 for the Mozilla ID API. This bug will be just about the API that DOMCrypt needs. I expect the DOMCrypt API discussion to be long and I don't think we should have that discussion in this bug. Let's discuss & design DOMCrypt in mozilla.dev.tech.crypto (instead of in this bug) as much as possible.
Summary: Design threadsafe Crypto API callable via ChromeWorkers for Identity and DOMCrypt → Design threadsafe Crypto API callable via ChromeWorkers for DOMCrypt
(Reporter)

Comment 10

7 years ago
(In reply to comment #9)
> I filed bug 665057 for the Mozilla ID API. This bug will be just about the
> API that DOMCrypt needs. I expect the DOMCrypt API discussion to be long and
> I don't think we should have that discussion in this bug. Let's discuss &
> design DOMCrypt in mozilla.dev.tech.crypto (instead of in this bug) as much
> as possible.

very good. thanks.
(Reporter)

Updated

6 years ago
Attachment #539830 - Flags: feedback?(bsmith)

Comment 11

5 years ago
This is probably superseded by Bug 865789.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.