5 ms·

Age is great and all but it has a huge footgun. It encourages the user to encrypt material with a public key in a way that is entirely unauthenticated. So an at

Age is great and all but it has a huge footgun. It encourages the user to encrypt material with a public key in a way that is entirely unauthenticated. So an attacker with access to that public key can simply overwrite the file with whatever they want. If ensuring that you end up with the same stuff as you encrypted is important than that can be a big problem. Fixing this involves the use of a separate signing utility and thus introduces an entirely different set of keys for the user to manually manage. By doing the key management for the user, GPG actually ends up being a lot more usable...

e3bc54b2 4y ago
OTOH if you already have another checksumming mechanism in place (oh hello there, git!) age can piggyback off that and ensure there's no switcharoo.
- lijogdfljk 4y ago
  Mind describing (to a layman?) how checksums can help Age prevent switcharoo? I ask because i've been writing a datastore of sorts that's immutable. Ie all content addressed. I plan to add some basic encryption for cloud storage primarily, however if Age could let someone swap file contents then i can't use Age. I know someone's thinking "if it's content addressed how can someone tamper with the file contents?" - they can't, of course, but that only works if you know the HEAD's to point to. If you don't, say you're doing a full recovery, you slurp in all the content IDs and now have to determine which one is the HEAD. This is where tampering could take place, hypothetically, as they could not just swap the file contents but _also_ change the hashes/content IDs. In a content addressed system signing the HEAD is really the only thing needed, since everything else can be validated via checksum. However i think it still needs signing, no? Sidenote, i know next to nothing about crypto practices. I desperately need to find a class which teaches necessary knowledge to use crypto correctly in your own programs.
  - e3bc54b2 4y ago
    Right, I am just as much of a n00b at crypto as next guy/gal, but here's my understanding. GP mentioned that detecting switcheroo is not possible because both original and new secret will be encrypted by the same public key. Until the decrypted secret is actually used, we will not realise it. But, if we track all the changes in git, and have more than one copy (you have them, right?) then it becomes quite easy to detect this. Goes more if git commit access is gated by SSH key or another secret/auth layer. And this, makes detecting and or rolling back a switcheroo possible.
  - bawolff 4y ago
    I think basically - if you already know the file is the correct version, then it must be the correct version, so no need to check again. Which sounds much less impressive when put that way. One way to do this is to hash the file and store that hash somewhere you trust, which i think is what the person is suggesting. This approach has somewhat limited applicability, because if you already have a trusted channel, why are you using cryptography? (Yes there are lots of exceptions to that where crrypto still makes sense, but in general the point stands) > Sidenote, i know next to nothing about crypto practices. I desperately need to find a class which teaches necessary knowledge to use crypto correctly in your own programs. If you like hands on stuff, https://cryptopals.com/ https://cryptopals.com/ has a lot of challenges to help learn stuff. Other than that maybe look into books. When i was trying to learn about this stuff, I liked "Cryptography Engineering" by Ferguson, but that was a while ago no idea if its dated now (also i am definitely an amartur in this so take everything i say with a grain of salt)
    - lijogdfljk 4y ago
      > One way to do this is to hash the file and store that hash somewhere you trust, which i think is what the person is suggesting. This approach has somewhat limited applicability, because if you already have a trusted channel, why are you using cryptography? (Yes there are lots of exceptions to that where crrypto still makes sense, but in general the point stands) Yup. In my case my system is content addressed, so everything is a hash. So one one hand, sign-less encryption will work fine if i know the HEAD hash, as you mentioned. However i also want these backups to work from no local store. Ie i don't know the HEAD, and in that case someone could tamper with my pointer. Kinda surprising that Age doesn't have a way to handle this. Shame, but good to learn. Cryptopals is interesting, appreciate the link! I'll also look into that book, thank you! Did you find the book a bit deep? I have no intention of writing my own crypto, i just want to use it reliably and correctly.
      - bawolff 4y ago
        > Kinda surprising that Age doesn't have a way to handle this. Shame, but good to learn. The big problem is there are no really good ways to deal with this problem fully. If you use digital signatures, you have to have a trusted method of distributing the verification keys. If you have a secure method of distributing keys, you could also just distribute the encrypted file (or its hash) via that secure method. Digital signatures usually work best when you previously had a secure channel but dont anymore (which is actually fairly common). But once you start doing that, often you start to want doing complex key management (e.g. PKI, tofu etc. Who manages the trust store), and how most appropriately to do that can be application specific (lots of tradeoffs and all options suck in different ways). So i kind of get why the author wants people to use a separate tool for that (even if it is a bit of a cop out). > Did you find the book a bit deep? I have no intention of writing my own crypto, i just want to use it reliably and correctly. Its been a while since i read it, but it was mostly about how to use different crypto primitives properly. It was not about how to design a block cipher or anything like that.
kardianos 4y ago
I don't understand how this could be. Can you be concrete or give a link? I would like to understand.
- marcus_cemes 4y ago
  I'm not an expert, but here's my take. The public key is generally not considered a secret and is therefore "less guarded". Anybody with access to the public key is able to encrypt and create legitimate looking files that are indistinguishable from the original files. You can still only decrypt them using the private key, but you can no longer trust the contents of the file as your own. A solution would be to encrypt with the public key, and then _also_ sign with the private key. When reading, you work in reverse order. You verify the signature using the public key, and then decrypt the file using the private key. But then if you're just using both, why not use fast and robust symmetric encryption instead? Not only will decryption be garbage if the file has been tampered with, but you can also create a signature to detect it (HMAC).
  - kardianos 4y ago
    I think I understand what you are saying. For example, if you are using age to send an encrypted email, it is easy to encrypt the body/attachments to multiple recipients with their public keys (maybe published over DNS TXT records). But age doesn't give you a clear way for the recipients to read the message, fetch your private key, and authenticate the message was actually from you.
sixhobbits 4y ago
One of the things I like most about Age is that it made the very deliberate choice to __not__ become a general tool like GPG, and focuses only on one thing: secure encryption. You can read some of the reasoning about specifically not supporting signing as well here [0], but TL;DR -- it's a hard problem and age isn't really designed for communication and doesn't want to become a "a worse version of signal". [0] https://github.com/FiloSottile/age/issues/51 https://github.com/FiloSottile/age/issues/51
- vaylian 4y ago
  I'm familiar with GnuPG and I'm trying to understand how I can actually use age in practice. There doesn't seem to be a good explanation beyond the command line usage. My current understanding based on various pieces across the internet is the following: 1. age has only a single use-case: Encrypting files using public key cryptography or alternatively password-based encryption. 2. It is technically possible to encrypt e-mails with age, but it is not encouraged because the author considers e-mail to be fundamentally broken 3. age should be considered as a part of a wider cryptographic ecosystem. For example, if you need to sign files (or messages), you would reach for a different tool like minisign. I wonder if there is another tool/service that one can use for public key distribution 4. There is currently no tool that tries to combine different modern crypto tools into one big suite. I have no information about what age's author would think about such a tool. 5. age is intended to be minimalistic and therefore less bug-prone/misuse-prone. 6. The author of age talks a lot about forward secrecy. But there is no good explanation on how to manage key pairs over time. Does that sound right?
e12e 4y ago
Wow, I just looked at the issues in the repo, and the position of the developers is indeed that there will be no signing - so you can verify the recipient, but never the sender. So if I have your public key, I can just replace all your backups for example - and age cannot help you detect that. (for the particular use-case of encrypt-to-self, one could use the authenticated symmetric encryption, rather than public key - and assume the pass phrase is kept secret). But then your backup client can both "read and write" your backups - rather than just encrypt (to your public key) and sign (with backup instance private key). So you get.. 30% of the benefits of public key encryption, for 90% of the complexity?
woodruffw 4y ago
I'm not sure I understand this comment: age doesn't have authenticated encryption, but neither does PGP. The closest thing in PGP is the "Modification Detection Code," which is hilariously broken[1]. Edit: On top of that, every PGP implementation that I've ever worked with happily streams unauthenticated, decrypted plaintext before completing MDC verification. [1]: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
- upofadown 4y ago
  It turns out that "The PGP Problem" was simply wrong about the MDC being broken (among other incorrect and misleading arguments)[1]. Note that since PGP addresses offline non-connected media it is simpler to directly authenticate the material. So the sort of thing that is being described here as "authenticated encryption" is not usually relevant[2]. >On top of that, every PGP implementation that I've ever worked with happily streams unauthenticated, decrypted plaintext before completing MDC verification. For offline non-connected media, that is a completely reasonable approach. Not everything works like TLS. [1] https://articles.59.ca/doku.php?id=pgpfan:tpp https://articles.59.ca/doku.php?id=pgpfan:tpp [2] https://articles.59.ca/doku.php?id=pgpfan:authenticated https://articles.59.ca/doku.php?id=pgpfan:authenticated
  - woodruffw 4y ago
    This post doesn't adequately explain how MDC isn't broken: if my PGP implementation gives me unauthenticated data, then I am not doing authenticated encryption no matter what might be smashed onto the end of my ciphertext. Folding authentication into the correctness decryption phase is the only secure and misuse-resistant way to do authenticated encryption; PGP fails to provide either. We can nitpick about the factuality of the "16 bit" claim or the truncation attack (which I believe GPG has since fixed), but neither directly contradicts the above. > Note that since PGP addresses offline non-connected media it is simpler to directly authenticate the material. So the sort of thing that is being described here as "authenticated encryption" is not usually relevant[2]. Okay, but you just pointed to this property as a "huge footgun" in age. Why is it a footgun there, and not in PGP? Besides, this is entirely ignoring actual use patterns: age is intended for offline file encryption, while PGP is used in all kinds of online channels and directly advertises itself as a "toolbox" for any purpose.
jbverschoor 4y ago
Non crypto people shouldn't be doing crypto things
- sascha_sl 4y ago
  Maybe you should look up the main author of age. (Hint: he owns the Go stdlib crypto packages)
  - jbverschoor 4y ago
    Well I'm very sorry, but then it makes even less sense. There's no explanation about the rationale behind why this project exists. The example is nice and everything, but can't i do that with pgp or other projects? Also, what does "age" mean? Impressive background btw, so I'll have to take back my prev. comment, but it's replaced by the current one :-)
pokstad 4y ago
> By doing the key management for the user, GPG actually ends up being a lot more usable... Isn’t that because GPG is a vertically integrated product while age is only trying to provide the foundation for products like gpg? Couldn’t another project accomplish key management so that age is focused on doing one thing very well?
- deleted 4y ago
  [deleted]
benlivengood 4y ago
I was going to agree completely but I think there's a use-case where age can work sensibly; distribute separate public keys to each semi-trusted host to perform its own automated backups. Rotate the keys frequently. There's still a significant advantage over symmetric encryption; the backups themselves will never be readable by an attacker who compromises a semi-trusted host. The reason this scenario makes sense is that even if backups were encrypted and signed with gpg an attacker gaining root access to the semi-trusted host would also have access to its signing key and be able to impersonate it anyway. By only accepting backups from particular hosts based on its currently-valid public key we can avoid the risk of an attacker overwriting arbitrary backups. You're going to be rotating either a gpg signing key or an age public key frequently regardless to reduce the time window when a potential attacker can impersonate a host, so age makes things slightly simpler by avoiding signatures entirely.

e3bc54b2 4y ago

OTOH if you already have another checksumming mechanism in place (oh hello there, git!) age can piggyback off that and ensure there's no switcharoo.

lijogdfljk 4y ago
Mind describing (to a layman?) how checksums can help Age prevent switcharoo? I ask because i've been writing a datastore of sorts that's immutable. Ie all content addressed. I plan to add some basic encryption for cloud storage primarily, however if Age could let someone swap file contents then i can't use Age. I know someone's thinking "if it's content addressed how can someone tamper with the file contents?" - they can't, of course, but that only works if you know the HEAD's to point to. If you don't, say you're doing a full recovery, you slurp in all the content IDs and now have to determine which one is the HEAD. This is where tampering could take place, hypothetically, as they could not just swap the file contents but _also_ change the hashes/content IDs. In a content addressed system signing the HEAD is really the only thing needed, since everything else can be validated via checksum. However i think it still needs signing, no? Sidenote, i know next to nothing about crypto practices. I desperately need to find a class which teaches necessary knowledge to use crypto correctly in your own programs.
- e3bc54b2 4y ago
  Right, I am just as much of a n00b at crypto as next guy/gal, but here's my understanding. GP mentioned that detecting switcheroo is not possible because both original and new secret will be encrypted by the same public key. Until the decrypted secret is actually used, we will not realise it. But, if we track all the changes in git, and have more than one copy (you have them, right?) then it becomes quite easy to detect this. Goes more if git commit access is gated by SSH key or another secret/auth layer. And this, makes detecting and or rolling back a switcheroo possible.
- bawolff 4y ago
  I think basically - if you already know the file is the correct version, then it must be the correct version, so no need to check again. Which sounds much less impressive when put that way. One way to do this is to hash the file and store that hash somewhere you trust, which i think is what the person is suggesting. This approach has somewhat limited applicability, because if you already have a trusted channel, why are you using cryptography? (Yes there are lots of exceptions to that where crrypto still makes sense, but in general the point stands) > Sidenote, i know next to nothing about crypto practices. I desperately need to find a class which teaches necessary knowledge to use crypto correctly in your own programs. If you like hands on stuff, https://cryptopals.com/ https://cryptopals.com/ has a lot of challenges to help learn stuff. Other than that maybe look into books. When i was trying to learn about this stuff, I liked "Cryptography Engineering" by Ferguson, but that was a while ago no idea if its dated now (also i am definitely an amartur in this so take everything i say with a grain of salt)
  - lijogdfljk 4y ago
    > One way to do this is to hash the file and store that hash somewhere you trust, which i think is what the person is suggesting. This approach has somewhat limited applicability, because if you already have a trusted channel, why are you using cryptography? (Yes there are lots of exceptions to that where crrypto still makes sense, but in general the point stands) Yup. In my case my system is content addressed, so everything is a hash. So one one hand, sign-less encryption will work fine if i know the HEAD hash, as you mentioned. However i also want these backups to work from no local store. Ie i don't know the HEAD, and in that case someone could tamper with my pointer. Kinda surprising that Age doesn't have a way to handle this. Shame, but good to learn. Cryptopals is interesting, appreciate the link! I'll also look into that book, thank you! Did you find the book a bit deep? I have no intention of writing my own crypto, i just want to use it reliably and correctly.
    - bawolff 4y ago
      > Kinda surprising that Age doesn't have a way to handle this. Shame, but good to learn. The big problem is there are no really good ways to deal with this problem fully. If you use digital signatures, you have to have a trusted method of distributing the verification keys. If you have a secure method of distributing keys, you could also just distribute the encrypted file (or its hash) via that secure method. Digital signatures usually work best when you previously had a secure channel but dont anymore (which is actually fairly common). But once you start doing that, often you start to want doing complex key management (e.g. PKI, tofu etc. Who manages the trust store), and how most appropriately to do that can be application specific (lots of tradeoffs and all options suck in different ways). So i kind of get why the author wants people to use a separate tool for that (even if it is a bit of a cop out). > Did you find the book a bit deep? I have no intention of writing my own crypto, i just want to use it reliably and correctly. Its been a while since i read it, but it was mostly about how to use different crypto primitives properly. It was not about how to design a block cipher or anything like that.

kardianos 4y ago

I don't understand how this could be. Can you be concrete or give a link? I would like to understand.

marcus_cemes 4y ago
I'm not an expert, but here's my take. The public key is generally not considered a secret and is therefore "less guarded". Anybody with access to the public key is able to encrypt and create legitimate looking files that are indistinguishable from the original files. You can still only decrypt them using the private key, but you can no longer trust the contents of the file as your own. A solution would be to encrypt with the public key, and then _also_ sign with the private key. When reading, you work in reverse order. You verify the signature using the public key, and then decrypt the file using the private key. But then if you're just using both, why not use fast and robust symmetric encryption instead? Not only will decryption be garbage if the file has been tampered with, but you can also create a signature to detect it (HMAC).
- kardianos 4y ago
  I think I understand what you are saying. For example, if you are using age to send an encrypted email, it is easy to encrypt the body/attachments to multiple recipients with their public keys (maybe published over DNS TXT records). But age doesn't give you a clear way for the recipients to read the message, fetch your private key, and authenticate the message was actually from you.

sixhobbits 4y ago

One of the things I like most about Age is that it made the very deliberate choice to __not__ become a general tool like GPG, and focuses only on one thing: secure encryption. You can read some of the reasoning about specifically not supporting signing as well here [0], but TL;DR -- it's a hard problem and age isn't really designed for communication and doesn't want to become a "a worse version of signal". [0] https://github.com/FiloSottile/age/issues/51 https://github.com/FiloSottile/age/issues/51

vaylian 4y ago
I'm familiar with GnuPG and I'm trying to understand how I can actually use age in practice. There doesn't seem to be a good explanation beyond the command line usage. My current understanding based on various pieces across the internet is the following: 1. age has only a single use-case: Encrypting files using public key cryptography or alternatively password-based encryption. 2. It is technically possible to encrypt e-mails with age, but it is not encouraged because the author considers e-mail to be fundamentally broken 3. age should be considered as a part of a wider cryptographic ecosystem. For example, if you need to sign files (or messages), you would reach for a different tool like minisign. I wonder if there is another tool/service that one can use for public key distribution 4. There is currently no tool that tries to combine different modern crypto tools into one big suite. I have no information about what age's author would think about such a tool. 5. age is intended to be minimalistic and therefore less bug-prone/misuse-prone. 6. The author of age talks a lot about forward secrecy. But there is no good explanation on how to manage key pairs over time. Does that sound right?

e12e 4y ago

Wow, I just looked at the issues in the repo, and the position of the developers is indeed that there will be no signing - so you can verify the recipient, but never the sender. So if I have your public key, I can just replace all your backups for example - and age cannot help you detect that. (for the particular use-case of encrypt-to-self, one could use the authenticated symmetric encryption, rather than public key - and assume the pass phrase is kept secret). But then your backup client can both "read and write" your backups - rather than just encrypt (to your public key) and sign (with backup instance private key). So you get.. 30% of the benefits of public key encryption, for 90% of the complexity?

woodruffw 4y ago

I'm not sure I understand this comment: age doesn't have authenticated encryption, but neither does PGP. The closest thing in PGP is the "Modification Detection Code," which is hilariously broken[1]. Edit: On top of that, every PGP implementation that I've ever worked with happily streams unauthenticated, decrypted plaintext before completing MDC verification. [1]: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html https://latacora.micro.blog/2019/07/16/the-pgp-problem.html

upofadown 4y ago
It turns out that "The PGP Problem" was simply wrong about the MDC being broken (among other incorrect and misleading arguments)[1]. Note that since PGP addresses offline non-connected media it is simpler to directly authenticate the material. So the sort of thing that is being described here as "authenticated encryption" is not usually relevant[2]. >On top of that, every PGP implementation that I've ever worked with happily streams unauthenticated, decrypted plaintext before completing MDC verification. For offline non-connected media, that is a completely reasonable approach. Not everything works like TLS. [1] https://articles.59.ca/doku.php?id=pgpfan:tpp https://articles.59.ca/doku.php?id=pgpfan:tpp [2] https://articles.59.ca/doku.php?id=pgpfan:authenticated https://articles.59.ca/doku.php?id=pgpfan:authenticated
- woodruffw 4y ago
  This post doesn't adequately explain how MDC isn't broken: if my PGP implementation gives me unauthenticated data, then I am not doing authenticated encryption no matter what might be smashed onto the end of my ciphertext. Folding authentication into the correctness decryption phase is the only secure and misuse-resistant way to do authenticated encryption; PGP fails to provide either. We can nitpick about the factuality of the "16 bit" claim or the truncation attack (which I believe GPG has since fixed), but neither directly contradicts the above. > Note that since PGP addresses offline non-connected media it is simpler to directly authenticate the material. So the sort of thing that is being described here as "authenticated encryption" is not usually relevant[2]. Okay, but you just pointed to this property as a "huge footgun" in age. Why is it a footgun there, and not in PGP? Besides, this is entirely ignoring actual use patterns: age is intended for offline file encryption, while PGP is used in all kinds of online channels and directly advertises itself as a "toolbox" for any purpose.

jbverschoor 4y ago

Non crypto people shouldn't be doing crypto things

sascha_sl 4y ago
Maybe you should look up the main author of age. (Hint: he owns the Go stdlib crypto packages)
- jbverschoor 4y ago
  Well I'm very sorry, but then it makes even less sense. There's no explanation about the rationale behind why this project exists. The example is nice and everything, but can't i do that with pgp or other projects? Also, what does "age" mean? Impressive background btw, so I'll have to take back my prev. comment, but it's replaced by the current one :-)

pokstad 4y ago

> By doing the key management for the user, GPG actually ends up being a lot more usable... Isn’t that because GPG is a vertically integrated product while age is only trying to provide the foundation for products like gpg? Couldn’t another project accomplish key management so that age is focused on doing one thing very well?

deleted 4y ago
[deleted]

benlivengood 4y ago

I was going to agree completely but I think there's a use-case where age can work sensibly; distribute separate public keys to each semi-trusted host to perform its own automated backups. Rotate the keys frequently. There's still a significant advantage over symmetric encryption; the backups themselves will never be readable by an attacker who compromises a semi-trusted host. The reason this scenario makes sense is that even if backups were encrypted and signed with gpg an attacker gaining root access to the semi-trusted host would also have access to its signing key and be able to impersonate it anyway. By only accepting backups from particular hosts based on its currently-valid public key we can avoid the risk of an attacker overwriting arbitrary backups. You're going to be rotating either a gpg signing key or an age public key frequently regardless to reduce the time window when a potential attacker can impersonate a host, so age makes things slightly simpler by avoiding signatures entirely.