(Not cross-posting to dev-platform per Mounir's plea, and because I
don't think these details are particularly interesting to that
audience.)
>> > 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?
>> It's pretty weird to me that you get a CryptoHmac and a CryptoHash
>> via
>> a constructor, but you get pk/sign via window.crypto. I'd prefer
>> window.crypto.getHash(), window.crypto.getMac(), or something.
>>
> These were spec'd as constructors, but don't have to be.
>
> We could also return the hash or hmac producing object like: var h =
> window.crypto.hash(alg);
I would like this.
>> 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.
>> 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. :)
Thanks, David!
-Justin
--
dev-tech-crypto mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto
