> one-time-use combinations of three English words I really don't think that this is secure. > nacl/box and nacl/secretbox Both of which use XSalsa20 - which while not broken there should be no reason to use it rather than (X)Chacha20.
You're wrong. Magic Wormhole is fine, and so is XSalsa. XChacha is barely even a thing; Bernstein formalized extended-nonce Salsa20, but not Chacha20.
Modern Alternatives to PGP
71–80 of 261 posts
Re: Modern Alternatives to PGP
#72> one-time-use combinations of three English words I really don't think that this is secure. > nacl/box and nacl/secretbox Both of which use XSalsa20 - which while not broken there should be no reason to use it rather than (X)Chacha20.
You're wrong. Magic Wormhole is fine, and so is XSalsa. XChacha is barely even a thing; Bernstein formalized extended-nonce Salsa20, but not Chacha20.
Re: Modern Alternatives to PGP
#73The context for this is this Go project proposal: 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.
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?
Re: Modern Alternatives to PGP
#74Earlier quoted context omitted.
Is OpenPGP considered 'legacy'? If so, why? 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 intere…
Yes, as the article says, it's a 1990s-style ultra-configurable do-everything design which, in practice, almost always gets deployed in a lowest-common-denominator set of constructions that are themselves mired in 1990s crypto. 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…
The article mentions magic wormhole, but sometimes you need plain old symmetric file encryption with a password.
Re: Modern Alternatives to PGP
#75Earlier quoted context omitted.
No web of trust? I would say that’s exactly the point. For tons of applications, you don’t need web of trust at all. Using PGP when you don’t want the web of trust features is an utter pain in the ass. I want to be able to encrypt/sign and have web of trust be a different issue.
I feel like this is asking past the point. Without a web of trust, how are you securely signing? You can go with somewhat centralized trust, but that only gets you do far. Or, rather, that forces everyone to deal with that centralized source. Much like the web of trust.
Re: Modern Alternatives to PGP
#76> No one was sending you encrypted emails anyway Guess what! Since I moved to Germany (from the Netherlands), I noticed that people send a lot of encrypted mail. Not random Germans, sure, but where in the Netherlands the security and broader hacker community was hard to convince, in Germany it's quite widespread. My colleagues (security firm) and friendly security firms (when we collaborate) expect nothing less, and…
Re: Modern Alternatives to PGP
#77Earlier quoted context omitted.
> I wonder what it's caused by and how we can encourage it Probably because many Germans have a relatively recent memory of the Stasi in the DDR.
The Dutch probably do to a similar extent. We were quite involved in the war, unfortunately, and burning records to avoid involving jews/romas/homos/etc. But yeah it's the only thing I can think of as well. I still can't pinpoint what argument it is that they are implicitly taught that we aren't.
People tend to forget what the problem was during WW2.
See rise of right wing parties (also in Germany...).
Re: Modern Alternatives to PGP
#78Earlier quoted context omitted.
> I wonder what it's caused by and how we can encourage it Probably because many Germans have a relatively recent memory of the Stasi in the DDR.
The Dutch probably do to a similar extent. We were quite involved in the war, unfortunately, and burning records to avoid involving jews/romas/homos/etc. But yeah it's the only thing I can think of as well. I still can't pinpoint what argument it is that they are implicitly taught that we aren't.
Nazi Germany passed laws restricting the public and private lives of “non-aryans” and other groups of people that they deemed lesser. With such laws, they turned the country from a democracy to a dictatorship. The nazis proceeded to kill millions of people, most of them Jewish.
And after that, there was like the parent commenter said the Stasi in East Germany, who was subjecting millions of people to mass surveillance.
And like I said, they have the first hand experience, so it certainly is more ingrained and near to life for the people of Germany than it is to everyone else.
Re: Modern Alternatives to PGP
#79The context for this is this Go project proposal: 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'm not so sure this is a great idea, quite commonly when reverse engineering something I need a good reliable implementation of a dated cipher. MD4 is still used in NTLM, RIPEMD160 is still used in Bitcoin and other cryptocurrencies, etc. 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…
Re: Modern Alternatives to PGP
#80Remember '.bz' files that were all the rage? Yeah. Bzip1, not '.bz2'. Good luck trying to read that.
For my data, I will stick to things that have been around for a long time and that are likely to stay. Those fancy 'nacl/box' thingies? I'm willing to make a bet that they won't be around in 5 years time.
As to PGP, it is hard to understand, so people don't use it and are not interested in developing it. Which is a shame, we could all use more good end-to-end encryption.
I also find this article rather funny, as I'm happily encrypting/decrypting data with OpenPGP, using the agent to authenticate to my SSH servers, and keep my keys securely on a YubiKey. I do hope these "modern alternatives" have good answers for storing my keys on a YubiKey, because otherwise the whole thing isn't really worth the effort.