[dev-tech-crypto followup]
On Fri, Apr 20, 2012 at 8:11 AM, David Dahl <dd...@mozilla.com> wrote:
We could also return the hash or hmac producing object like: var h =
window.crypto.hash(alg);
This would be the most general way to handle it. (I'm told that 'generality is
the key'.)
****
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.
I see standards which suggest that it should be permitted, and no actual reason
not to.
(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. 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.)
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.
I'd like it to default to SHA2/256. This is particularly for deriving 256-bit
symmetric keys from ECDH exchanged secrets.
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.
-Kyle H
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
