Security

//Symmetric vs asymmetric, and why real systems use both

Symmetric uses one shared key — fast, but the key must be exchanged safely, which is the hard part. Asymmetric solves the exchange but is slow. So real systems use asymmetric encryption once, just to agree a symmetric session key, and then use the fast symmetric method for the actual data.

//Digital signature — the direction matters

The sender hashes the message and encrypts the hash with their PRIVATE key. The receiver decrypts it with the sender's PUBLIC key and re-hashes the message. If the hashes match, the message is unaltered AND could only have come from the holder of that private key. Getting the keys the wrong way round loses the mark.

Sender:    hash(message) --encrypt with PRIVATE--> signature
Receiver:  signature --decrypt with PUBLIC--> hash A
           hash(received message) --> hash B
           A = B  ->  authentic and unaltered

//Digital certificate

A certificate issued by a trusted Certificate Authority binds a public key to an identity. Without it, an attacker could simply publish their own public key and claim to be the bank.

//What makes a good hash

It always gives the same output for the same input, produces a fixed-length result, is fast to compute, and is effectively impossible to reverse. Two different inputs giving the same hash is a collision, and a good algorithm makes that vanishingly unlikely.

CHECK YOURSELF