CS551: Security and Privacy on the Internet, Fall 2000
Problem Set 3: Public-Key Cryptosystems Selected Answers
Problem 1: 17.8 (15 + 20)
Problem 2: 14.4 (15)
Problem 3: 23.8 (30 + 15)
Problem 4: 7.2 (10)
Problem 5: 21.2 (30)
1. Key DistributionRecall the Keys "R" Us distribution scheme from Lecture 6:
The protocol is:
- Alice meets securely with Keys "R" Us and agrees on secret key KA
- Bob meets securely with Keys "R" Us and agrees on secret key KB
- Alice sends E ("Bob", KA) to Keys "R" Us
- Keys "R" Us generate a new, random key: K1
- Keys "R" US sends Alice, E (K1, KA); Alice decrypts using KA to get K1.
- Keys "R" US sends Bob, E ("Alice" || K1, KB); Bob decrypts using KB to get K1.
- Alice and Bob communicate using shared secret key K1.
a. (15) One of the problems with the Keys "R" Us protocol is the trusted third party can eavesdrop on all communications between Alice and Bob since Keys "R" Us knows K1. Suggest a modification to the scheme that solves this problem.
Your solution should satisfy these requirements:
Alice and Bob may meet securely with (hint: one or more) trusted third parties at the beginning of the protocol.
- Alice and Bob agree on a secret key, K1, without ever meeting.
- Alice and Bob can be assured they are communicating with each other.
- No one besides Alice and Bob (including (semi-) trusted parties and eavesdroppers) can obtain any information about K1. You may assume there is a perfect encryption function E (m, k), and that independent semi-trusted third do not conspire together.
- Your scheme must not use exponentiation or modulo arithmetic. (It shouldn't be based on a public-key cryptosystems we have seen.)
Answer: With two trusted third parties it is simple. Alice and Bob each establish secret keys with Keys "R" Us and eKeys. Alice and Bob use the original protocol to establish K1 through Keys "R" Us, and use the original protocol through eKeys to establish K2. Alice and Bob communicate securely using K = K1 XOR K2. Neither Keys "R" Us nor eKeys can independently decode the messages.
b. (up to 20 bonus points) Since Alice and Bob are having an illicit affair (its a cyber affair, so they still cannot meet in person to exchange keys), not only do they want their messages to be private, they don't want anyone else to know they are even communicating with each other. Once they have obtained a secret key, this is easy: Alice posts her encrypted message in a public place where Bob knows to look (for example, they can place classified ads in the New York Times).
Adapt your solution to (a) to meet the additional requirement that no one (including trusted parties) can know Alice and Bob are communicating with each other. The other requirements should still hold, including Alice and Bob still obtain a shared secret key, and Alice should be confident she is communicating with Bob and vice versa.
Answer: Without using public-key techniques, this is much harder.
One approach (Aaron Bajek and GJ Halfond suggested schemes similar to this, but vulnerable to traffic analysis) is to give each person a bit string identifier (e.g., Alice is 10010, Bob is 01011). There must be enouch people in the system so that most bit-strings are used. If the bit-string are 5-bits long, there should be 32 people in the system, and an attacker should have no better than 1/31 chance of guessing who Alice is having an affair with (this assumes she isn't having an illicit affair with herself).
To establish secret communication with Bob, Alice sends "0xxxx" to a randomly-choosen trusted party (the more trusted parties there are the more secure the scheme is; ideally, there should be one per ID bit). The trusted party creates two random keys, K_0 and K_0x, and sends K_0 to each person whose ID starts with 0 (encrypted with the shared secret key each individual has with the trusted third party). The trusted party sends K_0x to every person whose ID starts with 1. This is a decoy message, but necessary if we want to be secure against traffic analysis attacks. If the trusted third party didn't send this out, an attacker could monitor all the traffic on the network and know that Alice wants to communicate with someone whose ID starts with 0. The trusted third party also send Alice K_0 encrypted with the secret key shared between Alice and the trusted third party. (Because K_0 is encrypted, an eavesdropper cannot tell if Alice was sent K_0 or K_0x).
Next, Alice sends "x1xxx" to a different randomly-choosen semi-trusted party. This party generates K_1 and K_1x, and sends it out according to the same protocol as the first trusted party used for K_0. The process continues through each ID bit.
At the end of the process, Alice and Bob both have K_0, K_1, ..., K_n. They calculate K = K_0 XOR K_1 XOR ... XOR K_n and use this as the secret key for communication. No semi-trusted third party knows more than one bit of the ID, so they have at best a 1 in n/2 chance of guessing with whom Alice is communicating.
Alice knows she is really communicating with Bob, because only Bob recieves all the components of K. Bob, however, does not know he is really communicating with Alice. One easy (but expensive) way he could authenticate this is to do the process in reverse where he is the one how initiates the communication. This produces a new key K'. If they communicate using K XOR K', both Alice and Bob know they are communicating with the right person.
Using public-key protocols, we can accomplish the same thing with considerably less effort. Alice just encrypts her message using Bob's public key and posts it in the newspaper. Only Bob can read it (using his private key), and no one else can tell the message is between Alice and Bob. If she also encrypts it using her private key, Bob can authenticate that the message came from Alice using her public key. (Later, we will see some examples of anonymous email and web browsing that provide similar anonymity to newspaper classified over the Internet. We can do this by sending messages along a chain of randomly choosen forwarding servers, with the next destination encrypted using the next server's public key.)
2. Primal TendanciesIn the RSA paper, the authors claim that it is okay to use a probablistic prime number test since if a composite number is choosen the receiver would probably detecte it by noticing that decryption didn't work correctly.
That is, choosing a composite number is not likely to lead to a substantial security flaw, since the problem would be detected in the first transmission. Note that if it were not detected, choosing a composite number for p or q would be bad, because an attacker would have an easier time factoring n = p * q = (p1 * p2) * q since one of the p factors is small (around sqrt (sqrt (n))).
a. (10) Illustrate that decryption doesn't work if the choosen p is composite using an example. That is, pick p, q, e and d consistent with the RSA algorithm except p is composite, and show for some M: D (E (M)) ¹ M.
Answer: Here is an example (based on Dave Rubens' answer):p = 4, q = 7So, D (E (M)) is not equal to M, and RSA breaks when we choose composite p.
n = 28
Phi(n) = (p - 1) (q - 1) = 18
e = 11 gcd(11,18) = 1 so e is valid.
d = 5 e * d = 55 == 1 mod 18
M = 2
E (M) = Me mod n = 2048 mod 28 = 4
D (4) = Cd mod n = 45 mod 28 = 1024 mod 28 = 16
b. (5) Show how the proof that D (E (M)) = M breaks if p is composite. (You don't need to reproduce a complete proof, just identify the step of the proof that depends on p being prime.)
The proof breaks becase the totient function equality depends on n being prime:If n is prime, (n) = n - 1.If n is composite, this is not true.
3. Public-Key PokerAlice, Bob and Colleen Hacker want to play poker on the Internet. A playing card deck has 52 cards. They agree to identify each card using a number:suit = 0 | 1 | 2 | 3 (hearts, clubs, diamonds, spades) number = 1 (Ace) | 2 | 3 | ... | 10 | 11 | 12 | 13 cardid = (13 * suit) + numberso the queen of diamonds is card 26 + 12 = 38.
Play proceeds as follows:
- Alice, Bob and Colleen each generate RSA public-private key pairs: KUA (Alice's public key), KRA (Alice's private key); KUB, KRB; KUC, KRC. The public keys KUA, KUB, KUC are securely published.
- Alice generates a "deck" of 52 cards, encrypts all cards with KUA. She sends all the cards in random order to Bob.
- Bob encrypts all cards with KUB, and sends the cards in random order to Colleen.
- Colleen encrypts all the cards with KUC, and sends the cards in random order to Alice. At this point, the card m is encrypted as EKUC [EKUB [EKUA [m]]]].
- Alice chooses five cards, and sends the remaning 47 cards to Bob (and keeps a copy of them for himself).
- Bob chooses five cards from the cards Alice sent, and sends the remaning 42 cards to Colleen (and keeps a copy of them for himself).
- Colleen chooses five cards from the cards Bob sent, and sends the remaining 37 cards to Alice.
- Each player publishes their private keys. The all decrypt their cards and reveal their hands. Each player also decrypts the cards they passed to the next player to make sure no one cheated.
a. (10) Alice and Bob are subject to the UVA Honor Code, but Colleen has no such scruples. After Colleen gets royal flushes (the best poker hand) for the first few hands, Alice and Bob begin to get suspicious that Colleen might be cheating. How is it possible for Colleen to always pick the best cards?
Since Colleen knows everyone's public key (as do all the other players), it is trivial for her to compute EKUC [EKUB [EKUA [m]]]] for each possible m, since there are only 52 possible m's and she knows they are 1, 2, ..., 52. She can then match the results with the deck, and know which card is which.
In general, it is not wise to encrypt guessable messages with a public key, since all an attacker has to do is try the possible messages and see if one matches.
b. (10) Suggest a simple modification to the protocol that makes it (nearly) impossible for Colleen (or anyone else) to cheat.
The easiest solution (which no one got) is for each player to just add a different random string to each card when they encrypt. So, the deck will be: EKUC [EKUB [EKUA [m + RA, i] + RB, j] + RC, k]. Since each player gets to add a random string, no player can determine the cards by trying a small number of messages. At the end of the game, the private keys are revealed, and each player can compare the random strings to make sure no one tampered with the cards.
c. (10 + up to 15 bonus points) In most poker games, cards are revealed one at a time followed by rounds of betting. Consider a poker game (5 card stud) that works as follows:
Design a protocol that supports a distributed poker game over the Internet. The closer you can get to the physical poker game described above, the better.
- Dealer shuffles the deck. The dealer is one of the players, and isn't trusted. The other players can observe that the dealer shuffles fairly.
- The player to the right of the dealer cuts the deck, just to make sure the shuffle was fair.
- The dealer gives each player (including herself) one card face down in turn, starting with the player to her left. Each player can read her own card, but this card will not be revealed to the other players until the end of the hand.
- The dealer gives each player (including herself) a second card, face up. All players can see the face up cards.
- The players make bets or fold. (You don't need to worry about this part of the poker protocol.)
- The dealer gives each player (including herself) a third card, face up.
- The players make bets or fold.
- The dealer gives each player (including herself) a fourth card, face up.
- The players make bets or fold.
- The dealer gives each player (including herself) a fifth card, face down.
- The players make bets or fold.
- All players still in the game reveal their face down cards, and the best hand wins the pot.
For bonus credit, your protocol must not allow any player to cheat, must not require a trusted third party, and should not require losing players to reveal their hands (or the dealer to reveal the unused cards) to catch cheaters. Regular credit (10 points) will be given to solutions which satisfy the no cheating requirement but not the other two. That is, if you can't solve it without a trusted third party dealer, submit a solution that uses one.
With a trusted third party, its easy:
Without a trusted third party, its extremely difficult. The main challenge is revealing the face-down cards to one player and face-up cards to all the players without revealing anything that can be used to determine the other cards. No completely satisfactory answers were submitted.
- All the players generate public-private key pairs: KUPi, KRPi. The trusted third party generates a public-private key pair: KUD, KRD. The public keys are published. Assuming the trusted third party is trustworthy, and none of the private keys are compromised, the protocol is secure.
- The trusted third party generates a deck of cards (using the solution from B) and shuffles them. There is no point in cutting the deck or making a player the dealer - either you trust the third party or you don't, and if you don't you shouldn't play! It is a bad idea to complicate the protocool with steps that are not necessary for security. Giving one player a chance to cut the deck is opening up your protocol to additional vulnerabilities.
- For face down cards, the trusted third party sends each player their card as EKRD [EKUPi [m]. Because it is encrypted using the player's public key, no other player can decrypt the card. Because it is encrypted using the trusted third party's private key, the player can authenticate it came from the trusted third party, and can decrypt the card using KUD.
- For face up cards, the trusted third party sends every player EKRD [player i: m]. Players can authenticate the message using KUD.
- At the end of the hand, the trusted third party reveals cards as necessary.
I believe the following protocol works --- but its complicated enough, that I'm not extremely confident. If you can find a significant flaw in this protocol, that is worth 20 bonus points.
First, we introduce this protocol which can be used to produce a random value which no part may influence:Random choice protocol
Assuming h is a one-way hash function, no one can cheat, since the hashes were already revealed. Each player has to choose their contribution to the random string without knowing the other values that will be XOR'd with it.
- Alice generates random bitstring RA, publishes h (RA).
- Bob generates random bitstring RB, publishes h (RB).
- Colleen generates random bitstring RC, publishes h (RC).
- After all hashes revealed, A, B and C reveal RA, RB and RC.
- The random bitstring is R = RA XOR RB XOR RC.
Now, let's play poker:
This protocol is believed to be correct, but a bit unwieldy for a practical poker game! If anyone can come up with a correct protocol that requires substantially less work (it must not require a separate key for each card), that is worth 100 bonus points.
- Pick a random R using the random choice protocol. (This isn't absolutely necessary, but it makes off-line attacks difficult, since the cards will be different each hand.)
- Alice generates a deck where each card is cardno XOR R.
- Alice picks a secret random bitstring RA. Each card is XOR'd with RA. Alice sends the cards in random order to Bob.
- Bob picks a secret random bitstring RB. Each card is XOR'd with RB. Bob sends the cards in random order to Colleen.
- Colleen picks a secret random bitstring RC. Each card is XOR'd with RC. Colleen publishes all the cards in random order, for all players to see. The cards are now:Cardi = mj XOR R XOR RA XOR RB XOR RCNo player can know which card each is because of the secret XORs and scramblings.
- Alice generates 52 secret random bitstrings, RAi. Alice scambles the deck, and replaces each card with a tuple:Cardi = < Cardj XOR RA XOR RAi, EKUA [RAXi]>Where RAXi is a different random string for each card. Alice keeps a table mapping RAXi to RAi, so when she is given RAXi she knows the corresponding RAi.
Note that the XOR with RA removes Alice's original random string from the cards without revealing RA to any other player.
Alice sends the new deck, in random order, to Bob.
- Bob follows the same protocol - scrambles the deck, XORing out RB from each card, XORing in a new different random string for each card, for the left element of the card tuple. Bob replaces the right element of the card tuple with:EKUB [old right tuple + RBXi]Hence, Bob will be able to undo this encryption using his private key to get RBXi and the Alice's right tuple (which has no meaning to Bob). Also, note that even if Alice eavsdropps on the deck Bob sends to Colleen, she cannot determine the shuffle since the left halfs have been XOR'ed randomly, and the right halfs have been encrypted with Bob's public key.
- Colleen does the same thing as Bob. At this point, we have cancelled out RA, RB and RC. Each card is encoded as:Cardi =The whole deck can be published.
< mj XOR R XOR RAiA XOR RBiB XOR RCiC,
EKUC [EKUB [EKUA [RAXiA] + RBXiB] + RCXiC]
- Deal each player a face-down card. (Alice gets Card1, Bob gets Card2, Colleen gets Card3.)
- Alice decrypts her face-down card by sending the right half of the card to Colleen. Colleen uses KRC to undo the outer encryption on the right half of the card and get RCXiC. She uses this to lookup RCiC, and sends this to Alice as EKUA [EKRC [RCXiC]].
Colleen sends Bob the rest of the right half of the card: EKUB [EKUA [RAXiA] + RBXiB.
Bob undoes the KUB encryption using KRB, and obtains RBXiB. He looks up the corresponding RBi and sends this to Alice encrypted with her public key and his private key. Bob also sends Alice EKUA [RAXiA], which she can decrypt using her public key and use to lookup RAiA.
Alice can now calculate mj = (Left half of card) XOR R XOR RCiC XOR RBiB XOR RAiA.
She can view her face-down card, but no one else has obtained any information about this card of any other card.
- Bob decrypts his face-down card similarly. The difference is he sends EKUA [RAXiA] and Alice sends back RAiA, appropriately encrypted. Colleen decrypts her face-down card similarly.
- For a face-up card, they can follow the same protocol, except each player sends their corresponding Rpip to all other players, so that every player can view the card.
- At the end of the hand, the face-down cards for the winning player are revealed by each player revealing the corresponding Rpip. Players can detect cheating by comparing the resulting values with the deck after step 8.
4. Hash House Harriers(10) Lem E. Tweakit thinks he can improve on the Data Authentication Algorithm (described in Stalling, p. 252-3) when a smaller MAC is required by using Output Feedback Mode instead of the Cipher Block Chaining mode used by Data Authentication Algorithm. He produces a 16-bit MAC by using DES in 16-bit OFB mode starting with an intialization vector of zero, and uses the last ciphertext output as the MAC. Assuming 16 bits provides sufficient security for Lem's purposes, does this satisfy the required properties of a MAC function?
The last 16-bits produced by OFB depend only on the last 16-bits of the message! Hence, an attacker can change the first n - 16 bits of the message to anything she wants without getting caught. Compare this to Cipher Block Chaining, where the last 16-bits produced do depend on the whole message.
5. Interplanetary IOUsConsider the IOU request protocol from Lecture 9:
It works as follows:
This protocol is vulnerable to the Birthday Attack since Bob gets to select x. One solution is to use a large message digest (that is, have H(x) be 128 bits). Alice is on Mars, however, and her Interplanetary Internet connection is too slow to send 128 bits reliably.
- Bob sends Alice an IOU message, x.
- Alice computes H(x) using a cryptographic hash function, and sends Bob the hash result encrypted with her private key: EKRA [H (x)].
- Bob can decrypt EKRA [H (x)] using Alice's public key to verify that Alice signed the IOU message x.
- Bob can send M and EKRA [H (x)] to a Judge to prove that Alice agreed to the IOU message x.
Colleen Hacker suggests that Alice only agree to sign hashes for messages of the form I, Alice, owe Bob n dollars where n is an integer (written without spaces or commas). Alice and Bob securely inform the Judge that only messages of that form should be considered valid IOUs.
a. (15) Assuming Alice will only sign hashes for messages of the given form where n is in the range 1...212, how much work is it for Bob to cheat? That is, how much work must he do to with high probability find a pair of messages x = I, Alice, owe Bob n dollars and y = I, Alice, owe Bob m dollars where n is agreeable to Alice (in the range 1 - 4096, there are 212 possible x messages) and m > 10000?
To keep the math simple, you may assume that none of the choosen x message hash to the same value as any other x message, and none of y messages hash to the same value as any other y message. Note that this underestimates the actual amount of work required.
Using the no duplicates assumption, there are 212 different hash values corresponding to messages Alice will agree to sign. Bob needs find a message favorable to Bob (but disagreeable to Alice) that matches one of those has values. There are 264 possible hash values, so for one bad message, Bob has a 2-64 chance of matching a particular hash value, and a 2-64 * 212 = 252 chance of matching one of the good hash values. If Bob generates approximately 252 favorable messages, he has a good chance (but not a certainty) of finding a match. (Because of the simplifying assumptions, this was sufficient to get full credit.)
If we drop the simplifying assumption, the math gets much more complicated. Note that we cannot use the Birthday attack formula, since the number of possible good messages is limited to 212. We need to estimate the chances of finding a collision given different numbers of good and bad messages.
Since 212 is so small relative to the 264 possible hash values, let's assume there are still approximately 212 different good hash values. For each bad message we choose, we have a 2-52 chance of matching one of those hash values. Or, there is a 1 - 2-52 probability we don't find a match. So, if we try n bad messages, there is a (1 - 2-52)n probability there are no matches. Or, a 1 - (1 - 2-52)n probability of finding at least one match. We are looking for n such that this value is close to 1. Actually calculating n would require a good calculator.
b. (15) Suppose Alice owes Bob a legitimate debt of $1000, and signs a hash for the corresponding IOU message: I, Alice, owe Bob 1000 dollars. Alice refuses to pay, and Bob brings the case to Martian small claims court. He shows the Judge the IOU message and corresponding hash digest signed with Alice's private key.
Alice claims, "Yes, it is signed with my private key, but I didn't sign the IOU. A cracker broke into my machine and stole my private key, and posted it on the Internet. Bob forged the IOU. You should put Bob in jail instead of making me pay the IOU." To back up her statement, she shows the Judge a public Internet site that reveals her private key.
Suggest a way to prevent this. (Consider non-cryptographic solutions; if you find a purely cryptographic one you've done something amazing.)
The challenge is to either make it impossible for Alice to reveal hey private key intentionally or to make it so painful she would not do so. Lots of interesting answers were submitted, but no one (in this class or the world) has come up with a totally satisfactory solution.
One approach is to use the analogy of a public notary. When someone signs an important legal document, they use human witnesses who validate their identity (using a trustworthy photo ID), watch them sign the document, and then stamp the document with a notary seal. The virtual equivalent is a trusted third party that confirms Alice's identity, and then signs the document using its private key. The problem the trusted notary can't use Alice's private key to confirm her identity, since if that key is stolen the cracker could do this also. We can use physical means to authenticate Alice to the trusted notary, but this might be difficult or expensive if she is on Mars. We can use a different key, or a combination of the key a hardware challenge/response card, but Alice could still claim this were stolen.
Many suggests adding timestamps to the IOU. This is certainly a good idea, but does not completely solve the problem. If Alice's key is actually stolen, she probably will not find out until later (perhaps, when she first sees the bogus IOU), and there is no way to tell whether her key was really stolen before or after the IOU was timestamped.
Other approaches are to make it harder for Alice to (either accidentally or intentionally) reveal her private key. We could put the key on a smart card and have a special, tamper-proof device that uses the card to sign an IOU. This can be integrated with a password and biometric (although we saw how well biometrics work in "Sneakers") so that someone stealing the card alone cannot forge IOUs.
Another approach is to deter Alice from revealing her key, by encrypting some embarrassing information with it that will also be revealed. This has two challenges - someone needs to know Alice's key and the embarrassing information to ensure that the information she encrypts with her key is really embarrassing, and will be sufficient to prevent her from deliberately revealing her private key. This requires a very trustworthy trusted party indeed!
University of Virginia
Department of Computer Science
CS 551: Security and Privacy on the Internet