Keypair Encryption
Public Key Cryptography (or Asymmetrical Cryptography) is a way of separating the ability to encrypt something from the ability to decrypt something.
This is an inverse to Symmetric Cryptography, which allows both encryption and decryption using a single piece of information.
We'll talk about this in the context of Chamber to keep things grounded.
When you chamber init in your project, you will be provided with four files.
chamber.pemchamber.encchamber.enc.passchamber.pub.pem
Note: The
.pemextension is irrelevent for this discussion, but just think about it as the format of the block you see when you open those files in a text editor. It makes it as "human-readable" as possible.
Out of the above files that Chamber creates for you, .chamber.pub.pem is your
public key. This file will be checked into version control with the rest of
your project.
The public key can do two things and only two things:
- Encrypt Data
- Verify Ownership
We discuss both of these things in What Keys Can Do.
As you may have guessed, if .chamber.pub.pem is your public key, therefore, by
process of elimination, .chamber.pem must be your private key.
In general cryptographic situations, you would never want to give your private key to anyone. It provides a way of ensuring that "you're you". For example, SSH uses Public Key Cryptography:
User: Hi, it's me! Here's my key!
Server: Oh, this is the only key that could possibly fit my lock and there's no way anyone else would possess it, it must be my User!
For Chamber however, your private keys are designed to be given out to very select individuals. This may include other developers on your team, QA testers, your CI service, etc.
These should be people you trust and who need to run your code.
Private keys can do everything public keys can do, and also:
- Decrypt Data
- Generate Signatures
We discuss both of these things in What Keys Can Do.
We put some encryption in your encryption - Anonymous
But if your private key is so sensitive, how do you possibly send it to someone such that you're sure no one else has intercepted it? Telling it to someone in person and having them type it directly into their text editor seems like the only way right?
Fortunately Chamber gives you a slightly better option. RSA keys (which is the type of key Chamber uses. Don't worry about it.) allow you to specify a passphrase which can be used so that, even if a private key is intercepted, it can't be used unless the user also has the passphrase.
When you chamber init, Chamber will not only give you the public and private
keys, it will also create an encrypted version of the private key
(.chamber.enc). Once the initialization is done, it will print the passphrase
for the encrypted private key to the screen, as well as put it in a file
(.chamber.enc.pass) alongside the keys.
At this point, you may be asking.
If the passphrase is secure enough to encrypt the private key, then why not just skip the key and use the passphrase by itself to encrypt the data?
The reason is because the passphrase is much much shorter than your private key. It's designed only as a last blockade against an attacker if they happen to steal your private key. It is not meant to be a primary defense. Your primary defense is to keep your private key... private.
However, since the likelihood of your private key being intercepted in transit is fairly low, you could send someone your encrypted key and then read off the short private key passphrase in front of the person and that will allow them to decrypt the private key.
I would personally never email a private key, even if it's encrypted, and even if it's only used for your application's settings.
Here are some potential options that would be far safer than email (from most to least safe):
- SD Card
- USB Drive
- Airdrop
- Bluetooth File Transfer
- Internal Network Share
- Slack DM, Dropbox, Google Drive, etc
There are advantages and disadvantages to each approach. The advantage of Public Key Cryptography is that it is safer and allows separation of responsibilities.
The advantages of Symmetrical encryption is that it is generally faster. It's also more convenient since you only need to store one (relatively short) piece of information rather than two (rather long) pieces.
The speed aspect is not a concern for Chamber due to the small amount of work that needs to be done. Megabytes of information decryption would have a noticable difference, but a few bytes does not.
Additionally having the ability to provide users with the ability to encrypt (but not decrypt) information is highly valuable.
