Let's start by explaining a use case and the confusion it gives due to poor nomenclature in the crypto-world. The case of me giving a so-called private-key to someone, so I can send the person an encrypted message with the pared public-key, so only the receiver can open it.
In this use case, in fact, I make a private-key public and assume the public-key to be private.
This use case makes clear that the naming of private-key and public-key are a poor semantic choice. It is a poor choice because depending on the use case, the private-key can be public and the other way around.
We better call the private-key just the encryption-key, and the public-key an encryption-vault. Let's then revisit the example use case now with the new naming.
The case of me giving a so-called encryption-key to someone, so I can send the person an encrypted message in an encryption-vault, so only the receiver can open it.
We have 4 clearly define objects now:
- public-encryption-key
- private-encryption-key
- public-encryption-vault
- private-encryption-vault
And vaults can have two states, namely be empty or being filled.
So we can split 3 and 4 in two types of boxes; empty and filled:
- encryption-vault (empty)
- encrypted-vault (filled)
Comments
Post a Comment