Introduction
sequenceDiagram actor Alice actor Bob Note over Alice,Bob: Both parties have k #8592; Gen(1^#lambda;) %% encryption and decryption Note over Alice: c #8592; Enc(k,m) Alice ->> Bob: c Note over Bob: m #8592; Dec(k,c)
An outline of how a symmetric cipher works is given above. There are 3 main components:
-
Key Generator (over a key space )
-
Encryption (over a message space )
-
Decryption (over a ciphertext space )
We should understand that has a -bit input. is known as the security parameter.
We also expect , this is known as correctness property.
Note that if we know we learn the key space. With that, if we know message space and , then we will know the ciphertext space as well. Message is also known as plaintext; and, "Private key", "Secret key", "Symmetric key" all mean the same thing usually.
Old Ciphers
We will briefly describe some notable ciphers used back in the day.
Caesar Cipher
A very old example of cryptogrpahy is by Julius Caesar back then, we simply rotate the alphabet.
Notice that key generation does not care about , and both encryption and decryption does not use the key. It is very easy to break this cipher; you could simply look at the letter frequencies, or digram (pair of letters) frequencies.
Vigenere Cipher
The key is CRYPTO.
k = C R Y P T O C R Y P T O C R Y P T
m = W H A T A N I C E D A Y T O D A Y
------------------------------------- (+ mod 26)
c = Z Z Z J U C L U D T U N W G C Q S
Every th character has the same shift. This was pretty powerful back then, but it is breakable; especially if you know the key length beforehand. In fact, the key length can be found by looking at the uniformity of the characters.
For a Vigenere cipher with key length to :
- determining the key length
- determining the bytes of key
- brute-force
Rotor Machines
Then came the rotor machines, such as Enigma Machine. Details omitted. All of the examples so far has been "substituion ciphers" where characters are mapped to some other character.
Digital Ciphers
Not that long ago there was DES (1974), AES (aka Rijndael, 2001) and Salsa20 (2008).
Modern Cryptography Principles
- Precise and format definition of security must be presented.
- Assumptions should be clear, minimal and basic, complete.
- Rigorous proof of security must be given.
Provably secure schemes can be broken if the definition does not correspond to reality, or if the assumptions are invalid. The best assumptions are ones that are old (thus still valid against test of time), simple (thus generic enough), and shared (thus general enough).
1: Formal Definition of Secure Encryption
Let us try to define the term "secure".
- ❌ - "No adversary can find the secret key, no matter what the ciphertext is.": Well, provides this, but is definitely not secure ;)
- ❌ - "No adversary can find the plaintext from the ciphertext.": satisfies this, but is obviously not secure.
- ❌ - "No adversary can determine and character of the plaintext that correspond to the ciphertext.": This sounds good, but the adversary can still learn which characters of the alphabet is used, which may be bad. For example if the adversary learns the characters and the message is 3 letters, it is probably "hey".
- ✔️ - "No adversary can compute any function of the plaintext from the ciphertext": Now that sounds formal, but we need to be more formal!
Note that is a function of plaintext that gives its length. It is often very hard to hide this, so the last bullet often allows this function to be computable.
2: Assumptions
To make well assumptions, one usually considers threat models, i.e. how powerful is the adversary? There are 4 threat models, with increasing attack power:
- Ciphertext-only attack: The adversary can attack just by looking at one (or many) ciphertexts.
- Known-plaintext attack
- Chosen-plaintext attack
- Chosen-ciphertext attack
A good security definition against ciphertext-only attack is: "regardless of any prior information the attacker has about the plaintext, the ciphertext should leak no additional information about the plaintext."
3. Proofs
Typical proof of a scheme will show using a constructive argument, that if is broken, some assumption will be violated.
- If there exists an algorithm for breaking , then we can construct an algorithm to break the assumption .
- If is efficient (i.e. runs in probabilistic polynomial time) then so is .
- The proof cannot present (in which case is already broken) but must present the "code" of . We always assume exists.
These all assume that if assumption holds, is secure.