5 ms·

I am usually on the side of “Don’t roll your own crypto” being gatekeeping (at least more than the average engineer), but this kind of project with no notes on

I am usually on the side of “Don’t roll your own crypto” being gatekeeping (at least more than the average engineer), but this kind of project with no notes on threat model, experimental status, authors and reviewers is a real problem. From a quick read of the README, which is not a rigorous description of the design (what does “computed from the cryptological digest” mean?), it seems this offers no authentication, fails completely if an attacker can observe the same file at two points in time, and there is no analysis of how big a tree can get before the chance of at least one directory having two files with the same nonce becoming significant. However, it’s presented without caveats, and there’s no way for non-practitioners to assess whether it’s fit for their purposes. Users might be led to think this is usable in the same scenarios as, say, gocryptfs, when if fact it’s completely insecure for real world use cases like encrypting a home directory to sync it on Dropbox.

aegistudio 4y ago
May I repeat your statements in my words, so that we can have understanding in common and communicate efficiently? 1. Elaborated and formalized description about encryption method is required. 2. Processes need to be authenticated before they could access ciphertext / plaintext directory, so that they can't recover the key stream. 3. On encrypting the file names, the threshold of directory tree size for the birthday attack to become innegligible, should also be elaborated.
- dhaavi 4y ago
  I recommend reading Cryptography Engineering [0] and then re-evaluating the design and then get it audited. I took that path and I learned a ton and still had (some smaller) issues in the audit. [0] https://www.schneier.com/books/cryptography-engineering/ https://www.schneier.com/books/cryptography-engineering/
  - aegistudio 4y ago
    Sure. Thanks for the reference.
  - FiloSottile 4y ago
    Cryptography Engineering was great for its time but has been outdated for years, which in cryptography doesn’t mean “lacks fancy new stuff” but “we learned the hard way to do things differently”. Serious Cryptography and Real World Cryptography are commonly mentioned as successors.
    - PYTHONDJANGO 4y ago
      You forgot to mention a better source - please be constructive, thanks.
    - dhaavi 4y ago
      Thanks. Was not aware of that. I bought/read it in 2015, I think. I'll check out Serious Cryptography - just found out that I already have it! I like JP's approach to things and his bold thinking.
- FiloSottile 4y ago
  (1) and (3), yes. (2) is not about process authentication but about using authenticated encryption that detects tampering. More broadly, there needs to be a threat model that states what your attacker is capable of. Even more broadly, I get the impression you’re not an experienced cryptography engineer and you didn’t work with one. Learning is great, but this is not presented with any warnings, which is irresponsible.
  - aegistudio 4y ago
    You are right. I don't come with cryptography background and haven't consider the attack model carefully. I will warn the users about the current status and strive to design it to confront potential attacks.
    - shiittile 4y ago
      [flagged]
      - aae42 4y ago
        Just wanted to note that while the posts were terse, I can't say I would consider them arrogant or non constructive. If I were the author of Enigma I'd be thrilled to get feedback from Filippo. Also, it seems immediately constructive just from the reply you replied to. That said, I kind of have to agree, "you don't know what you don't know" often holds true in the matter of cryptography, and failure tends to be pretty damaging to the user. Actually, not posting a disclaimer when trying to solve a difficult problem as an amateur might be what should be considered arrogant.
dhaavi 4y ago
This. Sad, I can only upvote once.
throwaway0x7E6 4y ago
>Don’t roll your own crypto as far as I can tell, they're neither inventing their own algorithms nor implementing existing algorithms from scratch. that's what "Don't roll your own crypto" supposed to mean, not "just use Bitlocker"
- FiloSottile 4y ago
  Well, I (and most security and cryptography experts I discussed this with) disagree, and I don’t think we’re going to find a canonical source for what the warning is supposed to mean. Its broader version that includes protocols and formats easily applies here (although is also arguably defeated because it didn’t stop this project from being published without caveats and making it to the HN front page). We had a discussion about this with tptacek on his podcast. https://securitycryptographywhatever.buzzsprout.com/1822302/8953842-the-great-roll-your-own-crypto-debate-with-filippo-valsorda https://securitycryptographywhatever.buzzsprout.com/1822302/...
  - tialaramex 4y ago
    I should probably listen to that podcast, but to me the "It's gatekeeping" thing is entirely annulled by experiences like this HN post. If I went a few years without seeing people ignorantly doing this I would re-think my stance, but I don't think I ever go more than a few months and I'm not paying that close attention. I feel like it belongs in the same category as "Don't eat wild mushrooms". I know some people who are really interested in fungi and they definitely don't see this as gatekeeping, they see it as fewer dead people. Bad cryptography is less immediately deadly than eating the wrong mushroom, but on the other hand even tremendous incompetence (e.g. feed housemates delicious mushroom soup you made, oops that was poison, they're all hospitalised) has narrower consequences than for software which can trivially be spread to millions of people. I wrote some crypto example software as a demo for an acquaintance (I was going to write "friend", but given subsequent events lets go with "acquaintance") last century, and I made sure to cover it in "Not for production use" warnings, but how sure can I ever be that the warnings were still on it when anybody else saw it ? Perhaps I should rather have said "No".
- st_goliath 4y ago

aegistudio 4y ago

May I repeat your statements in my words, so that we can have understanding in common and communicate efficiently? 1. Elaborated and formalized description about encryption method is required. 2. Processes need to be authenticated before they could access ciphertext / plaintext directory, so that they can't recover the key stream. 3. On encrypting the file names, the threshold of directory tree size for the birthday attack to become innegligible, should also be elaborated.

dhaavi 4y ago
I recommend reading Cryptography Engineering [0] and then re-evaluating the design and then get it audited. I took that path and I learned a ton and still had (some smaller) issues in the audit. [0] https://www.schneier.com/books/cryptography-engineering/ https://www.schneier.com/books/cryptography-engineering/
- aegistudio 4y ago
  Sure. Thanks for the reference.
- FiloSottile 4y ago
  Cryptography Engineering was great for its time but has been outdated for years, which in cryptography doesn’t mean “lacks fancy new stuff” but “we learned the hard way to do things differently”. Serious Cryptography and Real World Cryptography are commonly mentioned as successors.
  - PYTHONDJANGO 4y ago
    You forgot to mention a better source - please be constructive, thanks.
  - dhaavi 4y ago
    Thanks. Was not aware of that. I bought/read it in 2015, I think. I'll check out Serious Cryptography - just found out that I already have it! I like JP's approach to things and his bold thinking.
FiloSottile 4y ago
(1) and (3), yes. (2) is not about process authentication but about using authenticated encryption that detects tampering. More broadly, there needs to be a threat model that states what your attacker is capable of. Even more broadly, I get the impression you’re not an experienced cryptography engineer and you didn’t work with one. Learning is great, but this is not presented with any warnings, which is irresponsible.
- aegistudio 4y ago
  You are right. I don't come with cryptography background and haven't consider the attack model carefully. I will warn the users about the current status and strive to design it to confront potential attacks.
  - shiittile 4y ago
    [flagged]
    - aae42 4y ago
      Just wanted to note that while the posts were terse, I can't say I would consider them arrogant or non constructive. If I were the author of Enigma I'd be thrilled to get feedback from Filippo. Also, it seems immediately constructive just from the reply you replied to. That said, I kind of have to agree, "you don't know what you don't know" often holds true in the matter of cryptography, and failure tends to be pretty damaging to the user. Actually, not posting a disclaimer when trying to solve a difficult problem as an amateur might be what should be considered arrogant.

dhaavi 4y ago

This. Sad, I can only upvote once.

throwaway0x7E6 4y ago

>Don’t roll your own crypto as far as I can tell, they're neither inventing their own algorithms nor implementing existing algorithms from scratch. that's what "Don't roll your own crypto" supposed to mean, not "just use Bitlocker"

FiloSottile 4y ago
Well, I (and most security and cryptography experts I discussed this with) disagree, and I don’t think we’re going to find a canonical source for what the warning is supposed to mean. Its broader version that includes protocols and formats easily applies here (although is also arguably defeated because it didn’t stop this project from being published without caveats and making it to the HN front page). We had a discussion about this with tptacek on his podcast. https://securitycryptographywhatever.buzzsprout.com/1822302/8953842-the-great-roll-your-own-crypto-debate-with-filippo-valsorda https://securitycryptographywhatever.buzzsprout.com/1822302/...
- tialaramex 4y ago
  I should probably listen to that podcast, but to me the "It's gatekeeping" thing is entirely annulled by experiences like this HN post. If I went a few years without seeing people ignorantly doing this I would re-think my stance, but I don't think I ever go more than a few months and I'm not paying that close attention. I feel like it belongs in the same category as "Don't eat wild mushrooms". I know some people who are really interested in fungi and they definitely don't see this as gatekeeping, they see it as fewer dead people. Bad cryptography is less immediately deadly than eating the wrong mushroom, but on the other hand even tremendous incompetence (e.g. feed housemates delicious mushroom soup you made, oops that was poison, they're all hospitalised) has narrower consequences than for software which can trivially be spread to millions of people. I wrote some crypto example software as a demo for an acquaintance (I was going to write "friend", but given subsequent events lets go with "acquaintance") last century, and I made sure to cover it in "Not for production use" warnings, but how sure can I ever be that the warnings were still on it when anybody else saw it ? Perhaps I should rather have said "No".
st_goliath 4y ago