4 ms·

One thing I miss and would imagine probably front and center of an encryption tool, is the algorithm(s) it's using to encrypt. There are multiple mentions of ke

One thing I miss and would imagine probably front and center of an encryption tool, is the algorithm(s) it's using to encrypt. There are multiple mentions of keys, but not the encryption mechanism itself. I've been roaming around the doc for that but couldn't find anything. Is there any pointer to that?

ameliaquining 5y ago
Specification of the format is at https://docs.google.com/document/d/11yHom20CrsuX8KQJXBBw04s80Unjv8zCg_A7sPAX_9Y/preview https://docs.google.com/document/d/11yHom20CrsuX8KQJXBBw04s8... and includes all the cryptographic primitives that it uses. TL;DR: Mostly the djb stack.
- petre 5y ago
  ChaCha20-Poly1305, great. Thank you, I was looking for the algorithm. Just found a similar tool called hpenc[1], written in C++11 with libsodium yesterday. It uses AES-GCM or ChaCha20 to encrypt files and streams. But this is even better as it's more ergonomic, drop in, I don't have to worry about dependencies and it does much more, like encrypt using ssh or gpg keys. https://github.com/vstakhov/hpenc https://github.com/vstakhov/hpenc
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 ago
  That 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 ago
    The 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 ago
  It 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.

ameliaquining 5y ago

Specification of the format is at https://docs.google.com/document/d/11yHom20CrsuX8KQJXBBw04s80Unjv8zCg_A7sPAX_9Y/preview https://docs.google.com/document/d/11yHom20CrsuX8KQJXBBw04s8... and includes all the cryptographic primitives that it uses. TL;DR: Mostly the djb stack.

petre 5y ago
ChaCha20-Poly1305, great. Thank you, I was looking for the algorithm. Just found a similar tool called hpenc[1], written in C++11 with libsodium yesterday. It uses AES-GCM or ChaCha20 to encrypt files and streams. But this is even better as it's more ergonomic, drop in, I don't have to worry about dependencies and it does much more, like encrypt using ssh or gpg keys. https://github.com/vstakhov/hpenc https://github.com/vstakhov/hpenc

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 ago
That 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 ago
  The 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 ago
It 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.