In cryptography, generally we have two ways of handling sensitive information.
We can use one-way encryption such as hashing. This is useful when we never need to retrieve it again. In this case, we can know if we found the right password, but never the original password other than by brute force. Hashing doesn't have a decryption routine, and doeesn't use a key except in some cases like HMAC.
We also have two-way cryptography, where a secret key can be used to encrypt or decrypt the information. In this case, anyone with the key, and the encrypted information, can get back the original text.
There's also public key cryptography, where you have two keys. In this case, one is used to encrypt/sign messages, and the other can only validate but not encrypt. So this is an example with two keys but not what I'm looking for.
What I was wondering about, is whether there's another kind of cryptographic algorithm with two keys. One of them behaves kind of like a hashing function with one-way encryption, while the other key is a two-way encryption function.
For example, if we have our secret, we can encrypt it with either key, but when it comes to decrypting, only the second key will work. The first key doesn't work to decrypt. It's only "one-way" like hashing.
This type of setup would be useful for situations of the general type:
- Information is stored in a less secure location, such as online or where multiple people access it.
- Information must remain secret even if data is breached. Both data and decryption key are needed.
- Information doesn't need to be accessed often, and is typically accessed outside of an automated system.
A very common example would be the standard website which handles personal information of users. The average shared hosting environment is riddled with potential security holes, and the vast number of high profile data breaches further emphasize the challenges of keeping customer information secure even at the enterprise level.
On the other hand, much of this information such as home addresses, phone number, or payment details don't need to be accessed often, or by many people. Standard two-way encryption has the problem that new entries have to be encrypted, which means you either have to:
- Store the private key somewhere online, subject to being breached in the same way as the data, or
- Manually handle the encryption, in which case the data resides unencrypted and there's a bottleneck to try to reach the key-holders. That's bound to manifest in practice as data not being encrypted during key times, greater likelihood of breach, and chewing up a massive volume of resources.
If we can solve the encryption problem with a separate one-way key, it means that information in the database is immediately secure upon entry, similar to a hashed password. Even if the database is breached, it's useless to the hacker without the decryption key.
There are a vast number of solutions for the safe storage of decryption keys offline, in HSM (hardware security models), on paper, or even in memory. A MPC (multi-party computation) could even be used to spread out the attack vector so multiple independent entities all have to be breached simultaneously to generate the key and access the data. Because it's a static and unchanging piece of data, it can be backed up and stored more easily, and a relatively small piece of data gives many more options.
On the other hand, secure storage of a dynamic database is an ongoing challenge of keeping those backups synchronized while simultaneously protected. Updating the data on a periodic basis is an attack vector that requires access be given to a trusted individual or system. Trusting the wrong individual or a single mistake in the system can mean the permanent and irreversible breach of the data.
Given how many applications I can see for such a setup, and was curious whether anything existed. If it doesn't exist, I'm curious (without getting too technical) if there's a certain reason why it's not possible, or if it simply hasn't been invented yet.
Hope what I'm asking makes sense. Thanks so much!