Can't think of a good opening just try exploring basics of cryptographic thru practical application and example to understand further on asymmetric, symmetric as well hybrid cryptographic communication.

Asymmetric Cryptographic

First there's asymmetric cryptographic where a key-pair generated. One key to encrypt and another key to decrypt. We not going to dive into factorisation of prime number and mathematical algorithm behind it, for this writing we focused on the practical application and how to use it.

There's multiple option for generating key pair. But since this learning notes, we want to try converting from existing key-pair in .ssh folder generated from ssh-keygen command instead of generating new one from openssl.

If no key generated run ssh-keygen command from the terminal and follow the instruction to generate. This going to generate a key-pair for ssh verification.

Converting existing RSA to OpenSSL format

Instead of converting both key-pair, what we going to do here is converting the private key first then generate the public pair from the converted private key. Then we convert the public key directly so we can compare.

To convert the private key we use OpenSSL

openssl rsa -in private-key -outform PEM -out openssl_private_conversion.pem

In the command above, input the private-key file containing the private key string and output the conversion to the .pem file.

Generating the public key

There's two thing we want to do here, convert the existing public key to .pem format and also extracting new public key from converted .pem private key. The goal here is to compare between this two.

Extracting from converted private key

openssl rsa -in openssl_private_conversion.pem -pubout -out openssl_public_extract.pem

Converting from existinng public key

ssh-keygen -f public-key.pub -e -m pem | tee keygen-public-convert.pem

Based from generated key both in similar format but contain different value.

Encrypt and decrypt messages

Lets start using the generated key to encrypt and decrypt message.

Create a message in a text file

echo "Ohayou!" | tee plain.txt

Inside write simple messages, in this case Ohayou!

To decrypt it we input the messages, the public key and the specify the output file for the encrypted messages.

Encrypt with OpenSSL thru extracted public key

openssl pkeyutl -encrypt -in plain.txt -pubin -inkey openssl_public_extract.pem -out encrypted_public_extract.bin

Encrypt with openssl thru conversion public key

openssl pkeyutl -encrypt -in plain.txt -pubin -inkey keygen_public_convert.pem -out encrypted_public_convert.bin

Great, now check the .bin file generated contain, it should contain gibberish character and not making any senses.

To get the readable version of the original messages we need to decrypt the encrypted message.

Decrypt with openssh thru private key

openssl pkeyutl -decrypt -in encrypted.bin -inkey openssl_private_conversion.pem -out decrypted.txt

Open out or print the decrypted.txt file, the original message show be displayed.

cat decrypted.txt

From the experiment above, we can see the public key generated in either way works and can be decrypted by the private key. But can the private key use to decrypt and public to encrypt (reverse)? No, for the RSA algorithm (I tried). In simple words the truth table for encryption and decryption just now was something like this.

Reverse Asymmetric Cryptographic

There's other types of crytographic algorithm that can work in reverse where the owner use the private key to encrypt and other users decrypt it by public key, this normally refered as sign and other people who have the public key can decrypt it and compare to the original content normally referred as verify. Using this method, we can sure the sender is the valid private key owner else the pair won't works.

One of the most popular algorithm for this purposes is ECDSA.

Lets look at the simple implementation example using OpenSSL

Generate ECDSA keypair

openssl ecparam -name secp256k1 -genkey -noout -out private_key.pem
openssl ec -in private_key.pem -pubout -out public_key.pem

Data for verification

echo "any data will do" | tee data.txt

Sign data (encrypt)

echo -n "Insert message here" > data.txt
openssl dgst -sha256 -sign private_key.pem -out signature.bin data.txt

Verify data (decrypt)

openssl dgst -sha256 -verify public_key.pem -signature signature.bin data.txt

In the verify (decrypt) process original data needed to compare the output and serve as validation. If the output data not matching the original data.txt then the signature is not valid (keypair not matching).

The truth table for ECDSA.

Symmetric Cryptographic

Another type of encryption which allow two way symmetric encryption which using single key to encrypt and decrypt message.

To understand further, assume we copy it into two with different name public and private (the content remain the same) the truth table should goes like this.

Generating the key

openssl rand --hex 64 | tee aes_key.txt

This command above will generate a 64 bytes long key (equal to 8*32 bits as one bytes equal to 8 bit). This random string generated can be use as AES key to decrypt and encrypt message.

Encrypt message AES

echo -n "Your secret message" > plaintext.txt
openssl enc -aes-256-cbc -salt -in plaintext.txt -out encrypted.bin -K $(cat aes_key.txt) -iv [initialization_vector]

For the IV can include any hex number or just random string, this but the same string should be use when decrypting the message.

Decrypt message AES

openssl enc -d -aes-256-cbc -in encrypted.bin -out decrypted.txt -K $(cat aes_key.txt) -iv [initialization_vector]

When generating the key we also can further randomize the key generation using phrases. This will provide generate a better random key.

Generaring AES key with phrases

echo -n "use this text" > phrases.txt
openssl enc -aes-256-cbc -kfile phrases.txt -P -md sha256

In the command above, the we can either pass phrases using file (-kfile) or direct text (-k). The string will be use to prompt a password or displaying the phrases during decryption process but as addition measure to further randomize the factor for creating the key.

Hybrid Protocol

For effective communication, we can use combination of the cryptographic algorithm for example using asymmetric key to sent the symmetric key then exchange data thru symmetric only.

How communication was secure using this method? Lets imagine we have 3 people on the communication line. UserA, UserB, UserC. UserA and UserB only want to talk with each other but UserC was peeking thru the communication line.

UserA and UserB need to establish secure communication thru the open line.

So this is what they did.

1. UserA generated asymmetric cryptographic RSA keypair private.pem and public.pem.
2. UserA sent the RSA public.pem to UserB thru the communication line.
3. UserB and UserC who was listening the communication line got the public.pem key as well.
4. UserB generated a symmetric AES key and encrypt it using public.pem key and sent to UserA thru the communication line.
5. UserA and UserC got the encrypted AES key but UserA the only one have private.pem key to decrypt the message.
6. Now both UserA and UserB have the AES key to encrypt and decrypt while userC only have the public.pem key and encrypted AES key.
7. UserA and UserB now both can talk using AES encyption but UserC only received encrypted AES message without AES key to decrypt it

This is of course a very simple example, complicated situation may arise if both UserB and UserC claimed as the real one and sent UserA with their own AES key. To resolve this, implementation of signing with reverse asymmetric cryptographic required where UserB thru reputable organization provide verification of identity. Read thru how SSL certification works.

The simple example for this, UserB generate a keypair of ECDMA private_userb.pem and public_userb.pem. The public key is for decrypt and private key for encrypt (signing) message. A reputable third party will verified public_userb.pem which sent to everyone belong to the userB.

When the UserB sent out any message it also sent random string signed (encrypt with private key) and the random string itself, everyone then can use public_userb.pem to decrypt the message compare the output to verified private key ownership. Unless the right keypair use, the random string will not decrypt into the right one. This is again a very simple explanation, real world implementation have bit more layer of proving and verifying the identity.