Besides encrypting your user data at rest using these post-quantum cryptography algo.
What can be done from a design point of view to make it as hard as possible to deter attackers?
Would it make sense to segregate different types of data into other dbs rather than as a separate table?
“Name DB”
“Account DB”
“Address DB”
An attacker would need to have advanced knowledge of the app backend to know you have to snag both the account db and address db. Otherwise, the decrypted data is useless with only 1 db.
Drawbacks of course include “performance degradation”, “increasingly complex app”.
Ideally, if you did not need to store sensitive data or collect other user info such as address or zip code. Then not asking for it at all would be optimal. Maybe regulation is needed here.
>Besides encrypting your user data at rest using these post-quantum cryptography algo.
If you're encrypting data at rest, just keep using an appropriate mode of AES (or ChaCha20 or whatever+) and exercising good key management practices. Quantum computing is largely irrelevant to conventional symmetric ciphers.
No it’s worth a 1/2 reduction in the number of bits. So 256 becomes effectively 128 bit encryption. Idk though if the solution could be as simple as creating “AES 512”.
If I were an adversary possessing a (quantum) code-breaking device, who can break into your infra that uses a (pre-quantum) encryption for authorization, I probably would attach a debugger to your worker process, and find out about all your databases, and maybe hijacked a live connection to one.
If I only could get access to nothing but one database, and every table / segment of it were encrypted differently, it would likely take as much effort to break into each of them, as if they were "physically separate" databases.
it is also trivial to work around by just doubling the key length. But even without that the speed up is slow enough that we will be well within the quantum age before this matters. The article talks about this a bit.
Typically once you get access you just try to dump everything and figure it out later. Splitting into separate stores is just convoluting your day to day for minimal inconvenience to a possibly non-existent an adversary.
What can be done from a design point of view to make it as hard as possible to deter attackers?
Would it make sense to segregate different types of data into other dbs rather than as a separate table?
“Name DB” “Account DB” “Address DB”
An attacker would need to have advanced knowledge of the app backend to know you have to snag both the account db and address db. Otherwise, the decrypted data is useless with only 1 db.
Drawbacks of course include “performance degradation”, “increasingly complex app”.
Ideally, if you did not need to store sensitive data or collect other user info such as address or zip code. Then not asking for it at all would be optimal. Maybe regulation is needed here.