Live data from Hacker News

Modern Alternatives to PGP

blog.gtank.cc

101–110 of 261 posts

Re: Modern Alternatives to PGP

#101
post #97

A side issue, but: > It generates those passwords for you, and they're short, one-time-use combinations of three English words If an attacker knows the tool does this, doesn't this reduce the keyspace to crack to (number of words in an English dictionary)*3? Is that enough? Am I missing something? A very complete dictionary has around 170K words, let's generously assume the password generator is willing to use all of…

It is not multiplication, it is permutation (170k!). I don't know how big this number is, however it is pretty big. This technic even has a name: diceware [1]. [1]: https://en.m.wikipedia.org/wiki/Diceware

Sorry, not factorial either. More like 170k(170k - 1)(170k - 2).

Generally I see people using Diceware with more than 3 words too (at least 4 or 5). However if the file does not need NSA levels of security 3 words seems fine.

Re: Modern Alternatives to PGP

#102
post #94
post #80

One starts looking at things differently as years pass. I've been working with computers for >25 years now, and I've learned that long-term thinking is important. Remember '.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…

Those fancy box thingies are very well specified and fit into 100 tweets worth of public domain ANSI C with no dependencies. If you want your format to last 100 years, I’m not sure how to ensure it better than that. https://tweetnacl.cr.yp.to/

Yup--unless you think future you isn't going to be able to lay hands on a C compiler, you can literally tuck a copy of it alongside all your backups forever and ever anon.

Re: Modern Alternatives to PGP

#103
post #29

> 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.

Using "one-time-use combinations of three English words" is "fine" only if your definition of "fine" includes allowing someone with a minimal budget to find out the password in less than a year. I am seriously wondering under what definition this could be considered better than OpenPGP.

XSalsa20 is indeed fine, but XChaCha20 is better in every way. The proof for XSalsa20 provided by Bernstein applies to XChaCha20 as well.

Re: Modern Alternatives to PGP

#104
post #29

Earlier quoted context omitted.

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.

Using "one-time-use combinations of three English words" is "fine" only if your definition of "fine" includes allowing someone with a minimal budget to find out the password in less than a year. I am seriously wondering under what definition this could be considered better than OpenPGP. XSalsa20 is indeed fine, but XChaCha20 is better in every way. The proof for XSalsa20 provided by Bernstein applies to XChaCha20 as…

> Using "one-time-use combinations of three English words" is "fine" only if your definition of "fine" includes allowing someone with a minimal budget to find out the password in less than a year.

Magic Wormhole uses a PAKE to establish a secure channel from a low-entropy shared secret.

Re: Modern Alternatives to PGP

#105

A side issue, but: > It generates those passwords for you, and they're short, one-time-use combinations of three English words If an attacker knows the tool does this, doesn't this reduce the keyspace to crack to (number of words in an English dictionary)*3? Is that enough? Am I missing something? A very complete dictionary has around 170K words, let's generously assume the password generator is willing to use all of…

It’s enough because of the underlying PAKE technique. The passwords do not directly become the key, and an unsuccessful bruteforce attempt breaks the session.

PAKE isn’t really new, but it’s certainly underused for how much it changes the password game: https://blog.cryptographyengineering.com/2018/10/19/lets-tal...

Re: Modern Alternatives to PGP

#106
post #101
post #97

Earlier quoted context omitted.

It is not multiplication, it is permutation (170k!). I don't know how big this number is, however it is pretty big. This technic even has a name: diceware [1]. [1]: https://en.m.wikipedia.org/wiki/Diceware

Sorry, not factorial either. More like 170k (170k - 1) (170k - 2). Generally I see people using Diceware with more than 3 words too (at least 4 or 5). However if the file does not need NSA levels of security 3 words seems fine.

> 170k(170k - 1)(170k - 2)

Which is 4,912,913,300,340,000 ≈ 2^52. Fifty-two bits of entropy is pretty horrible for anything that you really care about: you want at least 128.

Re: Modern Alternatives to PGP

#107
post #97

A side issue, but: > It generates those passwords for you, and they're short, one-time-use combinations of three English words If an attacker knows the tool does this, doesn't this reduce the keyspace to crack to (number of words in an English dictionary)*3? Is that enough? Am I missing something? A very complete dictionary has around 170K words, let's generously assume the password generator is willing to use all of…

It is not multiplication, it is permutation (170k!). I don't know how big this number is, however it is pretty big. This technic even has a name: diceware [1]. [1]: https://en.m.wikipedia.org/wiki/Diceware

It's around 2^52 keys, which is pretty bad.

Re: Modern Alternatives to PGP

#108
post #72
post #29

Earlier quoted context omitted.

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.

Wireguard, libsodium, go's crypto libraries and Google's Tink have all implemented xchacha20-poly1305. I would not say that it's not a thing, but I would probably wait at least until the ietf process is over before using it.

I know it exists, and I don't think there's anything wrong with it. It's just weird to demand that everyone use it, since, as I said, it's barely a thing.

Re: Modern Alternatives to PGP

#109
post #74
post #39

Earlier quoted context omitted.

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…

I believe "gpg -c" remains a better idea than encrypted zip files and "openssl enc" due to better defaults/ciphers/kdf. The article mentions magic wormhole, but sometimes you need plain old symmetric file encryption with a password.

Yes, PGP is better than the Bass-o-matic ZIP cipher many implementations of ZIP use. PGP clears that very, very low bar.

Re: Modern Alternatives to PGP

#110

Some problems PGP (these days, this means GnuPG) solves pretty well for me: - offline encryption; - distributed web of trust; - digital signature (for messages and software packages); - batch processing; - certification of other users without a server at all; - ability to use a completely "offline" infrastructure; - sending messages without revealing the actual recipient (i.e. --hidden-recipient) - multiplatform; - e…

Of your list, the alternatives that George provided check off:

- offline encryption

- digital signatures

- batch processing

- no server

- offline infrastructure

- "hidden recipient" (which, ironically, is a command line flag to mitigate a flaw in PGP, and not in fact a feature of PGP)

- multiplatform

- easy to integrate

- copying and pasting ciphertext

- open source and well-tested

- not bound to phones

- not being an electron app

The things you don't get with these alternatives are flaws, not features, like "all being in one application".

You're making George's case for him. I'd recommend reading his article again, and then following the links.

Post reply on HN