Other Protocols Multiple key Public key cryptography * RSA and other methods can be generalized to involve n keys. if 0 < m < n keys are used for encryption, then the other n-m keys decrypt. None can be derived from any subset of the others. * In RSA, instead of choosing e,d so that e * d = 1 mod(p-1)(q-1) choose e1, e2, ..., en so that e1 * e2 * ... * en = 1 mod(p-1)(q-1) * If you give out n-1 keys per person using a leave-one-out scheme, you can, for any specified subset, encode a message that only the people in that subset can read (just use the left-out keys of the desired subset). * You do need to send the list of intended recipients as well, and everyone has a lot of key data. There are some other schemes that avoid these problems. * If you give out 1 key per person, you can arrange a message so that an arbitrary subset of the recipient needs to get together to read it (just leave out their keys when encrypting the message). Secret splitting * Take some message M , XOR it with a random string R , give U = M XOR R to one party, the random string R to another. * Neither can read the message unless they pool their resources. U XOR R = M XOR R XOR R = M * Equivalent to a one-time pad, so this is absolutely secure. * Generalizes to n parties: XOR the message M with n different random strings U = M XOR R1 XOR R2 XOR ... XOR Rn. Give U to one party, R1 - Rn to n-1 other parties. They must all be present to reconstruct the message. * OK kids, you each have a piece of the number of my Swiss bank account. So does my lawyer. If I die, you all have to get together to open it... * Of course there are problems if one party gets hit by a truck... Secret sharing * Suppose we want to arrange things so it take 5 out of 7 colonels to initiate a nuclear strike. * It is possible to generalize the previous idea so that m out of n pieces are needed to reconstruct a message, and any m will suffice. * This is sometimes called a "threshold scheme", and the pieces are called "shadows" * One general technique: Let the message be the coefficients of some sort of polynomial equation of degree m-1. Each shadow could be a point satisfying the equation. With m of them, it is possible to solve for the coefficients of the interpolating polynomial of degree m-1. * Turns out that if the polynomial is of the form ax^m + bx^(m-1) + ... + kx + M mod p where M is the message, the constants a, b, ..., k are chosen randomly, and p is a prime larger than any message, Then the coefficients, given m shadows, can be obtained by solving a set of linear equations, and the scheme is as secure as a one-time pad for any number of people less than m. * All sorts of schemes can be constructed by giving people different numbers of shadows. * Generalizations are known that allow any boolean formulation of the required decision-makers to be implemented (e.g. [(Bob and Alice) or (Alice and Carol and Dave)] ... * There are schemes that protenct against cheaters who might try, e.g., to hear everyone's shadow and then run out saying HaHa!, I'm really Mallory, not Dave, and now I know three shadows... ---------------------------------------------------------------------------- Timestamping services: (Digital notary) * Need to certify that a document existed on a certain date * Data itself must be stamped, regardless of the medium on which it resides. * It should be impossible to change the data without it being apparent. * It should be impossible to timestamp a document with a date and time other than the current one. Arbitrated solution 1. Alice transmits a document to Trent 2. Trent records time and date, and keeps it along with a copy of the document * No privacy * Huge database * Trent has to be involved in every validation * Trent could be damaged or compromised in some way * Trent might not be absolutely reliable. How would you feel about a document notarized by Dan's pawnshop, check cashing, and timestamp services? Improved Arbitration 1. Alice sends a one-way hash of a document to Trent. 2. Trent appends the data and time to the hash, and signs the result. 3. Trent sends the signed result back to Alice. * No privacy problem, no database problem, Trent does not need to be involved for validation. * Trent is signing unknown bits, which might be risky * Alice and Trent can still collude Linking * To reduce the possibility of Alice and Trent colluding, Trent could include linking information to the previous timestamp (or several) that he issued to (someone other than Alice), and send Alice a pointer to the next document he stamps after he does it. * This provides a check on the time. Alice and Trent now have to involve more people in the conspiracy. * Getting hold of those other people could be problematical if the issue ever came up. Distributed protocol: 1. Alice uses the hash H of the document as seed to a cryptologically secure random number generator. 2. Alice interprets the output as addresses of a subset of a large pool of potential verifiers, and sendsH to each of them 3. Each of these people attach date and time, sign the result, and send it back to Alice. 4. Alice saves all the signed hashes as her timestamp. * Collusion unlikely in this environment, as Alice can't select the output of the generator * You need a reasonably large set of potential verifiers, so that Alice can't try variations until she hits her three friends. * Quite a bit of "extra" work seems to be being done here, just to avoid potential for cheating. * Might be hard to talk people into belonging to this pool * Might work if pool was 1000 "professional" notaries, and Alice needed signatures of 6, and they got paid for the service... ---------------------------------------------------------------------------- Bit Commitment Bob wants Alice to commit to some position at some point in time, but Alice does not want Bob to know what she committed to until some later date. * Maybe Alice claims she can predict the stock market but doesn't want Bob to profit on any prediction without paying her. * Maybe Alice is submitting a bid on a city contract, but doesn't trust Bob in the mayor's office not to look at her bid and tell his uncle's construction company about it so they can undercut her. Symmetric Encryption Solution 1. Bob generates a random string R and sends it to Alice 2. Alice appends the bit(s) b or message she wishes to commit to, encrypts it with some key K, and sends it back to Bob. 3. When it is time to reveal the message, Alice sends Bob the key K. 4. Bob decrypts the message, checks his random number, and read Alice's bit(s) b. * Bob's random number is protection against Alice trying different decryption keys after sending the commitment to Bob, until she finds one that produces the bits she wants after the fact. This is mainly a problem if Alices message really is a single (or a few) bits, rather than something intelligible. Solution using One-way functions 1. Alice generates random strings R1 and R2, and creates a message (R1, R2, b) where b are the bits she wishes to commit to. 2. Alice computes a one-way hash of the message, and sends the result to Bob along with one of the random numbers. [H(R1,R2,b),R1] ==> Bob 3. When it is time to reveal the bits, Alice send Bob the unhashed message. R1,R2,b. 4. Bob checks that the hash is valid, and that R1 is correct. * R1 keeps Alice from sending Bob a hashed string that she knows several messages that hash to. This should be hard to do in any case, but Alice could have them ready in advance, having run a birthday search for several months prior. It is even better if Bob originates R1. * Alice needs to keep R2 secret to prevent Bob from trying a dictionary attack through the hash function to see which bits she sent. (Only a problem if Alice is sending one or a few bits). ------------------------------------------------------------------------------ Fair coin flips How can you flip a coin over the internet? Bob doesn't trust Alice or her random number generator, and she doesn't trust him or his. * One idea: Alice generates a random bit, Bob generates a random bit, and they XOR the two together. By really using a random generator, Alice can cancel any non-randomness Bob is employing, Bob can do the same. If they are both trying to cheat by guessing what the other will do, they deserve each other. * Only problem is they both have to generate our bits before they know about the other's. One way, using bit commitment: 1. Alice commits to a random bit 2. Bob sends his (random) guess of the bit to Alice. 3. Alice reveals her bit. * Workability depends on security of commitment process. * Bob might have to worry that Alice will lie about his guess later, and Alice likewise, he might want to sign it in case there is a dispute. More directly, using a one-way function f: 1. Alice selects a random number x, computes y = f(x) 2. Alice sends y to Bob. 3. Bob guesses if x is odd or even and sends guess to Alice. 4. If Bob is correct, he wins (or the flip is heads). Alice announces the result of the flip, and sends x to Bob 5. Bob verifies that f(x) = y. * The parity of x must be uncorrelated with any easily computable property of f(x). So f is not only one-way, but has cryptologically strong pseudorandom properties. * Alice must not be able to find even one pair x and x' such that x is odd and x' is even, and f(x) = f(x') = y. * Alice and Bob might still worry about disputes.