6 ms·

I always wonder who's watching the watchers with encryption. I know there are standard, recommended libraries available. But how are those vetted if mere mortal

by uticus 3y ago

I always wonder who's watching the watchers with encryption. I know there are standard, recommended libraries available. But how are those vetted if mere mortals like myself don't even know what known vulnerabilities to look for? Is there like a high council of crypto wizards that keep checks and balances on each other?

sacrosanct 3y ago
As a rule of thumb, pay attention to crypto parameters and cipher 'suites'. Use the highest SHA, use seven word diceware phrases for the password, ensure the latest TLS version is used, use a reputable & robust RNG, etc
- tptacek 3y ago
  SHA2 is fine. The "reputable" RNG comes with your OS; just use getrandom.
  - tialaramex 3y ago
    If you don't know what you're doing SHA-512/256 (note that's not a choice, that's the name of a single SHA-2 family member) is probably the member of the SHA-2 family to choose.
    - tptacek 3y ago
      I go the other way and tell people to ignore KMAC and just use HMAC for everything, and then you don't really need to know about truncated SHA2.
      - tialaramex 3y ago
        Fair, I have no experience with which approach is more likely to prevent naive users from blowing their own feet off in practice.
        tptacek 3y ago
        My feeling is that like in 2001 it would have been valuable to get people to switch to a non-extendable hash by default because people were freelancing their own MACs, but sometime in the intervening 2 decades people switched fully over to HMAC, so that if you're dealing with someone who is literally writing their own prefixed key hash MAC, you've got bigger problems than Merkle Damgard.
Buttons840 3y ago
Whenever I'm roleplaying with my tinfoil hat, I say that the NSA is behind the "never implement your own crypto" advice. If you're really worried, roll your own encryption, and then also run the encrypted message through standard encryption implementations. After all, if the standard implementations work, it doesn't matter if you mess up your own crypto implementation, because the standard implementation is unbreakable.
- Analemma_ 3y ago
  Whenever I'm roleplaying with my tinfoil hat, I say that the NSA is behind comments like yours. You cannot assume that the security of a composite crypotsystem is max(system1, ..., systemN), i.e. that bolting a secure system to an insecure one is at least as secure as the most secure system. Sometimes it is; sometimes it is not and the insecure system breaks the whole thing in a way that casual analysis can't spot. If I were the NSA trying to inject memes into the software ecosystem to make my job easier, I would definitely recommend that everybody start with vetted open-source cryptosystems and then bolt their hand-rolled crap to them.
  - Buttons840 3y ago
    If it's true that modifying my plaintext before putting it through a standard encryption algorithm might affect the security, then it might also be possible that sending, say, an HTML payload is more secure than sending a JSON payload. That would be weird. Can existing encryption algorithms encrypt any payload or can't they? It would be odd if we're worrying about timing attacks, etc, when we can't even securely encrypt any possible plaintext first.
    - kwantam 3y ago
      Yes, a correct encryption algorithm can encrypt (essentially) any bit string. But it's quite easy to turn a correct encryption algorithm into an incorrect one by bolting on something seemingly innocuous. Here's a concrete example. Let's say you decide you want to make AES encryption more efficient by defining a new standard, "lzAES", that is just: Enc_lz(key, msg) := AES-Encrypt(key, lzw_compress(msg)) Dec_lz(key, ctxt) := lzw_decompress(AES-Decrypt(key, ctxt)) This "works", in the sense that you can correctly decrypt ciphertexts, and it certainly seems innocuous. But it is now an insecure cipher! Here's why: the definition of a secure cipher is that ciphertexts resulting from the encryptions of any two messages of equal length are indistinguishable. In other words, for any two messages you can choose, if I encrypt both messages under a randomly generated key, you can't tell which ciphertext corresponds to which message. In contrast, lzAES as defined above does not have this property: you could choose one message that's easily compressible (say, a string of zeros) and one that's not (say, a uniformly random string), and then you'd be able to tell which ciphertext corresponds to which plaintext just by looking at the ciphertext lengths. And this is not just a definitional issue! If you use lzAES to encrypt something, an attacker can guess your message and test whether compressing the guess gives the same length as your ciphertext. Guess-and-check isn't possible with a secure cipher, but it is with lzAES---in other words, it gives away information about your plaintext!
tptacek 3y ago
Cryptography engineers and vulnerability researchers who specialize in cryptography look for vulnerabilities in the popular libraries. Cryptographic vulnerabilities are high-status (if you find a pattern of them, you can even get published in the Big 4 academic venues). So there's a lot of incentive to find stuff, at least in popular software. It's a much bigger problem for bespoke crypto people roll themselves, because the expertise required to find crypto vulnerabilities is uncommon, and there's not that much incentive at all to find a vulnerability in something nobody uses.
Sohcahtoa82 3y ago
> Is there like a high council of crypto wizards that keep checks and balances on each other? Not exactly, but certainly there are some crypto wizards that would love to get famous for figuring out how to break the so-called trusted algorithms and libraries.
lnrd 3y ago
I think this "high council of crypto wizards" is academia, at the end of the day we are talking about advanced math and i think there are many experts on that field eager to prove and correct each other.

by uticus 3y ago

sacrosanct 3y ago

As a rule of thumb, pay attention to crypto parameters and cipher 'suites'. Use the highest SHA, use seven word diceware phrases for the password, ensure the latest TLS version is used, use a reputable & robust RNG, etc

tptacek 3y ago
SHA2 is fine. The "reputable" RNG comes with your OS; just use getrandom.
- tialaramex 3y ago
  If you don't know what you're doing SHA-512/256 (note that's not a choice, that's the name of a single SHA-2 family member) is probably the member of the SHA-2 family to choose.
  - tptacek 3y ago
    I go the other way and tell people to ignore KMAC and just use HMAC for everything, and then you don't really need to know about truncated SHA2.
    - tialaramex 3y ago
      Fair, I have no experience with which approach is more likely to prevent naive users from blowing their own feet off in practice.
      - tptacek 3y ago
        My feeling is that like in 2001 it would have been valuable to get people to switch to a non-extendable hash by default because people were freelancing their own MACs, but sometime in the intervening 2 decades people switched fully over to HMAC, so that if you're dealing with someone who is literally writing their own prefixed key hash MAC, you've got bigger problems than Merkle Damgard.

Buttons840 3y ago

Whenever I'm roleplaying with my tinfoil hat, I say that the NSA is behind the "never implement your own crypto" advice. If you're really worried, roll your own encryption, and then also run the encrypted message through standard encryption implementations. After all, if the standard implementations work, it doesn't matter if you mess up your own crypto implementation, because the standard implementation is unbreakable.

Analemma_ 3y ago
Whenever I'm roleplaying with my tinfoil hat, I say that the NSA is behind comments like yours. You cannot assume that the security of a composite crypotsystem is max(system1, ..., systemN), i.e. that bolting a secure system to an insecure one is at least as secure as the most secure system. Sometimes it is; sometimes it is not and the insecure system breaks the whole thing in a way that casual analysis can't spot. If I were the NSA trying to inject memes into the software ecosystem to make my job easier, I would definitely recommend that everybody start with vetted open-source cryptosystems and then bolt their hand-rolled crap to them.
- Buttons840 3y ago
  If it's true that modifying my plaintext before putting it through a standard encryption algorithm might affect the security, then it might also be possible that sending, say, an HTML payload is more secure than sending a JSON payload. That would be weird. Can existing encryption algorithms encrypt any payload or can't they? It would be odd if we're worrying about timing attacks, etc, when we can't even securely encrypt any possible plaintext first.
  - kwantam 3y ago
    Yes, a correct encryption algorithm can encrypt (essentially) any bit string. But it's quite easy to turn a correct encryption algorithm into an incorrect one by bolting on something seemingly innocuous. Here's a concrete example. Let's say you decide you want to make AES encryption more efficient by defining a new standard, "lzAES", that is just: Enc_lz(key, msg) := AES-Encrypt(key, lzw_compress(msg)) Dec_lz(key, ctxt) := lzw_decompress(AES-Decrypt(key, ctxt)) This "works", in the sense that you can correctly decrypt ciphertexts, and it certainly seems innocuous. But it is now an insecure cipher! Here's why: the definition of a secure cipher is that ciphertexts resulting from the encryptions of any two messages of equal length are indistinguishable. In other words, for any two messages you can choose, if I encrypt both messages under a randomly generated key, you can't tell which ciphertext corresponds to which message. In contrast, lzAES as defined above does not have this property: you could choose one message that's easily compressible (say, a string of zeros) and one that's not (say, a uniformly random string), and then you'd be able to tell which ciphertext corresponds to which plaintext just by looking at the ciphertext lengths. And this is not just a definitional issue! If you use lzAES to encrypt something, an attacker can guess your message and test whether compressing the guess gives the same length as your ciphertext. Guess-and-check isn't possible with a secure cipher, but it is with lzAES---in other words, it gives away information about your plaintext!

tptacek 3y ago

Cryptography engineers and vulnerability researchers who specialize in cryptography look for vulnerabilities in the popular libraries. Cryptographic vulnerabilities are high-status (if you find a pattern of them, you can even get published in the Big 4 academic venues). So there's a lot of incentive to find stuff, at least in popular software. It's a much bigger problem for bespoke crypto people roll themselves, because the expertise required to find crypto vulnerabilities is uncommon, and there's not that much incentive at all to find a vulnerability in something nobody uses.

Sohcahtoa82 3y ago

> Is there like a high council of crypto wizards that keep checks and balances on each other? Not exactly, but certainly there are some crypto wizards that would love to get famous for figuring out how to break the so-called trusted algorithms and libraries.

lnrd 3y ago

I think this "high council of crypto wizards" is academia, at the end of the day we are talking about advanced math and i think there are many experts on that field eager to prove and correct each other.