ITIS 6200/8200

time-stamping services Difficult to verify the creation date and accurate contents of a digital file Required properties of time-stamping –Data, instead of the storage medium, should be stamped –Minor change in source file leads to major changes in stamp –Low probability of conflict

Time-stamping using TTP –Alice sends a file to T –T keeps the file, date, and time in the record –When it is needed, T can provide the evidence –Problems: Need a TTP What about data error during transmission? Need huge storage space Why should Alice tell the secret to T? Collusion between Alice and T

Time-stamping using TTP –Using hash result and digital signature we can fix most of the problems –Alice asks T to sign the hash result of the file –T sends the digital signature back to Alice, T does not need to record the file –Alice verifies the signature and make sure that no error happens during transmission

How to defend against collusion –Linking protocol: every signature is restricted by the previous one and the following one –T will sign: –Alice will also receive the owner of the next hash result I n+1

How does the linking protocol mitigate the collusion between T and Alice –The timestamp is restricted by the previous one and the next one –T cannot predict the order of the requesters –Possible way to compromise this method: T generates fake event sequences and leaves some gaps for future use Counteraction: linking a longer sequence

Removing TTP: using Distributed hash table –Alice uses Hn as seed to generate a group of node ID using a pseudo random number generator –Alice sends out Hn to these nodes –These nodes will sign with their digital signatures and send it back –Alice can use these signatures to prove the timestamp

Why it is difficult for Alice to collude with all these nodes? –The node IDs are generated through a pseudo random number generator based on Hn, Alice cannot predict those IDs –Similar ideas have been used in P2P systems and location-based routing for wireless networks

The generation of a hash tree –Need to timestamp a large number of files –Using the hash values to construct a tree –Publish only the root of the tree –Provide corresponding entries in the tree to the end users so that they can verify

Bit commitment Alice needs to commit a prediction which will not be revealed until later. Bob needs to make sure that Alice cannot change it. How can we do that? Example: –Picking stocks: who will go first? –Be careful of the forward search attack –Attack to such commitment: racing horses Why this attack can be conducted: limited commitment space

Bit commitment using symmetric encryption –Bob generates a random number R and sends to Alice –Alice generates a secret session key k, send back E_k(R, committed bit) –Bob does not know k, so cannot recover the bit –Later Alice reveals the key so Bob can verify it

Problems of bit commitment using symmetric key encryption –Why E_k(b) cannot commit the bit? –If Bob does not provide the random number, Alice can decrypt the same cipher-text with different keys and generate one ended with “1” and the other ended with “0” –How about Alice generates R A and tells Bob? For example E_k(R A, b) –It is very difficult for Alice to find two different keys that can generate the same cipher-text with E_k(R, “0”) and E_k’(R, “1”). However, allowing Alice to generate R A will allow her to do pre-computation.

Bit commitment using one-way function –Can we use Hash(R A, b) to commit a bit? If Alice does not tell Bob R A, forward search by Alice If Alice tells Bob R A, Bob can figure out the bit –A better protocol: Alice generates two random numbers, R1 and R2 Alice sends (R1, Hash(R1, R2, b)) to Bob to commit the bit –Why we need R1 in plain text? –Why do we need R2 in cipher-text? Later, Alice gives Bob R1, R2, and b to verify

The advantage of this protocol: –Bob does not need to send anything –It is very difficult to find Hash(R1, R2, “0”) = Hash(R1, R2’, “1”) if R1 is long enough and the one way function has been properly designed

Fair coin flip in digital world –It is different from the real world, where both parties can see the coin –The properties we need: Alice flips the coin before Bob guesses Alice cannot change the result after Bob guesses Bob cannot “see” the result before taking the guess –It seems that bit commitment can solve this problem

Coin flip using bit commitment –Alice commits to a bit using one of the previous protocols –Bob guesses the value of the bit –If right, Bob wins, if wrong, Alice wins –After the guess, Bob must be able to verify the result

Coin flip using one-way functions –Alice generates a random number X, and sends Hash(X) to Bob –Bob guess whether X is odd or even –If Bob guesses right, Bob wins, otherwise, Alice wins –Alice reveals X so that Bob can verify. –If Alice can find two numbers (one odd, one even) having the same hash result, she can control the result every time.

Coin flip using commutative encryption (where E_k1(E_k2(msg)) = E_k2(E_k1(msg)) –Alice generates two messages, (R1, Head), (R2, Tail), sends E_k1(m1) and E_k1(m2) to Bob –Bob selects one message and sends back E_k2(E_k1(m)), Alice does not know which one Bob choose –Alice decrypts the message and sends back to Bob, Bob decrypts it again and tells Alice the random number and the result –Alice and Bob reveal their keys to verify the result

Coin flip using commutative encryption –Can Bob cheat? Not if he cannot guess the random string –Can Alice cheat? Send both messages with Head. But later when they reveal the key, Alice will be caught. Alice can lie about the value of R1 and R2: Bob can ask for their hash values before the messages are sent An application of coin flip: –Generate session keys in a collaborative method where no party has a total control –We can flip multiple bits simultaneously

Mental poker: play card on network –Commutative encryption methods will be used –Every party re-encrypt and shuffle the cards to prevent cheating –Example of 3 nodes to play poker

Anonymous key distribution using commutative encryption –Some nodes do not have enough resources to generate secure session keys –A Key Distribution Center will generate keys. But we want to make sure that KDC does not know which key is used by which node. –Solution: commutative encryption