Encryption uses an algorithm to take plaintext and a key to output ciphertext.
Decrytion takes ciphertext and a key to output plaintext.
Symmetric encryption uses the same key to encrypt and decrypt.
It is great for local file encryption or disk encryption, but not great for transferring between two parties.
Asymmetric encryption uses a public key to encrypt and a private key to decrypt. They are two separate keys.
The public key is fine to share with others, but the private key is not. If a third-party obtains the shared public key, then they cannot decrypt the data.
Used for pgp, ssh, ssl/tls and other secure protocols.
It is computationally expensive to do, so normally asymmetric encryption is used to help share symmetric keys.
Another process that uses asymmetric keys is signing.
How does the party without the private key know that the sender is who they claim to be?
What you can do is use signing. The party with the private key can use that key to sign a message that it sends back.
Once the other party receives the signed message, they can verify that the message was sent by using the public key to prove the message was signed by the private key.
Signing is used to verify identity.
Sometimes encryption isn't enough. The problem is that when you encrypt data, people can tell that you've encrypted the data. Steganography addresses this.
If you've ever used that invisible ink that only displays under a certain light, then that is an example of using steganography.
With steganography, a party with the public key could encrypt some plaintext and hide it within an image and send the image to the other party. The party with the private (knowing about the data within the image) can extract the data and then decrypt the message with a private key.
Steganography increases the file size but it would look almost identical. It is another level of protection.
KMS as a product isn't too complicated to understand, but it is used heavily by other AWS services.
KMS mainly manages CMKs (Customer Master Keys).
CreateKeyon KMS to create a CMK. CMKs are never stored in a persistent form when not encrypted.
Decryptcall and pass the ciphertext into KMS.
At no point does the CMK leave KMS and at no point is the CMK persisted to disk unencrypted. At every step, the user need the permissions to use the key (i.e. can
Decrypt). This is known as role separation.
When KMS generates the key, it provides you with two versions of it:
The idea is that you want to encrypt the data using the plaintext key provided, then discard the plaintext version of that key.
This leaves you with the ciphertext version of the key and the encrypted data. You want to store the encrypted key with data.
To decrypt the data, you do the following:
After creating a CMK and adding the correct policies to enable a specific user to encrypt/decrypt data, you can use the following to demo the process:
# Shared echo "find all the doggos, distract them with the yumz" > battleplans.txt Windows Commands aws kms encrypt --key-id alias/catrobot --plaintext fileb://battleplans.txt --output text --profile iamadmin-general --query CiphertextBlob > battleplans.base64 certutil -decode battleplans.base64 not_battleplans.enc aws kms decrypt --ciphertext-blob fileb://not_battleplans.enc --output text --profile iamadmin-general --query Plaintext > decreyptedplans.base64 certutil -decode decreyptedplans.base64 decryptedplans.txt # Linux/macOS commands aws kms encrypt \ --key-id alias/catrobot \ --plaintext fileb://battleplans.txt \ --output text \ --query CiphertextBlob \ --profile iamadmin-general | base64 \ --decode > not_battleplans.enc aws kms decrypt \ --ciphertext-blob fileb://not_battleplans.enc \ --output text \ --profile iamadmin-general \ --query Plaintext | base64 --decode > decryptedplans.txt
This is around encryption within S3.
A common misconception: buckets aren't encrypted. Objects are.
Every object can be using different encryption methods.
Both are encryption-at-rest.
With client-side encryption, you need to deal with the keys, process and tooling yourself.
With server-side, you have three types of encryption available:
There are two components to server-side encryption that all three of these handle differently:
SSE-S3 is not the right choice if you need any of the following:
|Method||Key Management||Encryption Processing||Extras|
|SSE-KMS||S3 & KMS||S3||Rotation Control, Role Separation|
When making a PUT request to upload the object, you can use the
x-amz-server-side-encryption header to specify the encryption method.
You need to specify the header.
The value for SSE-S3 is
AES256 and for SSE-KMS
There is also a feature that can be set on a bucket for a default encryption. The bucket default is just that - a default. The header takes priority.
You can use a bucket policy to restrict the type of encryption required on a bucket.