> Apologies. This is an internal API to support the WebAPI and will be used by > extension and browser developers.
Perhaps we're not talking about the same thing. Is https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest a web-facing API? It certainly appears to be; there are demos and everything. http://domcrypt.org/demos/demo.html >> > Sure, I don't imagine supporting any other MAC. >> >> Never e.g. CMAC? Why not? > > I guess I never considered it. However, I will keep this in mind when we > tackle MAC. Perhaps it is 'trivial' to add this - most likely not:) For the purposes of a web API -- and again, I'm now confused as to whether any of these APIs are exposed to the web, but I thought they were -- the question isn't whether it's trivial to add CMAC, but rather whether you want to commit that HMAC is the only MAC you'll ever want to use on the web. > While there is the ability to do this in NSS, I imagine since you will almost > always be signing a hash or set of hashes with a public key, this operation > will be very quick and operate on a small set of > data. Still, we will have to consider use cases like this. Ah, I thought that this API would handle the hashing for me. That seems in line with the "it should just work" aspect of the API. For the same reason, the API doesn't let me choose ECB encryption, and the API, I certainly hope, will MAC all encrypted messages and reject decryption with invalid MACs. On Sat, Apr 21, 2012 at 11:19 AM, David Dahl <dd...@mozilla.com> wrote: > ----- Original Message ----- >> From: "Justin Lebar" <justin.le...@gmail.com> >> To: "David Dahl" <dd...@mozilla.com> >> Cc: dev-tech-crypto@lists.mozilla.org >> Sent: Friday, April 20, 2012 6:31:02 PM >> Subject: Re: Feedback on DOMCryptInternalAPI >> >> (Not cross-posting to dev-platform per Mounir's plea, and because I >> don't think these details are particularly interesting to that >> audience.) >> > Ah, OK, sorry for the spam! > >> >> > interface CryptoHmac { >> >> >> >> Why isn't this CryptoMac? Surely the fact that it's an hmac is an >> >> implementation detail. >> > >> > Sure, I don't imagine supporting any other MAC. >> >> Never e.g. CMAC? Why not? > > I guess I never considered it. However, I will keep this in mind when we > tackle MAC. Perhaps it is 'trivial' to add this - most likely not:) >> >> >> >> Why is it that I get to stream data to the hash / mac provider, >> >> but I >> >> have to provide all my data upfront in order to encrypt / sign? >> >> I'd >> >> prefer if, for all four cases, we had the option to stream and >> >> give >> >> all the data upfront. >> > >> > We have talked about a streaming encryption/decryption method. I am >> > not sure if I see the use case for a streaming signature method. >> >> Suppose I have five separate pieces of data and I want to sign them >> all together. That's easy with a streaming signature, hard >> otherwise. >> > > While there is the ability to do this in NSS, I imagine since you will almost > always be signing a hash or set of hashes with a public key, this operation > will be very quick and operate on a small set of data. Still, we will have to > consider use cases like this. Thanks. > >> >> Can we have a default algorithm for hash / mac like we have a >> >> default >> >> pk / sign? I totally buy the virtue of giving people a choice of >> >> algorithm, but otoh it's also nice to be able to say "hash this >> >> for >> >> me" without worrying about which algorithm(s) the browser >> >> supports. >> >> >> > I imagine we might for the WebAPI, however, for this internal API, >> > I think we should specify it. >> >> Do you mean s/this/the? If so, I totally agree. If not, I'm >> confused, because I thought I was looking at the web api. :) > > Apologies. This is an internal API to support the WebAPI and will be used by > extension and browser developers. > > Regards, > > David -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
