rjh at sixdemonbag
May 4, 2012, 8:13 AM
Post #15 of 55
On 05/04/2012 10:17 AM, Milo wrote:
> Well, many expect rise of the quantum computing during lives of most
> of us. This can trash most (if not all) asymmetric algorithms
> (Shor's algorithm)
No. It can trash *some* asymmetric algorithms. There are a good number
of asymmetric algorithms whose decision problem exists outside of BQP.
(McEliece, for instance. For those wondering what BQP is, it's the
quantum computing analogue to P: it describes those problems you can
solve in a reasonable time with a quantum computer.)
I do not understand how, if you're concerned about quantum computing,
you can believe "it will all be better if we just use larger keys!",
rather than "it will be better if we use algorithms that cannot be
efficiently solved by a quantum computer."
> and reduce strength of symmetric ciphers in half (with for example
> Grover's algorithm).
Not half, reduce the strength of symmetric ciphers by a square root. A
128-bit cipher's strength is not halved (which would make it 127-bit);
it's reduced to the equivalent of 64 bits (the square root of 128 bits).
> Beside this consider widespread usage of 256-bit symmetric ciphers.
> If things you are writing are all the truth behind key length
> security we are dealing with huge, mass overkill or even scam
> perhaps. But I think we aren't.
It's worth noting that, per Suite B, 256-bit crypto is only required for
material that's at the top of the classification pyramid: things like
nuclear weapon release codes and other things that might cause 300
million people to have a really bad day.
128-bit crypto is considered quite sufficient for the rest of the
Also, some people are using symmetric crypto for secrets that must be
preserved for 50+ years -- census data, for instance. If you're
concerned about 50+ years of confidentiality, then yes, it makes sense
to go hog-wild on key lengths. But for the rest of us, the
confidentiality of our communications will be better-served by many
other measures than just adding more bits to the key.
> Just like modern cellphones' CPU/GPUs are s-f from Apollo mission's
> engineers' perspective, just like "640K ought to be enough for
> anybody" and like 32-bit address space for IP protocol is more then
> enough. History is showing quite clearly that such speculations
> despite - ofte high - competencies of the authors are missed.
An Apollo engineer would be unlikely to view a tablet PC as something
indistinguishable from magic. Nothing about it would be unknown to
them: only the size, the power and the integration would be new. This
is pretty much the norm in the field: from a pure computer science
perspective there's almost no difference between a Burroughs 5000 and a
Introduce quantum algorithms, though, and suddenly quite respectable
computer scientists suddenly start sweating bullets and saying, "uh, I
don't quite know about this, umm, *in theory* it will be kind of like
this, but the practical ramifications are ... hey, look at the time,
6000-qubit quantum computers are a magic so subtle they are
indistinguishable from high technology. They might, if we are
fortunate, be invented in our lifetimes -- but let's not go about saying
we need 8K RSA keys to defend against 6000-bit quantum computers. If
quantum computers bother you that much, use McEliece.
> Please try to avoid comedic undertone of your statements and
> comparisons if you want to keep discussion's level sane.
The discussion was already profoundly silly: the overt comedic
statements drew attention to this. Successfully, apparently.
> Yeah, then leave your home open because "Wow, who want to check
> every door in the world. So many of them".
> Yeah, let's drop all the crypto (encryption) for common folk because
> <put your arguments from above here>.
> Giving users easier-then-hacking-through-sources way of setting
> bigger key size isn't a crime.
No, but there's no point in it, either. Frankly, I'd rather the GnuPG
developers spent their time on pursuits that are more reasonable and
will give a better return on investment.
Gnupg-users mailing list
Gnupg-users [at] gnupg