SSH Agent keys >4096 bit?
Robert J. Hansen
rjh at sixdemonbag.org
Sat May 5 01:57:20 CEST 2012
On 05/04/2012 04:35 PM, Milo wrote:
> Yes - niche, proof-of-concept, poorly analyzed ciphers. Let's talk
> about those widely used and considered mainstream. Those are our
> biggest concern.
McEliece is almost as old as RSA. Generations of graduate students have
tackled it in cryptanalysis courses. Almost a thousand academic papers
have been published on it. None have shown any significant weaknesses
Its inventor, Robert McEliece, received the Claude E. Shannon Award a
few years ago. What the Fields Medal is to mathematics, or the Turing
Prize is to pure computer science, the Shannon Award is to information
On the one hand, we have a cipher designed by a Shannon recipient which
has had almost a thousand papers published about it without any really
significant results. On the other hand, we have you calling it a niche,
proof-of-concept, poorly-analyzed cipher.
> I'm not suggesting that longer key for asymmetric ciphers is a cure
> for quantum computing backed cryptanalysis.
> I wrote about possible, future way of circumventing need of sucking
> nova's energy to successfully attack cipher(text).
The power and time requirements for computation are well-known.
Circumventing either would require
(a) invention of completely adiabatic computing
(b) repeal of the Heisenberg Uncertainty Principle
(c) repeal of the Second Law of Thermodynamics
(d) ridiculously large quantum computers running at
Any of the four puts us back into the realm of science fiction. If
you're advocating making keys larger, I'd like to know which of the four
science fiction breakthroughs you expect might happen. And no matter
which of the four you choose, I'll point out that should your chosen
breakthrough come to pass, we will all have much bigger things to worry
about than whether our 20-year-old communications are still safe.
> Thanks for pointing that but in considered situations this is slight
Halving the strength of a 128-bit cipher leaves you with 127 effective
bits of security. Rooting the strength of a 128-bit cipher leaves you
with 64 effective bits of security. The former is still well beyond our
ability to brute-force: the latter is well within our ability to brute
force. I don't consider this to be a slight difference.
> You can't tell consumer or end-user that he can't use 256-bit,
> symmetric cipher for his (even!) porn stash because this is some kind
> of faux pas and he is iconoclast because of this.
I cannot force someone to not use a 256-bit cipher, true. I can
certainly point and laugh at people who believe using one makes them
more secure, though.
Nobody has the right to be taken seriously. That's a privilege that
must be earned.
> Really? Then what's the reason behind 256-bit hw-supproted crypto
> (e.g. AES instructions for amd64 and x86), widely accessible on
> consumer market which has nothing to do with nuclear weapons?
The dirty little secret of crypto is that we've had a *great* symmetric
cipher ever since the mid-1970s: 3DES. It's big. It's ungainly. It's
slow. It has all the aesthetics of the Soviet Realism school of art.
It's very hard to code up because there are so many fiddly bits. And
yet, 3DES has been turning the best minds in crypto into burned-out
alcoholic wrecks for the last 35 years.
It has been undergoing constant attack for 35 *years*. Entire new
branches of cryptanalysis have been invented just to try and dent it.
These approaches have all failed miserably.
There are a few niches where 3DES doesn't work very well. If you need a
cipher that can encrypt a 1000baseT connection, you're better off using
something faster. If you need it on a smartcard, you're better off
using something more space-efficient. But for the rest of the problem
space, 3DES has been rocking the house for almost as long as I've been
So here's the question: why isn't 3DES used in more places?
Marketing. Because people -- both in the private sector and in the Free
Software world -- want to be able to say they support the latest and
greatest and best thing.
More information about the Gnupg-users