5 ms·

The forget the encryption key approach is clever.

jordibunster 9y ago
I used to think so too (that's what iPhones and the like do on "erase", btw) but doesn't that just push the problem into the future, when computers can more easily crack today's encryption?
- xoa 9y ago
  >the future, when computers can more easily crack today's encryption No. Don't confuse symmetric with asymmetric (current public key) encryption. They aren't subject to the same potential attacks. Even with a theoretical fully scalable general purpose quantum computer, the best quantum attack vs a symmetric cypher is brute forcing with Grover's Algorithm, which provides a quadratic rather then exponential speed up. Ie., a n-bit key could be attacked in around 2^(n/2). This is trivially countered by doubling key length, a 256-bit key would still take 2^128 which would still be effectively impossible, and a 512-bit key would take 2^256. There is no future with any foreseen technology that would be able to brute force that, so when it comes to AES and the like using at least 256-bit keys it can be reasonably assumed that destroying the key means the data is lost (anything legacy running off 128-bit is reasonable to watch out for though, 2^64 is potentially tractable). Present asymmetric crypto systems can theoretically [1] be attacked with Shor's Algorithm, which may be what you're kind of thinking of if you've heard about "today's encryption getting cracked" in the general media or scifi. And that would in fact be a big deal, it covers how most data is moved around in communications and the Internet at present. But QC isn't magic, and it doesn't just break anything. FDE and the like that just use symmetric crypto are safe. 1: "Theoretically" because that's if (big if) an ideal quantum computer that could be scaled to a sufficient number of qubits is created.
  - codetrotter 9y ago
    > There is no future with any foreseen technology that would be able to brute force that, so when it comes to AES and the like using at least 256-bit keys it can be reasonably assumed that destroying the key means the data is lost (anything legacy running off 128-bit is reasonable to watch out for though, 2^64 is potentially tractable). But we can’t know for sure that AES or any other encryption algorithm doesn’t have some as-of-yet-unknown fatal flaw that would make it breakable in some way not necessarily even having anything to do with quantum computers?
    - gizzlon 9y ago
      Of course not. But now you're getting philosophical :) Can you really now anything?
      - codetrotter 9y ago
        Ha ha yeah that is true. My point though was that it’s important to keep in mind if we decide to use throwing away the encryption key as or way of protecting the data.
  - raarts 9y ago
    > Don't confuse symmetric with asymmetric (current public key) encryption After reading this multiple times, and looking up QC (Quantum Computing) and FDE (Full Disk Encryption), I got the following out of it: - symmetric encryption is safe for AES-256 and up - asymmetric encryption isn't getting cracked because QC isn't magic Is this a correct TL;DR ?
    - prrls 9y ago
      The computations used to do symmetric and asymmetric encryptions are completely different. Asymmetric encryption is just about factoring out big numbers into primes, if we simplify things a bit. And modern computers aren't very good at it, but Quantum Computer happens to be, and can break it. Read a bit about Shor's Algorithm[0]. On the other hand, symmetric encryption can be seen as a super convoluted and costly shift cipher. And it seems that Quantum Computing does not help much with dumb and costly mathematics like this. [0]: https://en.wikipedia.org/wiki/Shor%27s_algorithm https://en.wikipedia.org/wiki/Shor%27s_algorithm
- Terr_ 9y ago
  It'll be fine as long as the decryption time-horizon is beyond the lifetime of the company, the user, and the regulatory-regime :p
  - theyinwhy 9y ago
    Not even this as it could have negative impact on the next at least 2 generations depending on politics in the future. Some people judge you based on who your ancestors were and what they did. There are countries today where you have to fear for your life if your father was gay, for example. As we cannot foresee the future, neither politics nor any future decyphering capacities, I highly doubt deleting the key is a viable option. Note: Edited for clarity.
evrydayhustling 9y ago
Yes very cool! But I wonder if courts will decide that throwing away the key to the lockbox is the same as burning the contents.
- BillinghamJ 9y ago
  Crypto-shredding, as it is known, it is already well established as a valid process and covers the requirements. The point is to make the data unusable. Obviously when you delete a file from your recycle bin, the data is all still there, but it's acceptable under EU data protection reqs.
  - sandGorgon 9y ago
    How does this work in practice? If each customers data has a unique encryption key, then how do you do SQL joins ?
    - whalesalad 9y ago
      It’s pretty straightforward: you don’t encrypt the data necessary for a join. Data for a join, ie foreign keys, are used to inform your structure. They aren’t really data a person owns... they just describe how that data (theirs) fits into your database (yours).
      - PeterisP 9y ago
        You'd still need to decrypt the whole table to do e.g. aggregation. For example, a customer's address is private information; statistics about how many customers come from each town/region is not, but calculating a simple "select town, count(*) from x group by town" requires decrypting every address.
        leifg 9y ago
        you can store whatever you want unencrypted on the read model. That‘s the place where you do joins/aggregation anyway.
freedomben 9y ago
This is clever, but it requires strict following of best practices (nobody has copies of production data, and backups and the like are guarded with proper access controls. Keys are never written to log files, etc). Make sure to get any DB backups as well, otherwise the key could still be out there somewhere. If you store the key under version control as well (bad practice but we've all seen it done) you'll need to rewrite git history to make sure the key isn't recoverable at all. There could be an infinite number of ways a key could unintentionally persist, so something to keep in mind with this approach. Good reason to be disciplined with keys and other secrets to make sure they aren't leaving the environment.
nbevans 9y ago
Why is storing junk data for all eternity considered clever?
- raarts 9y ago
  Because it beats getting a multimillion dollar fine from the EU?

I used to think so too (that's what iPhones and the like do on "erase", btw) but doesn't that just push the problem into the future, when computers can more easily crack today's encryption?

xoa 9y ago
>the future, when computers can more easily crack today's encryption No. Don't confuse symmetric with asymmetric (current public key) encryption. They aren't subject to the same potential attacks. Even with a theoretical fully scalable general purpose quantum computer, the best quantum attack vs a symmetric cypher is brute forcing with Grover's Algorithm, which provides a quadratic rather then exponential speed up. Ie., a n-bit key could be attacked in around 2^(n/2). This is trivially countered by doubling key length, a 256-bit key would still take 2^128 which would still be effectively impossible, and a 512-bit key would take 2^256. There is no future with any foreseen technology that would be able to brute force that, so when it comes to AES and the like using at least 256-bit keys it can be reasonably assumed that destroying the key means the data is lost (anything legacy running off 128-bit is reasonable to watch out for though, 2^64 is potentially tractable). Present asymmetric crypto systems can theoretically [1] be attacked with Shor's Algorithm, which may be what you're kind of thinking of if you've heard about "today's encryption getting cracked" in the general media or scifi. And that would in fact be a big deal, it covers how most data is moved around in communications and the Internet at present. But QC isn't magic, and it doesn't just break anything. FDE and the like that just use symmetric crypto are safe. 1: "Theoretically" because that's if (big if) an ideal quantum computer that could be scaled to a sufficient number of qubits is created.
- codetrotter 9y ago
  > There is no future with any foreseen technology that would be able to brute force that, so when it comes to AES and the like using at least 256-bit keys it can be reasonably assumed that destroying the key means the data is lost (anything legacy running off 128-bit is reasonable to watch out for though, 2^64 is potentially tractable). But we can’t know for sure that AES or any other encryption algorithm doesn’t have some as-of-yet-unknown fatal flaw that would make it breakable in some way not necessarily even having anything to do with quantum computers?
  - gizzlon 9y ago
    Of course not. But now you're getting philosophical :) Can you really now anything?
    - codetrotter 9y ago
      Ha ha yeah that is true. My point though was that it’s important to keep in mind if we decide to use throwing away the encryption key as or way of protecting the data.
- raarts 9y ago
  > Don't confuse symmetric with asymmetric (current public key) encryption After reading this multiple times, and looking up QC (Quantum Computing) and FDE (Full Disk Encryption), I got the following out of it: - symmetric encryption is safe for AES-256 and up - asymmetric encryption isn't getting cracked because QC isn't magic Is this a correct TL;DR ?
  - prrls 9y ago
    The computations used to do symmetric and asymmetric encryptions are completely different. Asymmetric encryption is just about factoring out big numbers into primes, if we simplify things a bit. And modern computers aren't very good at it, but Quantum Computer happens to be, and can break it. Read a bit about Shor's Algorithm[0]. On the other hand, symmetric encryption can be seen as a super convoluted and costly shift cipher. And it seems that Quantum Computing does not help much with dumb and costly mathematics like this. [0]: https://en.wikipedia.org/wiki/Shor%27s_algorithm https://en.wikipedia.org/wiki/Shor%27s_algorithm
Terr_ 9y ago
It'll be fine as long as the decryption time-horizon is beyond the lifetime of the company, the user, and the regulatory-regime :p
- theyinwhy 9y ago
  Not even this as it could have negative impact on the next at least 2 generations depending on politics in the future. Some people judge you based on who your ancestors were and what they did. There are countries today where you have to fear for your life if your father was gay, for example. As we cannot foresee the future, neither politics nor any future decyphering capacities, I highly doubt deleting the key is a viable option. Note: Edited for clarity.

evrydayhustling 9y ago

Yes very cool! But I wonder if courts will decide that throwing away the key to the lockbox is the same as burning the contents.

BillinghamJ 9y ago
Crypto-shredding, as it is known, it is already well established as a valid process and covers the requirements. The point is to make the data unusable. Obviously when you delete a file from your recycle bin, the data is all still there, but it's acceptable under EU data protection reqs.
- sandGorgon 9y ago
  How does this work in practice? If each customers data has a unique encryption key, then how do you do SQL joins ?
  - whalesalad 9y ago
    It’s pretty straightforward: you don’t encrypt the data necessary for a join. Data for a join, ie foreign keys, are used to inform your structure. They aren’t really data a person owns... they just describe how that data (theirs) fits into your database (yours).
    - PeterisP 9y ago
      You'd still need to decrypt the whole table to do e.g. aggregation. For example, a customer's address is private information; statistics about how many customers come from each town/region is not, but calculating a simple "select town, count(*) from x group by town" requires decrypting every address.
      - leifg 9y ago
        you can store whatever you want unencrypted on the read model. That‘s the place where you do joins/aggregation anyway.

freedomben 9y ago

This is clever, but it requires strict following of best practices (nobody has copies of production data, and backups and the like are guarded with proper access controls. Keys are never written to log files, etc). Make sure to get any DB backups as well, otherwise the key could still be out there somewhere. If you store the key under version control as well (bad practice but we've all seen it done) you'll need to rewrite git history to make sure the key isn't recoverable at all. There could be an infinite number of ways a key could unintentionally persist, so something to keep in mind with this approach. Good reason to be disciplined with keys and other secrets to make sure they aren't leaving the environment.

nbevans 9y ago

Why is storing junk data for all eternity considered clever?

raarts 9y ago
Because it beats getting a multimillion dollar fine from the EU?