This blog post aims to create a big picture of cryptography in the IT world.
Plan
- Vocabulary
- Symmetric Ciphers
- Asymmetric ciphers
- Diffie-Hellman key exchange
- Hash
- HMAC — Keyed-hash message authentication code
- Digital Signature
- Certificates
Vocabulary
A cipher is an encryption and decryption function that converts an original message (also called plaintext) to an encrypted message (also called ciphertext).
As you can see in Figure 1, synonyms can be used for these different words.
A cipher can either be:
- Symmetric
- Asymmetric
Symmetric Ciphers
A cipher is symmetric if it uses the same secret key for both the encryption and decryption process.
Example of a simple symmetric cipher is the XOR operation:
In this Figure the cipher and the key are the same for both the encryption and decryption.
Only the key is the same (and not the algorithm) in most other symmetric ciphers.
A symmetric cipher can either be a “stream” or “block” cipher.
Stream ciphers
Stream ciphers encrypt each “character” (could be binary) of the plaintext one by one.
The same character may have 2 different encryptions in the ciphertext.
An example of a stream cipher is RC4 (Rivest Cipher 4) which has been used for WEP key or SSL.
Block ciphers
Block ciphers consist of operations made on fixed block size of data: 64, 128, 192, 256 bits depending on the cipher.
Main block cipher
DES
Considered unsecured nowadays (and too slow)
- block size: 64 bits
- key size 56 bits
AES / Rijndael
Nowadays standard
- block size: 128 bits
- key size: 128, 192, 256 bits
Blowfish
Public domain, fast and still strong against attacks. Upgraded versions are Twofish, Threefish:
- block size: 64 bits
- key size: from 32 to 448 bits
Stream vs block cipher ?
— > In short: most of the time: block
- Stream ciphers are typically faster than block
- Block ciphers typically require more memory
- Stream ciphers are more difficult to implement correctly, and prone to weaknesses based on usage
- Also, stream ciphers do not provide integrity protection or authentication, whereas some block ciphers (depending on mode) can provide integrity protection, in addition to confidentiality.
===> Because of all the above, stream ciphers are usually best for cases where the amount of data is either unknown, or continuous — such as network streams. Block ciphers, on the other hand, are more useful when the amount of data is pre-known — such as a file, data fields, or request/response protocols, such as HTTP where the length of the total message is known already at the beginning.
Source: AviD on stackexchange
Asymmetric ciphers
Symmetric ciphers imply that both parties need to share the same unique private key to encrypt and decrypt data.
Asymmetric ciphers allow to split encryption and decryption between two different keys.
The most used and famous asymmetric cipher is RSA.
The creation of the two keys (one public and one private) uses maths that are not so hard to understand (with prime numbers).
If you want to dive deeper into the subject feel free to read: https://en.wikipedia.org/wiki/RSA_(cryptosystem).
The main principles and steps of asymmetric ciphers (RSA) to remember are:
- a keypair is generated using prime number maths.
- one key can be given to everybody (this key is called ‘public key’). With this key, anybody can encrypt data.
- the other key is kept secret and will allow the owner to decrypt any message.
Hence with this system, anybody can encrypt data but is unable to decrypt it.
Only the creator of the keypair can decrypt messages (because he owns the secret private key).
Diffie-Hellman key exchange
Diffie-Hellman is a process enabling two parties to agree on a secret private key (symmetric) in an insecure environment (where anyone could see data exchanged between the 2 parties).
Diffie-Hellman is used for:
- SSH
- TLS 1.3
- PKI (public key infrastructure)
- IPsec (VPN)
Notes
It is also possible to agree on a private symmetric key (AES for example) over RSA just by using the public key to encrypt a symmetric key which should be used for every future communication.
However Diffie-Hellman has an interesting property called Perfect Forward Secrecy (PFS).
This means that even if the long-term key is leaked at a later date, the session keys for individual connections are not compromised, even if the full data stream is captured.
Source: Polynomial on stackexchange
Hash
A hash function takes an arbitrary length data as input and will output a unique fixed length data.
Hash functions can be seen as algorithms calculating a “fingerprint” of data.
Because hash functions have an infinite possible inputs and a limited number of outputs, some collisions can occur.
Hash collision is when 2 different inputs produce the same output for a given hash function.
This is not a desirable effect and can be used for attacks.
Good hash functions try to:
- Be very fast to compute
- Minimize duplication of output values (collisions must be hard to guess / predict).
Some hash functions
Keyed-hash message authentication code (HMAC)
HMAC is a process which involves both a hash function and a secret pre-shared key between two parties to simultaneously verify both the data integrity and the authenticity of a message.
Thanks to HMAC, the two hosts can guarantee that the messages they exchange have not been modified and come from the right host.
HMAC is a tool used to create a digital signature for a message.
Nobody can modify the messages exchanged between 2 parties who agreed on the shared private key or the HMAC won’t match.
Digital Signature
Digital signature uses RSA to separate the signer and the verifier (it is one of HMAC weaknesses).
In Figure 7 if Alice wants to share a message with Bob:
- She begins by generating a RSA keypair and sharing her public key with Bob.
- Then she calculates a hash value ‘H’ of her message.
- Alice uses her private RSA key to encrypt the hash ‘H’ into ‘H-encrypted’.
- Alice sends the message (on the network for instance) by adding ‘H-encrypted’ at the end of the message.
- Bob decrypts ‘H-encrypted’ from the received message back into ‘H’ thanks to Alice’s public key.
- Bob then calculates a hash H2 from the received message sent by Alice (with the same hash function).
- Bob finally compares H2 and H.
- If the two hashes match, then Bob can be sure that it was Alice who sent the message !
Certificates
There is an issue with digital signatures:
How can the public key be trusted ?
The solution is to create a X.509 certificate for that public key.
A certificate binds a public key and owner identity informations together (company, individual) thanks to a CA (Certification Authority).
In Figure 8, Mario Rossi wants to share his public key.
He can thus do the following:
Generate a private key (“.pem” file):
— openssl genrsa -out private.pem 2048
Generate a public key
— openssl rsa -in private.pem -outform PEM -pubout -out public.pem
Then Create a CSR (Certificate Signing Request)
— openssl req -new -key private.pem -out certificate.csr
After having generated a CSR, Mario Rossi will have to send his CSR to a certification authority (CA).
Once the CSR has been received, the certification authority will make some identity verifications (DNS ownership verification for instance).
Once the verifications succeeded, the CA will encrypt Mario’s CSR using its CA private key.
Mario will then add the signature the CA returned and will add it to it’s CSR.
This will be its official certificate.
Mario can now add that official certificate to whatever he sends.
The receiver (such as a web browser) embeds by default most common CA public keys and will therefore be able to decrypt Mario’s official certificate.
Intermediate certificates
A CSR is generally not signed by a root CA but by an intermediate CA.
It is made possible thanks to certificate chaining.
Because the name of the issuer of each certificate is written inside it, the client (browser for instance) can check whether it has the public key of the root CA of that chain.
When a TLS connection is opened, the server will send all the necessary intermediate certificates to the client.
Self-signed certificates
Certificates can be self-signed (easier and quicker to manage for testing purposes).
In a self-signed certificate, the CA and the certificate sender are the same.
As you can see in the figure above, the certificate’s fields “Issued to” and “Issued by” are identical.
Thus the client is not able to get a chain of certificates to one of its well known root certificates.
The end !
I hope you enjoyed this blog post, if you see any error don’t hesitate to let me know.
You can also follow me on twitter and check out the references below if you want to dive deeper into the subject.
References
Books
VPNs Illustrated: Tunnels, VPNs, and IPsec — Jon C. Snader
Websites
https://en.wikipedia.org/wiki/Digital_signature
https://www.youtube.com/watch?v=stsWa9A3sOM
https://security.stackexchange.com/questions/108508/how-do-i-produce-a-ca-signed-public-key
https://en.wikipedia.org/wiki/X.509
https://en.wikipedia.org/wiki/Certificate_signing_request
https://www.certeurope.fr/blog/guide-csr-certificat/
https://fr.wikipedia.org/wiki/Transport_Layer_Security
https://medium.com/asecuritysite-when-bob-met-alice/ephemeral-diffie-hellman-c07c54afabff
Images
Figure 2
https://miro.medium.com/max/3372/1*bbCyiW35hBU3GiaiF4Qcmw.png
Figure 3
VPNs Illustrated: Tunnels, VPNs, and IPsec — Jon C. Snader
Figure 4
https://www.educative.io/edpresso/what-is-the-rsa-algorithm
Figure 5
https://www.practicalnetworking.net/series/cryptography/diffie-hellman/
Figure 6
https://crypto.stackexchange.com/questions/68307/what-is-the-difference-between-sha-3-and-sha-256
Figure 7
https://en.wikipedia.org/wiki/Digital_signature
Figure 8
https://en.wikipedia.org/wiki/Public_key_certificate
Figure 9
https://en.wikipedia.org/wiki/Certificate_authority
Figure 10
https://ldapwiki.com/wiki/Certificate%20Chain
Figure 11
https://www.veeam.com/blog/generate-and-install-ssl-certificates-on-microsoft-windows.html
