----- Original Message ----- > From: "Kyle Hamilton" <aerow...@gmail.com> > To: "mozilla's crypto code discussion list" > <dev-tech-crypto@lists.mozilla.org> > Cc: "Justin Lebar" <justin.le...@gmail.com> > Sent: Friday, April 20, 2012 7:40:12 PM > Subject: Re: Feedback on DOMCryptInternalAPI > >> **** > >> > >> 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. > > CMS does not require DER. It requires BER, specifically to handle > indefinite-length streams. It may be the case that there are > multiple sections of code writing to the same stream, as a valid > (though spaghetti-codish) implementation technique. > > Streaming signature should be a function of streaming digest. > PKCS#11 submits the digest to the module for signature, and returns > the signature blob. This is the case even for DSA and ECDSA > modules. >
Good to know. > > I see standards which suggest that it should be permitted, and no > actual reason not to. Ok, can you point to some standards docs for me to read about? > > (Speaking of ECDSA, I'd like that enumerated in the IDL. I'd like to > enable DHKE, but I'd also like to enable ECDHKE. I will add ECDSA for signatures for sure. Again, I am not sure if ECDHKE would be permissible for us to use. > Dan Bernstein's > Curve25519 function is exemplary for this, with a derived key length > of 256 bits. The downside is that any ECDH implementation requires > a key derivation function, like a digest -- one must not use > ECDH-agreed values directly. Personally, I'd like to see this > requirement inflicted on DHKE secrets too.) Interesting. Are you interested in helping with a design for the symmetric encryption API? :) > > If the digest algorithm has no default, please don't specify a > default in the symmetric or asymmetric algorithms either. I'd > prefer a conceptually tidy API, with as few differences between the > algorithm types as possible. Yes. Makes sense. In our Identity work there is the notion of a alg/keybits argument/property for these kinds of things: "DS160" or "RS256". Cheers, David -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
