If you see the letters GNU in a systems design, and that system intersects with cryptography, I can almost guarantee that it will be badly designed to an alarming degree.

This is as true of GnuPG (and PGP in general) as it is of designs like the proposed GNU Name System (IETF draft) and cryptographic libraries like GnuTLS and libgcrypt. In fact, I cannot recall single GNU-branded cryptography project that isn’t a roaring dumpster fire.

I will elaborate.

Problems with the GNU Name System’s Cryptography

Asymmetric Cryptography

The GNS (GNU Name System) uses an unconventional construction for zones:

A zone in GNS is defined by a public/private ECDSA key pair (d,zk), where d is the Private Key and zk the corresponding public key. GNS employs the curve parameters of the twisted edwards representation of Curve25519 [RFC7748] (a.k.a. edwards25519) with the ECDSA scheme ([RFC6979]).

GNU Name System IETF Draft, section 2

This is beyond weird: Going out of your way to use the edwards25519 curve from RFC 7748, but not use the Ed25519 signature algorithm, but still choosing to use deterministic ECDSA (RFC 6979). If you’re lost, I wrote about digital signature algorithms in a previous blog post.

The authors acknowledge the unconventional nature of their design choice in section 9.1 of the RFC draft:

GNS uses ECDSA over Curve25519. This is an unconventional choice, as ECDSA is usually used with other curves. However, traditional ECDSA curves are problematic for a range of reasons described in the Curve25519 and EdDSA papers. Using EdDSA directly is also not possible, as a hash function is used on the private key which destroys the linearity that the GNU Name System depends upon. We are not aware of anyone suggesting that using Curve25519 instead of another common curve of similar size would lower the security of ECDSA. GNS uses 256-bit curves because that way the encoded (public) keys fit into a single DNS label, which is good for usability.

GNU Name System IETF Draft, section 9.1

The bold statement (my emphasis) is nonsense: In any design that uses digital signature algorithms, your system should map a private key (some opaque byte string) to a public key (some other opaque byte string) and signatures should also be opaque byte strings. The inclusion of a hash function under the hood of the signature algorithm is a moot point, especially since RFC 6979 also uses HMAC-SHA2 to generate deterministic nonces, thereby rendering their choice of RFC 6979.

Using Ed25519 with a 32-Byte Private Key (instead of a 64-byte private key) is also trivial. To wit: Libsodium offers crypto_sign_seed_keypair() for this purpose.

But even worse: ECDSA (a variant of Fiat-Shamir) is less secure and slower than EdDSA (a variant of Schnorr). The authors of the RFC do not defend this design choice beyond this hash function non sequitur.

Symmetric Cryptography

The GNU Name System project doesn’t stop there. It further throws IND-CCA2 security out the window and specifies encrypting with AES and TwoFish in a cipher cascade, using Cipher Feedback (CFB) mode.

The authors do not even attempt to defend this decision. I sincerely doubt they’ve heard the words “adaptive chosen-ciphertext attack” in the course of their self-study.

Because, y’know, attackers will surely never be able to replay UDP traffic if a runtime exception occurs because of corrupted data.

“But They Use Digital Signatures”

Cough.

Other GNU Projects

If you want to learn about why GnuPG (and the PGP ecosystem in general) is terrible, I recommend Latacora’s takedown.

GnuTLS is an SSL/TLS library created by the same people who created (and then abandoned) libmcrypt, which was the scourge of bad cryptography in the PHP ecosystem for many years (until it was finally excised in PHP 7.2). Consequently, the project’s CVE history should be no surprise.

Quick story: A few years ago, a few timing attacks were discovered in libgcrypt by regular chatters in Freenode’s ##crypto channel, including Taylor “Riastradh” Campbell. This led a lot of us to look at libgcrypt for more bugs.

The general consensus of the ensuing discussion was, “We probably shouldn’t try to fix them all, because a) that’s way too much effort because there’s too much badness and b) this library will be a ripe target for upcoming cryptanalysis researchers to get their first papers published for many years”. And, indeed, the attack papers that have come out over the years that affect libgcrypt haven’t disappointed.

Takeaway

If you see the letters GNU anywhere in a project that intersects with cryptography–except for its public license–it’s almost certainly an error-prone cryptographic design.