4 ms·

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.
      - lijogdfljk 4y ago
        > If you have a secure method of distributing keys, you could also just distribute the encrypted file (or its hash) via that secure method. Well in my case the central thing is mutable, changing. Ie it's a pointer to the HEAD, in git terms. So yes, i have to distribute keys but the keys are immutable and can be distributed. The HEAD however can't, or at least can't with assurances that it's trusted. Which is kinda the root issue i suppose. To answer the question of "the file on S3 is mutable, did i actually write it?". I have to be able to answer that > 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. That actually sounds great. Definitely interested, thank you!

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.
    - lijogdfljk 4y ago
      > If you have a secure method of distributing keys, you could also just distribute the encrypted file (or its hash) via that secure method. Well in my case the central thing is mutable, changing. Ie it's a pointer to the HEAD, in git terms. So yes, i have to distribute keys but the keys are immutable and can be distributed. The HEAD however can't, or at least can't with assurances that it's trusted. Which is kinda the root issue i suppose. To answer the question of "the file on S3 is mutable, did i actually write it?". I have to be able to answer that > 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. That actually sounds great. Definitely interested, thank you!