3 ms·
You can find them in the linked specification/design document, but I don’t really believe in putting cryptographic primitives front and center on user facing do
by FiloSottile 5y ago
You can find them in the linked specification/design document, but I don’t really believe in putting cryptographic primitives front and center on user facing documentation.
First, the average user doesn’t actually care that much. Picking algorithms is my job, not theirs. They want to get their task done, so what I need to tell them is what the tool does and what are the security properties, not how it works.
Second, the choice of primitives is a relatively small part of cryptographic design. How you compose them and how it addresses a real use case matters much more. I usually get suspicious when I read “uses AES-256” in marketing copy because, like, it doesn’t tell me _how_ it’s used, and doesn’t seem to think it’s important.
- q-rews 5y agoThat kind of thinking is probably applicable to consumer applications, not for security CLI tools. Anyone deciding to encrypt files with anything other than rar/7z passwords probably wants to know how really secure the tool they’re about to choose is. But I may be wrong.
- technion 5y agoThe vast majority of GPG users weren't aware of the encryption details in use either. As recently as 2018 Redhat 7 users were shipped GnuPG 2.0, which according to [0] defaulted to CAST5. And I've met some of those users that thought they were using AES off the back of "well I used GPG so I assumed...". [0] https://security.stackexchange.com/questions/86305/what-is-the-default-cipher-algorithm-for-gnupg https://security.stackexchange.com/questions/86305/what-is-t...
- petre 5y agoIt is important if the algorithm gets broken or weakened somehow. Also, I was looking for something like this just yesterday. If the algotirhm was clearely displayed in the readme I would have found it with a web search. You made a great choice. Thank you. This tool looks awesome. Can't wait to build it.