Online Bids, Spam Reduction, Secret Sharing, Visual Cryptography, Random Numbers

CS166

Chris Pollett

Oct 8, 2012

Outline

Last week, we were talking about hash functions and at the end of Wednesday, we briefly went over some uses of hash functions, today we are going to loook at some of these uses in details... We begin by considering online bidding.
Suppose Alice, Bob and Charlie are bidders
Alice plans to bid `A`, Bob `B` and Charlie `C`
They don't trust that bids will stay secret; nevertheless, they would like bids to be made simultaneously without knowledge of other bids.
One solution possible to this problem:
- Alice, Bob, Charlie submit hashes `h(A)`, `h(B)`, `h(C)`.
- All hashes received and posted online.
- Then bids `A`, `B`, and `C` submitted and revealed
Hashes don't reveal bids (one way)
Can't change bid after hash sent (collision)
But there is a flaw here... If we know that the bids lie in the range $10,000 to $20,000, we might only have 10,000 things to try to hash to figure out the other bids before `A`, `B`, `C` revealed.
Might want to share a secret salt first, to solve this problem.

Before accept email, want proof that sender spent effort to create email.
Here, effort == CPU cycles
Goal is to limit the amount of email that can be sent
- This approach will not eliminate spam
- Instead, make spam more costly to send

Let
`M` = email message
`R` = value to be determined
`T` = current time
Sender must find `R` so that:
`h(M,R,T) = (00 ... 0,X)`,
where `N` initial bits of hash value are all zero
Sender then sends `(M,R,T)`
Recipient accepts email, provided that... `h(M,R,T)` begins with `N` zeros and provided `T` is not too long ago.

The oligarchy PKI trust model is what's used by most browsers.
The birthday attack can be used to at most half the number of keys you need to search to find a collision.
RFC 2104 computes an HMAC as `h(M,K)`.

Random numbers used to generate keys
- Symmetric keys
- RSA: Prime numbers
- Diffie Hellman: secret values
Random numbers used for nonces
- Sometimes a sequence is OK
- But sometimes nonces must be random
Random numbers also used in simulations, statistics, etc. Such numbers need to be "statistically" random

There are `52! > 2^(225)` possible shuffles
The poker program used a "random" 32-bit integer to determine the shuffle So, only `2^(32)` distinct shuffles could occur
Code used Pascal pseudo-random number generator (PRNG): Randomize()
Seed value for PRNG was function of number of milliseconds since midnight
Less than `2^(27)` milliseconds in a day.
So, less than `2^(27)` possible shuffles

Seed based on milliseconds since midnight
PRNG re-seeded with each shuffle
By synchronizing clock with server, number of shuffles that need to be tested < `2^(18)`
Could then test all `2^18` in real time -- Test each possible shuffle against "up" cards
Attacker knows every card after the first of five rounds of betting!

Poker program is an extreme example
- But common PRNGs are predictable
- Only a question of how many outputs must be observed before determining the sequence
Crypto random sequences not predictable
- For example, keystream from RC4 cipher
- But "seed" (or key) selection is still an issue!
How to generate initial random values?
- Keys (and, in some cases, seed values)

True "randomness" hard to define
In nature, the entropy of a system is a measure of its randomness
Good sources of "randomness" from nature
- Radioactive decay -- radioactive computers are not too popular
- Hardware devices -- many good ones on the market
- Lava lamp -- relies on chaotic behavior

Sources of randomness via software
- Software is (hopefully) deterministic
- So must rely on external "random" events
- Mouse movements, keyboard dynamics, network activity, etc., etc.
Can get quality random bits by such methods
But quantity of bits is very limited
Bottom line: "The use of pseudo-random processes to generate secret quantities can result in pseudo-security"