Re: ECC in OpenPGP

[Jon Callas <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> 
> Is it really worth switching horses across to ECC from RSA?  The NSA seems to think so...
> 
> Let me put it this way, as a hypothetical:  if OpenPGP next-gen had to choose between RSA and ECC, only implement one of them, which would we choose?

That's the wrong question, really.

There's one and only one reason to seriously consider ECC, and that is that you want public keys with security greater than 128 bits, and you don't want unwieldy key sizes.

NIST says that a 3Kbit integer public key has the same security as 128-bit symmetric keys, and that to get to 256 bits, you need a 15Kbit integer key. Argue with NIST's assessment this if you like -- heck, I *like* the argument, myself -- but the point is that if you want crypto-balance with AES-256, then RSA is unwieldy. No argument there.

If you're happy with 128-bit security, then you don't need ECC. RSA is just fine. If you want 256-bit security, then you have a quandary. You either need to go beyond 4096-bit RSA keys, or go to ECC. It's that simple.

One could argue that there is no need to do this before say 2020 or 2025, thus mooting the whole Certicom/RIM patent issue. There is merit to this way of dealing with it. However, if one wants one's protocol to be used with Suite B or things that are effectively Suite B, then one needs ECC before then.

Andrey Jivsov has circulated a draft for ECC in OpenPGP that was intentionally built to both satisfy Suite B and to avoid the whole patent thing, only using freely-usable technology. He probably needs to push that along some more. :-)

	Jon


-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.10.0 (Build 554)
Charset: us-ascii

wj8DBQFMfE8PsTedWZOD3gYRAgcsAKD+mWuqGtIaClxngXzdgPl8+x4flwCbBZdl
pefyVwOE4C49i3Js2a6zJ34=
=IZ9M
-----END PGP SIGNATURE-----