cryptography

3 min read

20 Jul 23 5:44 pm type: related: why crypto

cryptography

  • always evolving
  • key concepts like hashing, encryption and signing are important

hashing?

  • one way algo
  • result is called a digest, digital fingerprint or hashfile
  • same size digest regardless of how big the input is

takes an input → passes it to a fn ( md5, sha, argon2) → output a hash/digest

real life usecase

  • allows us to store data without needing to know it’s true value. eg - password
  • if the hashes match up, we know that the original values are same ( used to verify passwords etc )

eg. sha256 ( 256 bit digest )

problem: just a hash isnt enough to store passwd on a db. ppl reuse passwds and a hacker could just ctrl f the hash on a large set of pass:hashes

salting?

if people use similar passwords, they’ll have the same hash, so if i had a record of general passwords like password123 and all the hashes for them, i can just query the hash and find the password like that → which is stupid.

a salt is a random value that’s added to the password before it’s hashed

we generate a salt and send it to a scrypt fn which takes in a passwd and a salt and generates a 64 bit digest which is the hashed

salts are generally stored on the db in this format

password: "{salt}:{hashedpassword}"

timing attacks

while matching the hashes, always use timingSafe equality checks so that the hackers dont get information based on time to compare the two hashes

HMAC

hash based message authentication code

  • 2 users communicating securely using HMAC must have a shared key

eg: JWT

the key is incl in the hashing fn and different keys to the same message result in different hashes.

encryption

take a message → create a cipher text from an encryption algorithm → allow someone to decrypt by using the same algorithm

mostly randomized, so everytime you encrypt, you get a diff cipher text

symmetric

  • shared password/key which the sender and reciever of the message will need eg. DES (56 bit key), triple DES, aes256 (128 bit key)

problem with symmetric: both parties need a shared password, and sharing is awkward

assymetric encryption

  • solves problems in symmetric encryption by using a keypair system
  • real life usecase: browser x websites in https
    • browser finds public/1st key in SSL certificate installed on website
    • public/1st key’s used to encrypt data thats sent to website
    • malicious actors cant read the data being transferred
    • data is decrypted on server using the private/2nd key

when something’s encrypted using your public key, only you can read it using your private key

eg. rsa is most famous - multiple size keys - 1024, 2048, 3072, 4096 etc

problem: if anyone can encrypt using my public key, how will others know if i sent it or not? - digital signatures

symmetric vs assymetric

if asymmetric is so good, why do we even need symmetric?

  • asm is slower
  • high CPU usage

signing and digital signatures

to verify the authenticity of the sender

  • sender hashes their message using an algorithm like rsa-sha256

  • sender signs with private key

  • sender sends message & signature to receiver

  • receiver gets message + signature ( and also knows the public key of the sender )

  • receiver creates a verifier of an algorithm like rsa-sha256

  • receiver passes in message to the verifier

  • receiver verifies the authenticity by checking with public key and signature.

  • verifier proves authenticity by returning true / false

references

https://www.youtube.com/watch?v=NuyzuNBFWxQ

Graph View

Backlinks