-----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-----