The "third party" you don't trust is your own sysadmin. That person
already has access to the plain text messages right now. So does
everyone tapping your connections. We suggest that you limit that
risk to the sysadmin you already trust.

You're introducing a single point of failure -- and a SPOF that's highly susceptible to coercion, at that.

You say you're opposed to widespread surveillance: this does *nothing* to address that. The only people it will stop are the people who aren't smart enough to realize, "You know, I could just get a subpoena." Or the ones who think, "You know, I could just plant malware on the sysadmin's computer and gain access to all their encrypted communications at once." Or the ones who think...

I think that's exceptionally foolish. Build systems that provide a measure of security against smart, dedicated attackers -- don't build systems that only provide it against childish ones.

This is not a solution.  This is a surrender.

Made false claims that DSA is compromised

I said "was certainly compromised in the past". As you know, one
source for DSA flaws is the current ssh-keygen man page:

"DSA keys must be exactly 1024 bits as specified by FIPS 186-2."

You apparently feel there is some explanation for "exactly 1024 bits"
other than the obvious one, that keys of that length are compromised.

You have not presented *any* evidence that 1024-bit keys are compromised.

For that matter, you haven't presented any evidence that you understand what a FIPS is. A FIPS is a *Federal* Information Processing Standard. It's not binding on private citizens. All FIPS 186-x says is, "if you want to use digital signatures with the United States Government, here is the digital signature scheme that we use." FIPS specifies a standard for the USG to use, not one for private citizens to use. Is it really so strange that a standards document would specify parameters for an algorithm?

For that matter, DSA has never been limited to any keysize, not even under the FIPS 186-2 regime. DSA is the Elgamal signature scheme with a very slight algorithmic tweak to reduce one avenue of attack on it. If a private citizen likes DSA but thinks it would be better with a 8192-bit key, they're free to go for it. It's just Elgamal, after all. We know how to extend DSA arbitrarily. We just don't, because there's really no point in it.

FIPS 186-2, which you're obsessing about, was released in January of 2000. In January of 2000, 1024-bit keys were expected to be safe for the next 20 years. There has never been *any* credible hint that, in January of 2000, the belief was that Elgamal signature schemes of length 1024 bits were suspect. It was the standard signature scheme in use in GnuPG 1.0 and PGP 6.5.8, both of which date back to that era.

Find me a single peer-reviewed paper published in a reputable journal that says DSA-1024 is compromised. (Joe Bob's Web Page of Crypto doesn't count. Something like EUROCRYPT or Financial Cryptography does.)

One.

Just *one*.

Do that and I'll happily eat a whole steaming plate of crow, feathers and all. But until then, I believe you're a dangerous charlatan.

If you want another source, NSA themselves consider DSA, specifically
ECDSA, to be only Grade B security. With their usual misdirection,
NSA calls it "Suite B".

False.  See, e.g.:

https://www.nsa.gov/IA/Programs/suiteb_cryptography/

Browse around there and you'll find Suite B is certified for TS/SCI information. Again: this is publicly available information that the authors want to be shared as broadly as possible.

Red Hat explicitly says the NSA's Suite B is
only good enough for "most" classified information.

False.  Let's quote the exact page, shall we?

"[Suite B] serves as an interoperable cryptographic base for both unclassified information and most classified information."

It never says it's only good enough for most classified information. It says it's used as an interoperable cryptographic base for most classified information. Given the size of the USG, it wouldn't surprise me if there was a rotor machine still in use somewhere. There's a lot of inertia there: bureaucracies don't change overnight, and the entire USG didn't switch to Suite B the moment the spec was published.

Made false claims that NIST . . .

NIST has often changed specs as each compromise is discovered.
Examples are DES...

With respect to DES, false. DES was proposed to the National Bureau of Standards (NIST's predecessor) in 1976; it was published as a FIPS in 1977, and was subjected to periodic five-year reviews in '83, '88, '93 and '99. No compromise has ever been discovered in DES; as of today, the best known method for breaking DES is brute force.

DSA...

You have not presented evidence for a single compromise against DSA. You point to a FIPS parameter specification and say "the only reason this would happen is if it was compromised!", yet the civilian cryptographic community -- which has looked at DSA *very* closely -- disagrees emphatically.

and Elliptic Curve.

Dual_EC_DRBG was handled in an appropriate manner: NIST advised against its usage and then completely withdrew it from the standard.

I suggest you are more careful about your accuracy before you make
accusations of false claims, or use the nasty slur "snake oil".

I've been quite careful, and I believe you're hawking snake oil.


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Reply via email to