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. _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users