Live data from Hacker News

Age and Authenticated Encryption

words.filippo.io

1–10 of 20 posts

Re: Age and Authenticated Encryption

#3
Another signcryption scheme as described in the article is also implemented by the libsodium author as an extension:

https://github.com/jedisct1/libsodium-signcryption

It's unclear from the article if this is the same implementation age uses.

Signcryption schemes are also a good candidate algorithm for replacing JWTs and PASETO as they suffer from no algorithm confusion, and don't need what PASETO calls "Algorithm Lucidity" and serve both plaintext authentication, authenticated encryption, sender receiver verification, and shared key generation that can be used for unlimited encrypted streaming, for example with libsodium's crypto_secretstream API.

https://doc.libsodium.org/secret-key_cryptography/secretstre...

https://github.com/paseto-standard/paseto-spec/blob/master/d...

Re: Age and Authenticated Encryption

#4
post #2

I remain unconvinced by their arguments on this, and so will keep using good old reliable `gpg -se`.

Is there a specific argument you found unconvincing? I thought this was a very well-written summary of (1) why age doesn't provide authenticated encryption by default, (2) how you can do authenticated encryption with age, and (3) why age won't make "simple" authenticated encryption simpler.

Edit: I forgot to point out: GPG does sign-then-encrypt, which has a potential failure mode that the post notes (i.e., that your recipient retains your signature, and can encrypt-and-forward it to any additional recipient they please.)

Re: Age and Authenticated Encryption

#5
post #2

I remain unconvinced by their arguments on this, and so will keep using good old reliable `gpg -se`.

Is there a specific argument you found unconvincing? I thought this was a very well-written summary of (1) why age doesn't provide authenticated encryption by default, (2) how you can do authenticated encryption with age, and (3) why age won't make "simple" authenticated encryption simpler. Edit: I forgot to point out: GPG does sign-then-encrypt, which has a potential failure mode that the post notes (i.e., that your…

>...that your recipient retains your signature, and can encrypt-and-forward it to any additional recipient they please.

So just like signatures made on paper? You can take a signed paper document and put it in an envelope and send it anywhere you want. What is wrong with that? It is what someone living in this world would normally expect. We need more things that work as expected, not less...

Re: Age and Authenticated Encryption

#6

Earlier quoted context omitted.

Is there a specific argument you found unconvincing? I thought this was a very well-written summary of (1) why age doesn't provide authenticated encryption by default, (2) how you can do authenticated encryption with age, and (3) why age won't make "simple" authenticated encryption simpler. Edit: I forgot to point out: GPG does sign-then-encrypt, which has a potential failure mode that the post notes (i.e., that your…

>...that your recipient retains your signature, and can encrypt-and-forward it to any additional recipient they please. So just like signatures made on paper? You can take a signed paper document and put it in an envelope and send it anywhere you want. What is wrong with that? It is what someone living in this world would normally expect. We need more things that work as expected, not less...

In most countries that's called "forgery." You can't pass of someone's signature, even if it's authentic, in a context they did not intend.

(It should be obvious why it's illegal, and what's wrong with it -- nobody wants bank accounts opened in their name by unrelated parties. You should then be able to reason by parallel as to why it's not a desirable property in a cryptosystem.)

Re: Age and Authenticated Encryption

#7
This is very interesting, thanks for sharing!

I have considered switching from GPG to age quite a lot, but I mostly use GPG for file encryption so this issue was a deal breaker for me. I did consider signing the encrypted backups with minisign, but then I needed two unrelated key pairs to safely access my backups instead of just one.

Re: Age and Authenticated Encryption

#9
The hypothetical I want to pose people is, let's say your server is corrupted or I.pacted by ransomware. So you pull your gpg backups and hit restore. The data somehow looks correct and in line with expectations, but the signature fails to verify.

You can say 'well I know there was tampering, or possible one bit of bitrot' but then what? Let's say my backup was a poatgresql backup that restored correctly and had no obvious issues.

People often state backups mist be signed but just not sure how you would even respond. You cannot just not use the backup if all your backups are the same and you just had an incident. You could say "now we don't trust the data" but again what is meaningful action here?

Is it really a plausible threat that an attacker wiped put production, gained access to your backup infrastructure, but instead of just wiping it in order to force you to pay a ransom they took a new backup and quietly modified it? Surely such a person would just modify production if they wanted such a game.

Re: Age and Authenticated Encryption

#10
post #9

The hypothetical I want to pose people is, let's say your server is corrupted or I.pacted by ransomware. So you pull your gpg backups and hit restore. The data somehow looks correct and in line with expectations, but the signature fails to verify. You can say 'well I know there was tampering, or possible one bit of bitrot' but then what? Let's say my backup was a poatgresql backup that restored correctly and had no o…

Huh? What's your concern? Yeah there was tempering, good idea you signed. Maybe go freeze your credit? I don't know, you tell me?
Post reply on HN