Re: web crypto api user report

On Dec 5, 2014 12:27 PM, "Jason Proctor" <jason@mono.hm> wrote:
>
> dear fellow cryptos,
>
> i'm new to the W3C and don't really understand the mechanisms and
procedures, and what with the web crypto API recommendation around the
corner, i realise that this message may well be very late to the game.
apologies in advance for any faux pas i may commit along the way.
>
> i've been using crypto APIs for a long time, and so when i recently
discovered the API, i thought i would try to essentially make
standards-compliant web-hosted versions of some of my applications. this is
an account of the issues i ran into along the way, which raise some
questions that i humbly hope the community can perhaps address.
>
> the main issue i ran into was related to (surprise) usages. if for
example i generate an RSA key pair, and happily encrypt and decrypt with
it, then export the public key, then i instantly lose its encryption
capability. this was a surprise, to say the least -- this is a *public* key
we're dealing with.
>
> (a reply on the comments list advised me of a workaround involving
removing the key_ops and ext properties from the JWK structure, pre-import.
this presumably simulates a key from the outside world, but it has the
opposite effect - i can import for encrypt but not decrypt this way. also
it does seem a little odd that hacking the JWK structure is required for
roundtripping with different usage ramifications.)
>
> however, the simple act of wrapping this key in a simple (ie easily
derived from consecutive numbers) AES key effectively removed the usage
restriction. this creates an odd dichotomy, where if *i* write the wrapping
code, it's not allowed, but presumably the API has its own special import
mechanism that bypasses usages.
>
> (a similar situation occurs with private keys and the decrypt usage. i
can get around that with wrapping, too, but experience has taught me to do
my own wrapping, especially in heterogenous environments - which is not
allowed here)
>

Frankly, this sounds like a bug in your code, not a spec issue.

For RSA-OAEP, public keys support encrypt/wrap, private keys support
decrypt/unwrap.

Wrapping/unwrapping the key or removing the usages from the JWK has zero
effect on these aspects, as they're encoded in the spec. You cannot use a
public key for decrypt (which, when you think about it, makes sense, as
then anyone in the world can decrypt) nor a private key for encrypt (for
the same reasons). If your system relies on anyone in the world being able
to decrypt with a public key, then what you've described is a signature,
not encryption.

That's why I suspect it is a bug in your code / the description of the
problem, or, at worst, in the implementations, but the spec is quite
explicit in this regard.

> another significant issue i ran into was that RSAES-PKCS1 is no longer
supported. this is unfortunate as there are a lot of such keys around.

Yes, but with the possible exception of TLS, and only in special, carefully
crafted cases that few have ever gotten right, they are all insecure.

So I don't lose sleep on the lack of support for them.

> it would have been nice if the API let me import such keys and then
export them as something "better", but the API seems to conflate keys and
key encoding.
>

It doesn't conflate keys and encoding. I suspect you're instead talking
about coupling keys to algorithms, which is a very intentional design
decision (see below).

Put differently, it was intentional NOT to support a generic abstraction
such as " RSA keys", and instead couple them to the algorithms and
parameters they would use, for security, for interoperability, and for
performance.

This is because using any key across multiple algorithms - whether an RSA
key for both PSS and OAEP or an AES key for both CBC and GCM - is a
fundamentally insecure operation.

> and the last issue (for now, grin) is that it seems i can make an RSA
pair for encrypt/decrypt or sign/verify but not both. really? i remember
the bad old days in pre-Bouncy Castle JCE, where i had to have both RSA and
DSA keys due to similar artificial restrictions.

This isn't artificial. This is because the mathematical operations employed
make it absolutely fatal for ANY cryptosystem to mix and match these. If
you are using the same key for enc/dec as you are for sign/verify, then you
have designed a system that is fundamentally insecure and broken.

>
> thanks for listening, and any help with these issues. if this isn't the
right place, then please advise.
>
> best regards
> Jason
>