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
