# CS代考程序代写 Cryptography Basics – (Pseudo)Randomness

Cryptography Basics – (Pseudo)Randomness

ECEN 4133 Jan 21, 2021

Review

•Integrity of messages between Alice and Bob

•Alice appends bits that only Alice (and Bob) can compute

•Solution: Message Authentication Code (MAC)

• Hash-based MAC (HMAC) used in practice, e.g. v = HMAC-SHA256k(M)

k

m, v

m’, v’?

k

•Where does k come from?

• How do we generate it? [Today]

• How do we share it with Alice and Bob, but not Mallory? [Next time]

Mallory

Alice

Bob

Randomness

True Randomness

Output of a physical process that is inherently random Scarce and hard to get

Pseudorandom generator (PRG)

Takes small seed that is really random

Generates long sequence of numbers that are “as good as random”

True Randomness

Where do we get true randomness?

Want “indistinguishable from random” meaning: adversary can’t guess it Gather lots of details about the computer that the adversary will have trouble

guessing [Examples?]

Problem: Adversary can predict some of this

Problem: How do you know when you have enough randomness?

Getting a large amount of randomness

Difficult to collect lots of true random

Suppose we have 128-bits of true random (k), but want 1024-bits of random ◦ Can we expand our 128-bits? [Breakout]

◦ Can we extend to arbitrary lengths?

◦ Any caveats? How many unique “sequences” of 1024-bits can we produce with this technique?

Getting a large amount of randomness

“Pseudo” Randomness:

◦ Not truly random – usually an expansion of a (shorter) set of true random bits

One solution: Pseudo-random number generator (PRNG):

◦ Given 128-bit true random k

◦ HMAC-SHA256k(0), HMAC-SHA256k(1), HMAC-SHA256k(2), … HMAC-SHA256k(n)

Is it secure?

◦ Can an adversary tell what will come next without knowing k?

◦ Given HMAC-SHA256k(a), (but not k), can an adversary predict HMAC-SHA256k(b) for b>a ?

Pseudo-random generators (PRG)

Many different ways:

◦ Using hashes

◦ Using HMACs

◦ Using block ciphers (we’ll talk about these next)

Beware that there also exist non-cryptographic PRNGs:

◦ Linear feedback shift register (LFSR)

◦ Linear Congruential Generator (LCG)

◦ Used by rand() / srand() / Math.random() – Don’t use for cryptography!!!

128 bits

k PRG

n bits

Output stream

We are talking about Cryptographically Secure PRNG (CSPRNG)

◦ Should be difficult for adversary to predict future (or past!) outputs given some output

“Backdoored” CSPRNG

Dual_EC_DRBG

◦ Dual Elliptic Curve Deterministic Random Bit Generator

◦ Developed by the NSA in 2006, standardized by NIST

◦ Strange design, very slow, based off elliptic curve cryptography (next week!)

◦ If someone knows a mathematical relationship between P and Q, trivial to compute what comes next in the pseudorandom stream given current output (backdoor!!)

◦ No explanation for how P and Q were chosen by the NSA

◦ NSA paid $10 million to RSA Security to include

in their popular cryptographic library

◦ Snowden documents revealed this to be a standard developed solely by the NSA as a backdoor

Randomness in practice

Modern OSes typically collect randomness, give you API calls to get it

e.g., Linux:

/dev/random is a device that gives random bits, blocks until available

/dev/urandom gives output of a PRG, nonblocking, seeded from /dev/random eventually

Note: both /dev/random and /dev/urandom use a CSPRNG seeded from: ◦ Keystroke/mouse movement timing

◦ Network packet timing

◦ Scheduler / interrupt timing

◦ /dev/random tries to do “entropy accounting”: don’t give out more than has been “put in” to the pool

/dev/(u)random problems

/dev/random blocks – slow to read from

/dev/urandom doesn’t block – but might not be initialized at all!!!

Embedded devices:

◦ Often don’t have keyboard/mouse

◦ Might not be connected to Internet at first boot (no packets) ◦ Very slow to collect entropy!

Solution:

◦ Usegetrandom()

◦ Added in Linux 3.17 (2014)

◦ Blocks until pool has been initialized

Confidentiality

Integrity: prevent Mallory from tampering kk

Alice

Mallory

Bob

k

Confidentiality: prevent eavesdropper (Eve) from learning the (plaintext) message

v’ == MACk(m’) ?

m, v:= MACk(m)

m’, v’

Terminology

p plaintext message

c ciphertext

k secret key

E encryption function D decryption function

k c := Ek(p) Eve

Bob

p := Dk(c)

Classical Cryptography

Digression: Classical Cryptography Caesar Cipher

First recorded use: Julius Caesar (100-44 BC)

Replaces each plaintext letter with one a fixed number of places down the alphabet Encryption: ci := (pi + k) mod 26

Decryption: pi := (ci – k) mod 26

e.g. (k=3):

Plain: +Shift:

=Cipher:

Plain:

ABCDEFGHIJKLMNOPQRSTUVWXYZ 33333333333333333333333333 DEFGHIJKLMNOPQRSTUVWXYZABC

fox go wolverines

+Key:

=Cipher: ira jr zroyhulqhv

333 33 3333333333

[Break the Caesar cipher?]

Cryptanalysis of the Caesar Cipher Only 26 possible keys:

Try every possible k by “brute force”

Can a computer recognize the right one?

Use frequency analysis: English text has distinctive letter frequency distribution

Lateradvance: VigènereCipher First described by Bellaso in 1553,

later misattributed to Vigenère

Called « le chiffre indéchiffrable » (“the indecipherable cipher”)

Encrypts successive letters using a sequence of Caesar ciphers determined by the letters of a keyword For an n-letter keyword k,

Encryption: ci := (pi + ki mod n) mod 26 Decryption: pi := (ci – ki mod n) mod 26

Example: k=ABC (i.e. k0=0, k1=1, k2=2)

Plain: bbbbbb amazon

+Key: 012012 012012 =Cipher: bcdbcd anczpp

[Break le chiffre indéchiffrable?]

Cryptanalysis of the Vigènere Cipher

Simple, if we know the keyword length, n: 1. Break ciphertext into n slices

2. Solve each slice as a Caesar cipher

How to find n? One way: Kasiski method Published 1863 by Kasiski (earlier known to Babbage?)

Repeated strings in long plaintext will sometimes, by coincidence, be encrypted with same key letters

Plain: CRYPTOISSHORTFORCRYPTOGRAPHY

+Key: ABCDABCDABCDABCDABCDABCDABCD =Cipher: CSASTPKVSIQUTGQUCSASTPIUAQJB

Distance between repeated strings in the ciphertext is likely a multiple of key length e.g., distance 16 implies n is 16, 8, 4, 2, or 1

Find multiple repeats to narrow down

[What if key is as long as the plaintext?]

One-time Pad (OTP)

Alice and Bob jointly generate a secret, very long, string of random bits

(the one-time pad, k) To encrypt: ci = pi xor ki To decrypt: pi = ci xor ki

“one-time” means you should never reuse any part of the pad. If you do:

Let ki be pad bit

Adversary learns (a xor ki) and (b xor ki) Adversary xors those to get (a xor b), which might be useful [How?]

Provably secure [Why?]

Usually impractical [Why? Exceptions?]

a b axorb 000 011 101 110

a xor b xor b = a a xor b xor a = b

Practical One-time Pad

Idea: Use a pseudorandom generator (CSPRNG) instead of a truly random pad

(Recall: Secure PRG inputs a seed k, outputs a stream that is practically indistinguishable from true randomness unless you know k)

Called a stream cipher:

1. Start with shared secret key k

2. Alice & Bob each use k to seed the PRG

3. To encrypt, Alice XORs next bit of her generator’s output with next bit of plaintext

4. To decrypt, Bob XORs next bit of his generator’s output with next bit of ciphertext

Works nicely, but: don’t ever reuse the key, or the generator output bits