4 ms·

The library is openssl and that comes with all these ciphers available. No other reason than because we can! I wish AES-GCM was available...but openssl can't d

The library is openssl and that comes with all these ciphers available. No other reason than because we can! I wish AES-GCM was available...but openssl can't do it on its own without further dependencies to parse the authentication correctly. Really this whole layer is complelty redundant actually. It's already E2EE without openssl via Tor. I like that it's encrypted before I hit the network pipe though.

lxgr 8mo ago
> No other reason than because we can! Then maybe your scientists should spend some time to stop and consider whether they should ;) But seriously, I'd just limit this to one option on the selection side, even if you continue supporting more than that at the protocol level for cryptographic agility.
- Bender 8mo ago
  I would rather avoid cipher fixation. Give me thousands of protocol / cipher / mac / mode combinations. Fixation only benefits nations wanting to crack something.
  - deleted 8mo ago
    [deleted]
  - inigyou 8mo ago
    Agility benefits nations wanting to crack something, because they can force you to pick an insecure combination. This has happened in the real world several times before.
    - Bender 8mo ago
      And what they will get is "haha! It was only 230 hours and we cracked their ... oh, there's another dozen sparse files inside that and it's a different combo..." I can automate encrypted sparse files all the way down each showing a size between 5PB and 40PB which a lot of forensic software will try to copy as a non sparse file.
- fc417fc802 8mo ago
  I don't see the issue. "Anything that openssl actively supports" plus providing a default seems like an extremely reasonable stance to take.
  - lxgr 8mo ago
    “Supported by OpenSSL” is not a seal of quality in any sense. It still supports a bunch of outdated crap including (on my system) RC4, RC2(!) and DES (yes, the 56 bit key one, not just 3DES).
    - fc417fc802 8mo ago
      Fair point. But what I'm getting at is that if you aren't an expert on cryptography (and perhaps even if you are!) rather than imposing your personal preferences on others simply deferring to a trusted third party library can make a lot of sense. So in addition to a sensible default I guess it would also be a good idea to tag choices that you believe to be outdated with a large warning. That way you haven't rolled your own crypto, you haven't forced your views on others, but you have done your best to enable end users to operate your tool in a sensible manner.
  - xnyan 8mo ago
    >reasonable stance Within the last 12 months, I had to write a script for a buddy at work that turned off availability of freaking freaking 56 bit DES in OpenSSH, which was available because was provided by openssl. I'm certain it was still there to provide compatibility for something(s) critical out there that depends on it, and while I can't imagine why anybody would choose to use it, it's there and it's awful.
inigyou 8mo ago
If a library doesn't do what you need, you need a different library, but this is impossible from a short bash script, so it's one of the tradeoffs of your design.
john_strinlai 8mo ago
>No other reason than because we can! great attitude for approximately everything except, perhaps, cryptography. especially since the initial encryption is mostly redundant, i would encourage that you, at some point, consider reducing the number of ciphers.

lxgr 8mo ago

> No other reason than because we can! Then maybe your scientists should spend some time to stop and consider whether they should ;) But seriously, I'd just limit this to one option on the selection side, even if you continue supporting more than that at the protocol level for cryptographic agility.

Bender 8mo ago
I would rather avoid cipher fixation. Give me thousands of protocol / cipher / mac / mode combinations. Fixation only benefits nations wanting to crack something.
- deleted 8mo ago
  [deleted]
- inigyou 8mo ago
  Agility benefits nations wanting to crack something, because they can force you to pick an insecure combination. This has happened in the real world several times before.
  - Bender 8mo ago
    And what they will get is "haha! It was only 230 hours and we cracked their ... oh, there's another dozen sparse files inside that and it's a different combo..." I can automate encrypted sparse files all the way down each showing a size between 5PB and 40PB which a lot of forensic software will try to copy as a non sparse file.
fc417fc802 8mo ago
I don't see the issue. "Anything that openssl actively supports" plus providing a default seems like an extremely reasonable stance to take.
- lxgr 8mo ago
  “Supported by OpenSSL” is not a seal of quality in any sense. It still supports a bunch of outdated crap including (on my system) RC4, RC2(!) and DES (yes, the 56 bit key one, not just 3DES).
  - fc417fc802 8mo ago
    Fair point. But what I'm getting at is that if you aren't an expert on cryptography (and perhaps even if you are!) rather than imposing your personal preferences on others simply deferring to a trusted third party library can make a lot of sense. So in addition to a sensible default I guess it would also be a good idea to tag choices that you believe to be outdated with a large warning. That way you haven't rolled your own crypto, you haven't forced your views on others, but you have done your best to enable end users to operate your tool in a sensible manner.
- xnyan 8mo ago
  >reasonable stance Within the last 12 months, I had to write a script for a buddy at work that turned off availability of freaking freaking 56 bit DES in OpenSSH, which was available because was provided by openssl. I'm certain it was still there to provide compatibility for something(s) critical out there that depends on it, and while I can't imagine why anybody would choose to use it, it's there and it's awful.

inigyou 8mo ago

If a library doesn't do what you need, you need a different library, but this is impossible from a short bash script, so it's one of the tradeoffs of your design.

john_strinlai 8mo ago

>No other reason than because we can! great attitude for approximately everything except, perhaps, cryptography. especially since the initial encryption is mostly redundant, i would encourage that you, at some point, consider reducing the number of ciphers.