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!

  • 1
    "I can think of a few applications for such a setup" - such as? I'm intrigued.
    – Polynomial
    Oct 14, 2021 at 2:25
  • Thanks so much. I expanded the question with much more detail about the different applications. Hope it makes sense.
    – azoundria
    Oct 14, 2021 at 17:13

1 Answer 1


First of all, a few misconceptions:

  1. You've got the way public key crypto (which is in fact called "public key" or "asymmetric", not "private key") works a bit wrong. The public key can encrypt and verify but can't sign or decrypt. The private key is the reverse. The sensitive operation in both cases - the one that only an authorized person should be able to do - requires the private key (anybody can encrypt, but only one can decrypt and reveal whatever secrets were encrypted; anybody can verify a signature if they get one, but only one is able to say "I hereby attach my seal to this message, that it may be known to come from me and not get tampered with en route").
  2. Hashing isn't encryption, in any useful sense. Not only is there no corresponding decryption routine, but also, hash functions produce an output with a fixed length, regardless of the input length (encryption functions always product an output at least as long as the input, and many can't actually take an arbitrary length input at all without some way to repeatedly apply the basic operation to each data chunk in sequence, known as a "block cipher mode of operation").
  3. Hashing also usually does not use any form of "key". You don't specify why you'd need a keyed hash at all in your actual question, but I'm going to assume it's for the usual reasons you might want one: to generate a message authentication code (MAC) of some kind, such as an HMAC (Hash-based MAC).

With that said:

While there are no cryptographic primitives (algorithms that can implement a single cryptographic operation) that can both encrypt and hash but use two different keys, there are cryptographic "constructions" or "suites" that do this. For example, TLS (the security protocol behind HTTPS and some other protocols) can use two symmetric keys in some cases, one for bulk data encryption and decryption, and the other for computing MACs of that data.

Alternatively, TLS (and other cryptosystems) can extend various ciphers in ways that add message authentication on top of encryption using the same key, and usually it's also possible to MAC some data without encrypting it. This is known as "Authenticated Encryption with Associated Data" (AEAD), and there are a few common ways to do it (Galois/Counter Mode, a block cipher mode of operation that adds AEAD to any block cipher, is commonly used with AES in, among many other things, securing your communication to this very website). However, while AEAD can both encrypt/decrypt and MAC (sort of like signing)/verify, and can MAC data that is not actually encrypted as well as data that is, AEAD uses the same key for everything.

Finally, and included only for completeness' sake, you can build something not entirely unlike a hashing algorithm using a cipher (encryption algorithm). If you take the message to "hash" and use it as the encryption key for some cipher, and use them (either without any initialization vector or nonce, or with a fixed one which thus technically is not a nonce) to encrypt a message already known to both parties (typically publicly known, or at least not really secret), you can produce something that is technically a ciphertext but which is used like a hash digest. Please don't do this; secure hash algorithms are as good or better at everything you might want to use this approach for.

  • Like a hash, this process is deterministic: assuming the cipher and message are held constant, any given secret will produce the same ciphertext.
  • Like a hash, this process is irreversible; assuming the cipher is secure, there's no way to derive the key used (except by brute force, which should be impractical) even though you know both the plaintext message and the ciphertext (and indeed know many such pairs for different keys).
  • In a secure hash, the process is collision-resistant; that is hopefully the case here too (it is only possible via brute force to find two different keys such that they encrypt the same message to the same ciphertext). However, that's not necessarily something one specifically tests ciphers for.
  • In a secure hash, the algorithm is resistant to pre-image attacks (given any digest, it's only possible by brute force to find an input that produces it); this is probably also true for these cipher-based "hashes".
  • Unlike a typical secure hash algorithm, the length of the secret is strictly restricted (ciphers typically only accept a small range, or single value, key size).
  • Thanks so much! I fixed the public key term in my post and added more about hashing. (1) For your first solution, it sounds like the resulting encryption would be different from the resulting hash. ie One could not "encrypt" without the decryption key, or "decrypt" the hash. I need to better understand. (2) While great for integrity, I understand this signature can't retrieve the original data. (3) Sounds like this is basically a less secure hash, and the original data is not retrievable with any key.
    – azoundria
    Oct 14, 2021 at 17:33
  • However, your information about public key cryptography has caused me to wonder if maybe that application is more general than I thought. If I generate a key-pair, then I could use the public key for the encryption of new data. That could be stored on the server for encryption, along with the encrypted data, and wouldn't allow any decryption. On the other hand, the private key would be kept offline, and could be used to decrypt any encrypted data from the database. If I understand public key cryptography right, then perhaps it already solves the problem. Any downside to that approach?
    – azoundria
    Oct 14, 2021 at 17:40
  • I tried out this example here: stackoverflow.com/questions/4629537/… - However, the end result encrypted text is 512 bytes in length. I tried to change from SHA512 to SHA256, however the result was still the same length. Is there a way to have the encryption result be slightly smaller (maybe 64 bytes or 128 bytes)?
    – azoundria
    Oct 14, 2021 at 18:33
  • Your edit makes this a substantially different question than before, but this is also part of where your conflating of "encryption" and "hashing" is confusing you. You describe a system with two keys, one of which can be used both for encryption and decryption, but the other only for encryption. There isn't any hashing in this system whatsoever. On the other hand, this is functionally just what every asymmetric encryption algorithm already is; the key pair can collectively be used for both encryption and decryption, while the public key alone is only usable for encryption.
    – CBHacking
    Oct 14, 2021 at 22:02
  • Regarding your second comment, there are lots of implementation issues with trying to do this - the naive approach will fail for many reasons, and at a minimum you want a "hybrid cryptosystem" where the public key is used to encrypt a symmetric key, rather than encrypting the secrets directly - but from a fundamental design perspective the system you're describing works (and is fundamentally what I described in the previous comment).
    – CBHacking
    Oct 14, 2021 at 22:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .