Jon Callas <jon at callas.org> wrote:
Why ever would you want a 1Kbit curve? Sure, arguably, but please make the
argument. As it is, Curve3617 is more than one really needs. I'm genuinely
interested.
The fastest method for solving the discrete log problem in finite
fields is index calculus. It is not known to be applicable to the
elliptic curves we use for cryptography (or obviously we wouldn't be
using them), modifications of the technique are applicable to
super-singular curves / extension fields and where applicable they
have sub-exponential scaling similar to the number field sieve for
factoring. While it's not believed that there can exist a
straightforward adaptation currently-believed strong curves, if one
were to be discovered it would render any of the common sizes
practically insecure.
It would be terrible indeed to migrate to ECC only to end up with keys
no more secure than 512 bit RSA.
But by comparison to performance in other groups a of size to around
1024 bits but leave the crypto system secure in practice even if index
calculus could be directly applied.
(Sorry for delay in responding, but I spent a little while googling
around to see if I was the only person thinking like this. I found a
number of things, the most amusing an old post of Bruce Schneier's:
"Realize, though, that someday -- next year, in ten years, in a
century -- someone may figure out how to define smoothness, or
something even more useful, in elliptic curves. If that happens, you
will have to use the same key lengths as you would with conventional
discrete logarithm algorithms, and there will be no reason to ever use
elliptic curves. "
https://www.schneier.com/crypto-gram-9911.html#EllipticCurvePublic-KeyCryptography
)
For many personal communications applications involving end to end
encryption— though certainly not all— speed is only an issue if you're
talking about hundreds of milliseconds, bandwidth is an issue only if
you're talking about tens of kilobytes. In these applications, when
we're talking about long term security for _unspecified applications_
(meaning, we should assume the cryptosystem is life critical and the
attacker is state level, because we've not specified an application
that excludes these parameters) then it is seem obviously prudent to
use more of the available speed and bandwidth budget to increase
security.
The next question for that should be _how_ to go about increasing the
security. One answer would be to pair up an orthogonal asymmetric
cryptosystem, but all the abelian hidden subgroup problems seem to
share a common fate— improvements in discrete log tend to result in
factoring improvements. For signatures merkle signatures might fit,
but for encryption the asymmetric cryptosystems which appear unrelated
all have overheads which probably do take us outside of the available
budget.
But a larger curve would not. Nor would it impose a very large
implementation or design complexity overhead. Nor would it be so
expensive that it would be unduly burdensome to users who don't want
it when they are forced to interact with it (as 250kbyte McEliece +
ECDH public key would) And it may well provide additional security
against currently unknown risks.
As a design principle, if the user has bandwidth and cpu to spare— it
would be quite sad to see his security fail simply because the
software didn't care to offer a maximally conservative option.
Failing to have a solid "I don't care about the speed/size, crank my
security to 11" option also creates a great market opportunity for
non-standard cryptography which turns out to be snake-oil "crank it up
to 11 (mod 10)", and increases the risk that users fail to use
encryption at all because they are too easily convinced by FUD that
the cryptography isn't strong.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp