Notes on Cryptography
Some notes on cryptography.
Some rough notes on cryptography.
Hashing Function Design
- Fast to compute
- Produce unique output values
- Produce the same output given the same input
- Difficult to reverse out the original input
- Storing data without knowing the value
- Used for comparison purposes
MD5 -> SHA256 -> ARGON2 -> ARGON2ID
Rainbow Tables
Pre-compute the hash of common passwords, faster to lookup by hash than to brute force.
HMAC
A hash that requires a password, so the person must have the password to create the key. Hash based message authentication code - the password is an input to the hash creation, so if you use two different passwords to hash a message you'll get two different outputs.
Message Signing
The sender of the message uses their private key to obtain a signature of the original message. Attach the signature to the original message. The recipient uses the public key to validate the authenticity of the message and that it hasn't been tampered with.
Symmetric and Asymmetric Encryption
Allowing people to know the value of the data as long as they have the key to decrypt it correctly.
Encrypt some message using a password. How does the recipient know how to decrypt it? Sharing the password is risky as it could be intercepted. This is what asymmetric encryption looks to solve. We generate pairs of public and private keys which are intrinsically linked but can not be derived from one another.
We can then encrypt data using the public key and it can only be decrypted with the associated private key. This means you can share your public key, and as long as you have the private key, you can decrypt any ciphertext which has been encrypted using the associated shareable public key.
The security of asymmetric encryption therefore relies on the ability to protect your own private key in order to protect messages which you are receiving (not sending).
Head tattoos were once one of the ways we hid information
Private Key Encryption - Symmetric
The same key is used in both the encryption and decryption of data.
Easy to use, but has problems - how do you get the key to the party with whom you're sharing data? If the PK is used for 2 way communication and the key is compromised then both sides of the communication channel become compromised.
Stream Cypher
A single bit at a time, done on the fly, bit by bit e.g. RC4
Block Cypher
Operate on fixed length blocks of data e.g. 256bits DES, Triple DES, IDEA, RC5, AES
Public Key Encryption - Asymmetric
Because the key is public, you can't verify who the sender actually is. To do this, you need to use a digital signature.
One way function
Easy to compute in one direction, very hard/impossible to compute the inverse e.g. prime factorization.
Prime Factorization
Given 2 primes, we can compute their product. Given the product of p and q is x and that p and q are primes, find p and q - this is much harder.
Trapdoor Function
Like one way function, except if you have access to a trapdoor (a secret) then doing the inverse is easy. You can easily fall through a trapdoor, then it's hard to get out unless you have a ladder.
A trapdoor for a prime factorization problem is having one of the primes already.
Hash Functions
- Hard or impossible to reverse from only the digest.
- Fixed sized digest irregardless of input length.
- Unique
Salt and Pepper
Salt - random value for each password. Take the hash of the password and the salt. You hash the salted password. Combat rainbow tables.
Pepper - the same secret value for all users. You can add pepper as well as salt before hashing.
Because I couldn't resist
Coprime
We can break down a number into factors. If the largest common factor between 2 numbers is 1, then they are co-prime.
e.g. 5 has factors of 1 and 5 10 has factors of 1,2,5
The largest common factor between 5 and 10 is 5, therefore they are not co-prime.
e.g. 3 has factors of 1 and 3 5 has factors of 1 and 5 The largest common factor between 3 and 5 is 1, therefore they are co-prime.
Any 2 primes are co-prime. Any 2 consecutive numbers are co-prime.
No Optimus Prime Jokes!
Browser Communication
The web server generates the key pair. The browser initiates the connection to the web server to negotiate the details of the encryption algorithms they will use. The web server replies back and sends back the public key to use.
The browser can then encrypt it's local private key, using the public key from the web server. This can then we sent to the web server, and only be decrypted by the web server (as it has the private key). The browser and the server now have the same secret key, which can be used for session level encryption (now using faster symmetric encryption).
How do you know the public key returned by the server is the real one, not that of a man in the middle? Use digital certificates.
The browser has public keys of existing certificate authorities built in. The browser will believe all certs issued by it. It has a public key to verify the certificate signature. You verify a digital signature using it's public key.
When a web server sends it's public key to the browser, it also sends the digital certificate. The browser then checks the validity of the digital certificate, which determines whether you can trust the public key the web server sent too you.
Kerberos
Use the user's password as an encryption key with requests to the authentication server. The auth server sends back a ticket. The ticket is sent to a granting server with the actual request the client wants to do. The ticket is decrypted by the granting server (it knows the secret key used on the ticket issued by the auth server), and it sends back a token. This token is then used to access the underlying resource by the user - the token is verified with the granting service from the service which is having resources requested from it.
Certificate Requests
You fill out a certificate request having generated your public-private keypair. The request goes to a certificate authority who will issue you your certificate. The cert has your public key, it provides a trustworthy way of giving out your public key.
The certificate authority is supposed to be a trusted third party. CA chains to establish a chain of trust. The CA encrypts the hash of the certificate using the CA's private key - this can be decrypted using the CA's public key.