Live data from Hacker News

PGP Marks 30th Anniversary

philzimmermann.com

61–70 of 82 posts

Re: PGP Marks 30th Anniversary

#61
post #60
post #49

Earlier quoted context omitted.

I want to be sure I'm reading this correctly. Failing to decrypt on a single bit error is the literal job definition of authenticated encryption. Any error you accept is malleability conceded to an attacker. Are you complaining that age isn't malleable enough ?

This makes no sense to me. If I run a file through age, and then run that through a Reed-Solomon encoder, I now have a file that can be decoded even with single bit errors. But I think I also still have authenticated encryption. The cost is that my file takes a bit of extra space. Am I missing something?

You are not. Of course, the problem is that PGP doesn't get its informal resilience to single-bit errors through error-correcting codes on the ciphertext.

Re: PGP Marks 30th Anniversary

#63

Earlier quoted context omitted.

What exactly is an OpenPGP recovery property? Can you point it out in the RFC?

OpenPGP specifies cipher feed back (CFB) mode[1] for block ciphers (normally AES). CFB has the inherent property that it is self healing in the face of corruption. It does not work in all possible instances of corruption but it works for the normal sort of corruption that is seen with mass storage devices (multiples of 512 bytes). A practical example here[2]. [1] https://datatracker.ietf.org/doc/html/rfc4880#section-…

I see. You're defining resynchronization of the register during decryption as recovery, not parity checks for recovering corrupted data. Fair enough.

Re: PGP Marks 30th Anniversary

#64
post #8

Earlier quoted context omitted.

What do you recommend as a replacement for PGP? (I'm looking for stand-alone software I can use to encrypt files on storage media, not an encrypted e-mail service.)

The high bit of the right answer to this question is that you don't want to replace PGP; one of the things we've learned in 29 years is that you don't want a single tool to do lots of different cryptographic things, because different applications have different cryptographic needs. For package signing: use something in the signify/minisign family. To encrypt a network transport, use WireGuard. To protect a web transa…

I find "age" a bit awkward when it comes to handling private keys. I want to store my private key files encrypted. If it just would accept private key files that have been encrypted with a passphrase it would be almost perfect.

There are ways to work around this [1], but I'm not happy with any of them.

[1] https://news.ycombinator.com/item?id=24378350

Re: PGP Marks 30th Anniversary

#65
post #8

Earlier quoted context omitted.

What do you recommend as a replacement for PGP? (I'm looking for stand-alone software I can use to encrypt files on storage media, not an encrypted e-mail service.)

The high bit of the right answer to this question is that you don't want to replace PGP; one of the things we've learned in 29 years is that you don't want a single tool to do lots of different cryptographic things, because different applications have different cryptographic needs. For package signing: use something in the signify/minisign family. To encrypt a network transport, use WireGuard. To protect a web transa…

How do you feel about 7zip's AES encryption functionality for files or sets of files?

Re: PGP Marks 30th Anniversary

#66
post #65
post #8

Earlier quoted context omitted.

The high bit of the right answer to this question is that you don't want to replace PGP; one of the things we've learned in 29 years is that you don't want a single tool to do lots of different cryptographic things, because different applications have different cryptographic needs. For package signing: use something in the signify/minisign family. To encrypt a network transport, use WireGuard. To protect a web transa…

How do you feel about 7zip's AES encryption functionality for files or sets of files?

It is maddeningly difficult to simply encrypt a file with interoperable tools. I'm optimistic about age, but it's early days. I understand why people want to use 7z for this. The problem is, if anyone else tries to send you an encrypted zip, and they use something other than 7z, they will likely end up using something even worse than Bass-O-Matic; the zip encryption ecosystem is unbelievably horrible, and it's intractably difficult for ordinary people to know what they're getting. So: long story short, I would tell a client "never, ever use encrypted zips".

Re: PGP Marks 30th Anniversary

#67
post #6

Earlier quoted context omitted.

I'm a huge fan of Phil and his work, and plan to send him a note of thanks, but I think your second sentiment is out-of-date now. Even if we avoid other controversies like Thomas Ptacek's views about the inappropriateness of the e-mail encryption threat model, PGP doesn't support forward secrecy and so it's at least not suitable for instant messaging or TLS (as well as not being integrated into their protocols!). A s…

Forward secrecy is not of any real value in most instances of instant messaging as people usually keep their old messages around thus negating it. Using OpenPGP in the way that TLS is used would negate the advantage of static encryption and would cause the result to be as insecure as TLS. Probably worse as OpenPGP has not required all the band aids that TLS has ended up with.

Encryption is not of any real value if the threat you're describing is 'someone simply has access to all your plaintext messages'. This isn't a meaningful argument against forward secrecy.

Re: PGP Marks 30th Anniversary

#68
post #64
post #8

Earlier quoted context omitted.

The high bit of the right answer to this question is that you don't want to replace PGP; one of the things we've learned in 29 years is that you don't want a single tool to do lots of different cryptographic things, because different applications have different cryptographic needs. For package signing: use something in the signify/minisign family. To encrypt a network transport, use WireGuard. To protect a web transa…

I find "age" a bit awkward when it comes to handling private keys. I want to store my private key files encrypted. If it just would accept private key files that have been encrypted with a passphrase it would be almost perfect. There are ways to work around this [1], but I'm not happy with any of them. [1] https://news.ycombinator.com/item?id=24378350

Good news, everyone!

https://github.com/FiloSottile/age/commit/d164fef036a2d19280...

It will be in the next release candidate.

Re: PGP Marks 30th Anniversary

#69
post #22
post #6

Earlier quoted context omitted.

I'm a huge fan of Phil and his work, and plan to send him a note of thanks, but I think your second sentiment is out-of-date now. Even if we avoid other controversies like Thomas Ptacek's views about the inappropriateness of the e-mail encryption threat model, PGP doesn't support forward secrecy and so it's at least not suitable for instant messaging or TLS (as well as not being integrated into their protocols!). A s…

I've never seen a realistic threat model where Signal-style forward secrecy actually helps. Suppose a repressive regime captured one dissident can see a bunch of messages between them and other people, but theoretically some crypto nerd might have been able to forge those messages if the dissident has been carefully publishing the material they're supposed to publish and the cryptographer decided to run the forgery t…

I'm pretty you're thinking of deniability (from OTR) rather than forward secrecy.

The forward secrecy in protocols like Signal allows for things like disappearing messages, which are then actually technically credible (the sender's and recipient's devices literally don't contain any information which would help to reconstruct the contents of their old messages). I think the former isn't really helpful in your scenario, but the latter is.

Re: PGP Marks 30th Anniversary

#70

Earlier quoted context omitted.

>Failing to decrypt on a single bit error is the literal job definition of authenticated encryption. Yes, this is an excellent example of where this behaviour is suboptimal. We should not cargo cult authenticated encryption. It has its place but this isn't it. > Any error you accept is malleability conceded to an attacker. Sure, but malleability that has a close to zero chance of being a problem. We are talking about…

> Sure, but malleability that has a close to zero chance of being a problem. https://efail.de https://tonyarcieri.com/all-the-crypto-code-youve-ever-writt... This isn't even a controversy among cryptographers or cryptography engineers.

Efail is an excellent example of how the static encryption of OpenPGP used for encrypted email makes malleability irrelevant. To make the Efail attack against OpenPGP work requires the knowledge of the first 11 bytes/characters of the unencrypted message. The attacker would only get one guess. The recipient by necessity would see the attack message and would immediately know there was something going on. As a result the Efail attack against the malleability of OpenPGP is completely impractical.

Contrast the Efail situation with that of TLS. TLS allows almost unlimited secret trials against its cryptography by an attacker. There have been multiple practical attacks based on such oracles in TLS.

>This isn't even a controversy among cryptographers or cryptography engineers.

I would like to think that there were such people out there that understood that different techniques are applicable to different problems.

Post reply on HN