encryption algorithm

[Robert J. Hansen]

On 12/18/2013 2:18 AM, Daniel Kahn Gillmor wrote:
> Sorry, but NIST does face a crisis of trust, particularly in the area of
> cryptography, whether either of us wants that to happen or not.

Perhaps: but *not over the PRNG they published*.  Please stay on point.

You are demonstrating a tendency here to stake out a position ("NIST is
untrustworthy") and argue towards it; and as soon as an argument is
refuted, you do a weak backtrack of that argument and stake out a new
one in the same direction.

Your argument for moving towards RSA-3072 was that you wanted the system
to be "more even."  When pointed out that we could not make the
asymmetric component "more even" with AES-256, you quickly said "well,
I'm not advocating RSA-15000" and have since pretended you never made
that argument.  When you made a smear against NIST on the basis of a
flawed PRNG algorithm -- and in context of what you were responding to,
it's hard for me to believe you were saying anything other than it was a
deliberate backdoor introduced with NIST's knowledge -- you backtracked
to "well, I never said it was witting/willing, and anyway, just putting
out a single bad spec is enough to damage trust in them."

There's no point in having a discussion about a subject if it starts
from a position and seeks arguments to support that position, rather
than starting from arguments and hoping it will lead to a position.  I
firmly believe in the latter.  The former is the specialty of bad cable
news channels where talking heads scream past each other -- which is the
state I fear this discussion has devolved into.

I'm going to make one last brief summation of my position.  Past that, I
am done with this thread.  It's not going anywhere useful.

1.  112 bits of keyspace is generally acknowledged to be the minimum
    level that current applications should support.  New crypto code
    should aim for at least 128 bits; 256 bits is better.
2.  The reason for the discrepancy is that when deploying a new system
    it's far easier to overdesign it.  When changing an existing
    system, one has to deal with a large installed codebase.
3.  GnuPG's asymmetric default meets the standard in #1.  There is no
    imminent and pressing need to change.
4.  GnuPG's asymmetric default is believed to be secure for about the
    next 15 years.  That meets GnuPG's goal of providing pretty good
    privacy.
5.  When GnuPG introduces ECC support it will be a fine opportunity to
    deploy new certificates, whereupon the default can be changed to
    256 bits of keyspace with minimal disruption to people above and
    beyond the disruption shifting to ECC will do.
6.  No one has presented any reason to shift to 128-bit keyspaces
    right this very instant, especially when ECC is on the horizon and
    approaching fast.  Since the asymmetric component is expected to
    be safe for 15 years, we're not in an exposure window.
7.  If you seriously believe that a 112-bit keyspace is inadequate,
    then you need to stop using computers.  Pretty much every
    Authenticode-signed Windows application uses RSA-2048 at maximum.
    ATMs use 3DES, with a 112-bit keyspace.  The HTTPS infrastructure
    tends to max out at RSA-2048.  112-bit keyspaces are endemic.  It
    would be nice if they'd all move to ECC, and hopefully they will,
    but we are not facing an imminent Cryptoageddon because society's
    computing infrastructure uses 112-bit keyspaces.
8.  I would like to see GnuPG migrate to 256-bit keyspaces.  I'd like
    to see this migration done in a calm, orderly fashion.  Given the
    total lack of risk presently associated with RSA-2048 -- or for the
    next 15 years or so -- I'm just fine with waiting a year to make a
    single cutover to minimize disruption to end-users.

You may disagree with these; I imagine you will disagree vigorously.
That's fine.  But now I trust my position is clear, and we can put this
to rest.