Re: web crypto api user report

On Fri, Dec 5, 2014 at 12:42 PM, Ryan Sleevi <sleevi@google.com> wrote:

thanks for your response. much appreciated.

> For RSA-OAEP, public keys support encrypt/wrap, private keys support
> decrypt/unwrap.
>
well, now i can't break it. and given the amount of time i spent verifying
the behaviour, this is frustrating and not a little embarrassing.


> 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.
>
absolutely. which is why i was so surprised at the behaviour.

> > 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.
>
fair enough. rather naively i was hoping to import PKCS1 keys and export
them as OAEP or something, but i accept that it's not necessarily the web
crypto API's mission to help people migrate their keys.

> > 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.
>
consider me educated. i assume that this is because you don't want
something signed with your "decrypting" private key floating around,
exposed to brute-force? are there other reasons?

thanks for all the help
Jason