4 ms·

Some (hopefully constructive) criticism: "Easy installation. Grab the binary and you're ready to go." Is putting the binary in the PATH really more user friend

Some (hopefully constructive) criticism: "Easy installation. Grab the binary and you're ready to go." Is putting the binary in the PATH really more user friendly than what's available in the package manager? Security updates and so on seems like a nightmare with that setup, and for something this important not an option for me. Since your target audience are people who can't wrap their heads around normal gpg can you expect them to know what the PATH is and how to figure it out? My first months on linux I didn't know what it was. Reading through the README I don't really understand what is supposed to be easier compared to GnuPG. First I thought it could be verbosity but GnuPG has -d/-e flags if you prefer. Some comparisons could be useful I'm probably missing something. That said I don't think encryption intended for engineers should be simplified, if they don't understand what they're doing it's a footgun. Do you want users asking you to recover their private keys? Instead of hiding the "words, concepts and commands" try to make them easier to understand. Also, you have a typo on #4, `env version` should be `enc`.

Hendrikto 4y ago
> That said I don't think encryption intended for engineers should be simplified, if they don't understand what they're doing it's a footgun. By that logic, you should be working out your signatures with pen and paper. Everything done manually has the potential for errors. If something can be simplified and/or automated, it is often a huge security benefit.
- worksonmine 4y ago
  You're missing my point. I'm not saying it should be difficult either, but is GnuPG really that difficult? Is --sign/--verify, --encrypt/--decrypt overly complex, and how does this tool improve on that? Should the users understand when to use symmetric vs asymmetric encryption? Is it important to know the difference between public and private keys? I just fail to see where and how this tool improves, what steps are removed compared to the flags I listed? Is it the lack of dashes? The pen and paper straw man doesn't answer my questions.
  - Hendrikto 4y ago
    > The pen and paper straw man doesn't answer my questions. I quoted the part of your comment I replied to. That part was no question. It was the claim that cryptography should not be made simpler. I strongly disagree with that point. That has nothing to do with the specific tool at hand. It is irrelevant how and whether it simplifies things, if you claim that the premise is wrong.
    - worksonmine 4y ago
      > I quoted the part of your comment I replied to. That part was no question. You did, but the next sentence you conveniently left out however is a question: "Do you want users asking you to recover their private keys?" Together in their context they make my point. The so called complexity is a result of the features. If you want simple E2EE chat-like encryption you can have that, but then you need to manage your users keys and so on. And that's a valid use, but is it for engineers? As soon as functionality other than simple E2EE enters the picture explaining the concepts becomes a necessity. To put it another way, I don't think it can be simplified without sacrificing security (for the user and their data) or features. It is important to understand how it works, but not necessarily being able to explain the algorithms.

Hendrikto 4y ago

> That said I don't think encryption intended for engineers should be simplified, if they don't understand what they're doing it's a footgun. By that logic, you should be working out your signatures with pen and paper. Everything done manually has the potential for errors. If something can be simplified and/or automated, it is often a huge security benefit.

worksonmine 4y ago
You're missing my point. I'm not saying it should be difficult either, but is GnuPG really that difficult? Is --sign/--verify, --encrypt/--decrypt overly complex, and how does this tool improve on that? Should the users understand when to use symmetric vs asymmetric encryption? Is it important to know the difference between public and private keys? I just fail to see where and how this tool improves, what steps are removed compared to the flags I listed? Is it the lack of dashes? The pen and paper straw man doesn't answer my questions.
- Hendrikto 4y ago
  > The pen and paper straw man doesn't answer my questions. I quoted the part of your comment I replied to. That part was no question. It was the claim that cryptography should not be made simpler. I strongly disagree with that point. That has nothing to do with the specific tool at hand. It is irrelevant how and whether it simplifies things, if you claim that the premise is wrong.
  - worksonmine 4y ago
    > I quoted the part of your comment I replied to. That part was no question. You did, but the next sentence you conveniently left out however is a question: "Do you want users asking you to recover their private keys?" Together in their context they make my point. The so called complexity is a result of the features. If you want simple E2EE chat-like encryption you can have that, but then you need to manage your users keys and so on. And that's a valid use, but is it for engineers? As soon as functionality other than simple E2EE enters the picture explaining the concepts becomes a necessity. To put it another way, I don't think it can be simplified without sacrificing security (for the user and their data) or features. It is important to understand how it works, but not necessarily being able to explain the algorithms.