Re: [WebCrypto Key Discovery] Algorithm names in named keys

On Fri, Mar 1, 2013 at 1:22 PM, Nick Van den Bleeken
<> wrote:
> Hi,
> The user obviously shouldn't choose the algorithm, because no 'normal' user knows what to choose. So it is either the implementer of the web crypto API or de app developer who needs to make the decision of the algorithm to use. Ideally the implementer should do this (he knows most about cryptography), but only the app developer knows what he is going to do with the result of the sign/verify/encrypt/decrypt operation and consequently the supported algorithm(s) for the usage. But then the implementer should provide access to all supported algorithms for the key, so he can choose the most secure one which is supported for the use case. Or am I missing something?
> Regards,
> Nick van den Bleeken


This was solely in the context of the app developer and API implementer.

I'm saying that the web implementer cannot and should not provide
access to "any" or "all supported" algorithms for a given key, because
that's still too much responsibility on the "web developer" to get
things right. For example, one web developer / one version of the
application may choose to use a given RSA key with RSA-PSS, while
another web developer / another version *of the same application* may
choose to use the same RSA key with RSA-PKCS#1. The use and generation
of signatures using different algorithms with the same underlying key
material undermines the assumptions about the cryptographic strength
of the key.

You can also see this applied to mixing the same AES keying material
with a CTR mode of operation and a CBC mode of operation.

As such, the web implementer, when implementing named keys, should
prescribe the given algorithm that can be used with that named key, so
that there is only one acceptable choice to the web developer.

If an application wants to support multiple derived keys from a given
master key (for example, allowing AES-CTR and AES-CBC), then those
would be treated as independent named keys as written.

Received on Friday, 1 March 2013 21:42:07 UTC