Ask HN: Weak+Strong Encryption

1 points by _ah ↗ HN
tl;dr: We should encrypt everything weakly, then strongly.

Data security, and by extension data collection by law enforcement agencies, is an economics problem. The old compromise has broken: phone taps and physical surveillance have very high human costs limiting their use. With the advent of Digital we have created a bifurcated system of impossibly weak or impossibly strong data security. We are simultaneously always at risk of data exposure through code errors, and yet also have various officials demanding key escrow and backdoors due to impossibly strong crypto.

I propose another way: Weak+Strong encryption. In this method, "weak" is defined as "key can be found with an average of $10,000 AWS compute time", and "strong" is "best available data security". We encrypt all user data with a user-generated weak key, and then encrypt again with a provider-generated strong key.

In this scenario, every user of a service has their personal crypto key, unknown to the service provider. All data is further strongly encrypted at rest by the provider. * In the event of database breach, no information is compromised. * The service provider can decrypt the first layer, but still cannot examine user information without significant effort (cost), or user cooperation. * In the event of demands from a Three Letter Agency, the service provider similarly has the ability to strip away the strong encryption, and the agency can easily afford to break the key of one user and gather evidence. However the economics of the weak keys prevent mass decryption. Only a few targeted individuals could be cost-effectively exposed. Even government departments have budgets to keep.

Weak+Strong may provide a good compromise between the needs of the user and the needs of law enforcement. As an added bonus, then we could stop arguing with senators about the mathematical impossibility of secure backdoors.

Anyone doing this already? Thoughts?

0 comments

[ 2.6 ms ] story [ 13.2 ms ] thread

No comments yet.