Re: Algorithm support - "Native" versus "Polyfilled"

On 2012-12-04 08:38, Ryan Sleevi wrote:
> It does not.
> 
> That said, there are two levels of "not supported" here. If the U-A supports it and is implemented in terms of providers (and not all libraries are or U-As will be), it can export the key material from one provider and import it into the other, all without giving the raw key material to JS.
> 
> The second level is where the U-A doesn't support the KDF at all, at which point, to poly fill in JS, the JS *MUST* have the key material.
> 
> Both of these are understood and fit within the design requirements, but thank you for noting. This is no different than how "native" code behaves today.

>From an application writer's point-of-view I don't agree that this is comparable to how native code behaves today.

I.e. if you install the Bouncycastle JCE provider you know that you can perform essentially every algorithm there is, while the P11 wrapper over an HSM typically gives you very small set of operations.

IMO the Web Crypto API should deal with three distinct providers.
1. A SW-only (like BC),
2. a provider associated with the actual keys in "web-storage" (will eventually be in hardware and usually being non-exportable),
3. and last but not least, a virtual provider for pre-provisioned keys.
all having different algorithm capabilities.

Anders


> 
> On Dec 3, 2012 11:33 PM, "Anders Rundgren" <anders.rundgren@telia.com <mailto:anders.rundgren@telia.com>> wrote:
> 
>     The Web Crypto API doesn't rely on a provider concept like most other cryptographic APIs do.
> 
>     A provider only supports a specific set of algorithms and it is usually impossible to expand the set without exporting the key material in clear.
> 
>     Let's say that you want to do a ECDH operation with a specific KDF and the provider doesn't support the KDF you want to use.  AFAICT you are stuck unless the provider also supports "raw" ECDH which allows polyfilling of the missing KDF.
> 
>     I don't quite understand how the Web Crypto API deals with this issue.
> 
>     Anders
>

Received on Wednesday, 5 December 2012 05:53:58 UTC