https://github.com/golang/go/issues/30141
Filippo proposes to deprecate (but not remove) Blowfish, archaic curves, CAST, MD4, RIPEMD160, TEA, Twofish, XTS, and OpenPGP from the Golang x/ libraries (which are "officially supported" but not part of the standard library.
It's really heartening to see a project get serious about shedding legacy crypto.
I was under the impression that it's mostly that it's really hart to reliably support e.g. calling 'gnupg' (cmdline), gpgme (library), etc.?
ISTR there was a company that's re-implementing the OpenPGP standard from scratch in a library-oriented-fashion, but for the life of me I can't remember their name...
I don't disagree with the 'drop legacy' stance, btw, I'm just interested in what exactly the issue is.
No modern cryptographic engineer looking at any problem PGP solves would design a system that looked like PGP.
PGP used to make some sense as a simple at-rest storage format, but in the era of Nacl and libsodium, even that use case is a poor fit.
I'm not sure it's just me being behind the times, but it seems that quite a few of the ideas behind PGP (specifically: asymmetric encryption) aren't really being exploited seriously. Instead there's lots of halfhearted "oh, let's just encrypt thing X with a password stored in thing Y" where Y is presumably more 'secure'. This is a bit of a tangent, but I find it interesting and depressing that industry has learned very little, if anything.
But, tangentially, it's a bad idea to use asymmetric encryption when you don't absolutely need it. Modern symmetric AEAD ciphers, which are implicated in pretty much all serious public-key designs anyways, are safer to use that asymmetric cryptography.
Seeing a public key in a design that doesn't demand public keys is a cryptographic engineering code smell.
The article mentions magic wormhole, but sometimes you need plain old symmetric file encryption with a password.
Or it's not useful to compare what's at hand?
Not sure I'm getting the message behind the jab.
Install something better.
GnuPG could do with better defaults, but that is true for every system good enough to have aged. A more modern KDF would also be welcome but it won't impact end user security. Just to put things in perspective.
...if you use it correctly. It appears that many people can't do this.
Telling users that it's broken without pointing to a clear alternative is counter productive as they are likely to end up much worse.
A more modern KDF would be welcome, but it is also important to communicate the benefit to an end user: You get comparable security with a shorter password. There are other things to consider when choosing an encrypted file format.
It's pragmatic, informative, and highlights that bashing gpg for this specific use case, without naming something better...is arguably worse than saying nothing.
Why downvote it instead of just naming a better choice? What's the big secret?
I downvote lots of things. On Hacker News, we're explicitly encouraged to downvote disagreement, especially when verbalizing that disagreement will just clutter up the thread. Everyone gets downvoted. I've been downvoted all over this thread. You were just downvoted a minute ago.
The one thing we're not supposed to do is complain about downvoting. That's in the guidelines for the site.
Where does it say that? It says a better kdf would improve the security of shorter passwords. I don't see anything that suggests a poor kdf is a feature.
The kdf used for "gpg -c" also seems better than "openssh enc". And we've still not heard what the reasonable alternative is for symmetric/password file encryption is. So, I'm sticking with gpg for that use case.
Gnupg is a default package for Ubuntu[1], so not always.
"Install something better"
That's a bit mysterious. Various Google searches don't suggest anything obvious.
[1] See http://releases.ubuntu.com/bionic/ubuntu-18.04.2-live-server... ctrl-f, search for gnupg
Edit: We do this, then push the files to a S3 bucket and users can get the files and decrypt them without having to deal with remembering/forgetting static passwords.
Systems exist outside of the Go ecosystem and not all systems are new. Compatibility is important. It's great to flag these as not recommend for new designs, but it's quite another to remove them entirely and prevent people from easily implementing compatible software. Seems more like something that should be in the documentation or spit a compiler warning if that isn't deemed loud enough.
MD5 is similarly broken but I'm assuming they don't want to remove it because it's still quite popular in some use cases - what exactly is their standard for that popularity?
What should I use instead of email.