3 ms·

You always get people screaming about 'it should have been encrypted!' when there's a leak without understanding what encryption can and can't do in principle a

by rcxdude 6mo ago

You always get people screaming about 'it should have been encrypted!' when there's a leak without understanding what encryption can and can't do in principle and in practice (it most certainly isn't a synonym for 'secure' or 'safe').

ErroneousBosh 6mo ago
Whenever someone says "But it should have been encrypted!" about things like configs on a server, I ask them how they'd implement that in practice. PoC or GTFO. I think you'll find it's a bit harder to do than you expect.
- lelanthran 6mo ago
  > Whenever someone says "But it should have been encrypted!" about things like configs on a server, I ask them how they'd implement that in practice. Short practical answer: Use a USB HSM plugged into your server and acknowledge that it is an imperfect solution. For configs, I used to setuid the executable so that it starts up as a user that can read the file, it reads the file into RAM in the first 5 lines in `main` then drops privs immediately to a user that can't read the file, and then continues as normal. This was to ensure that if the application was compromised, the config could not be changed by the application itself, nor could it be read once the program was running. If you wanted to keep it encrypted without leaking the key, you could do the same, except that the key would also be read at startup (or, preferably, get a data key from the USB HSM, and use that for decryption). Of course, that moves the problem of "read the first key from disk" to "read the HSM pin from disk". You can have your supervising program, like a K8 cluster, inject the correct keys into the pod as it's created, but that cluster itself needs a root key to decrypt those correct keys, and that has to come from somewhere too. There is, at the end of the day, only one perfect solution: when the program starts up it waits for user input - either the decryption key or the HSM pin - that it uses as a root key to decrypt everything else. There is no other way that isn't "store some root key, credential, token, etc on the computer".
CodesInChaos 6mo ago
Encryption turns your data confidentiality problem into a key management problem.
- dnnddidiej 6mo ago
  Also if you want to keep a secret a secret forever, encrypted but saved data may be easily decrypted in the future. Most secrets though in reality are less useful in X years time.
  - lemagedurage 6mo ago
    Theoretically maybe, but there's no indication that a quantum-resistant algorithm can't encrypt something that's secure for the coming million+ years.
    - hilariously 6mo ago
      Sure there is, just use a one time pad and never repeat the message. Oops - you said the opposite of what I read, my mistake.

by rcxdude 6mo ago

ErroneousBosh 6mo ago

Whenever someone says "But it should have been encrypted!" about things like configs on a server, I ask them how they'd implement that in practice. PoC or GTFO. I think you'll find it's a bit harder to do than you expect.

lelanthran 6mo ago
> Whenever someone says "But it should have been encrypted!" about things like configs on a server, I ask them how they'd implement that in practice. Short practical answer: Use a USB HSM plugged into your server and acknowledge that it is an imperfect solution. For configs, I used to setuid the executable so that it starts up as a user that can read the file, it reads the file into RAM in the first 5 lines in `main` then drops privs immediately to a user that can't read the file, and then continues as normal. This was to ensure that if the application was compromised, the config could not be changed by the application itself, nor could it be read once the program was running. If you wanted to keep it encrypted without leaking the key, you could do the same, except that the key would also be read at startup (or, preferably, get a data key from the USB HSM, and use that for decryption). Of course, that moves the problem of "read the first key from disk" to "read the HSM pin from disk". You can have your supervising program, like a K8 cluster, inject the correct keys into the pod as it's created, but that cluster itself needs a root key to decrypt those correct keys, and that has to come from somewhere too. There is, at the end of the day, only one perfect solution: when the program starts up it waits for user input - either the decryption key or the HSM pin - that it uses as a root key to decrypt everything else. There is no other way that isn't "store some root key, credential, token, etc on the computer".

CodesInChaos 6mo ago

Encryption turns your data confidentiality problem into a key management problem.

dnnddidiej 6mo ago
Also if you want to keep a secret a secret forever, encrypted but saved data may be easily decrypted in the future. Most secrets though in reality are less useful in X years time.
- lemagedurage 6mo ago
  Theoretically maybe, but there's no indication that a quantum-resistant algorithm can't encrypt something that's secure for the coming million+ years.
  - hilariously 6mo ago
    Sure there is, just use a one time pad and never repeat the message. Oops - you said the opposite of what I read, my mistake.