4

Let's suppose we have an Alice who knows a secret key A, and Bob who knows key B. Using their own keys, they each encrypt a message (Alice encrypts $m_A$, Bob encrypts $m_B$) with their own key, and send the encrypted messages to one another.

Now is there some cryptographic scheme thinkable that lets Alice only decrypt her message (using key B) when Bob is able to decrypt his (via key A)? To guarantee that Alice will tell Bob her key after Bob told his?

The simplest solution would be a third-party which releases both keys at exactly the same time, but maybe there is also a cryptographic way to do this?

Maestro
  • 1,069
  • 1
  • 10
  • 16
  • 1
    Are you familiar with http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange? If yes, and this wouldn't meet your specific requirements, please explain why. – Henrick Hellström May 13 '13 at 10:09
  • @Joshua: $:$ How should Bob verify the key he gets? $;;;$ –  May 14 '13 at 01:07

2 Answers2

4

I think what you want to look at is "fair exchange". There's a giant catalog of protocols for fair exchange. They've been designed for doing exactly what (I think) you want.

See, e.g.,

Some fair exchange protocols require a third party who Alice and Bob trust, and involve the third party in the protocol. Others (called optimistic fair exchange) require that there be a trusted third party, but normally the third party does not have to be involved in any way -- the third party only gets involved to settle disputes, if something goes wrong. Still others try to avoid any third party (e.g., gradual fair exchange); they're not perfect, but they try to ensure that if Alice can learn Bob's message with some amount of effort, then Bob can learn Alice's messages with not too much more effort.

To learn more about fair exchange, do a literature search on fair exchange. There are lots of research papers on this topic.

Community
  • 1
D.W.
  • 36,365
  • 13
  • 102
  • 187
  • I've read the references you gave, but it seems there has been done very little research in this area. I cannot find any well-known protocol or implementation. – Maestro May 14 '13 at 13:30
  • "there has been done very little research in this area" - Not true. There have been tons of papers written on fair exchange protocols. (Google Scholar turns up over 100.) Have you done a literature search? You should. – D.W. May 15 '13 at 01:26
2

Note that it is probably technically impossible to meet your requirement that both secrets have to be revealed at exactly the same time, if interpreted literally. However, if we interpret this requirement as meaning that each party needs guarantees that the other party selected its own message, before decrypting the message of the other party, then this might be achieved using a scheme by which each party commits to a message without revealing it, before actually sending it.

Note: In order to guarantee that Alice will get $M_B$ when revealing $M_A$, you need a trusted third party. However, if your requirements are consistent with simply giving Alice the ability to abort further interactions with Bob if Bob decides to cheat, the following scheme should be sufficient.

For simplicity, suppose each party has a RSA key pair that can be used for both signing and encryption, and that Alice already has the public key of Bob, and vice versa.

  1. Alice selects a message $M_A$. Bob selects a message $M_B$.
  2. Alice selects a symmetric AES key $K_A$. Bob selects a symmetric AES key $K_B$.
  3. Alice generates $S_A = Sign_{Priv_A}(K_A)$. Bob generates $S_B = Sign_{Priv_B}(K_B)$.
  4. Alice generates $C_A = AESEnc_{K_A}(M_A)$. Bob generates $C_B = AESEnc_{K_B}(M_B)$.
  5. Alice sends $S_A,C_A$ to Bob. Bob sends $S_B,C_B$ to Alice.
  6. Alice generates $T_A = Encrypt_{Publ_B}(K_A)$. Bob generates $T_B = Encrypt_{Publ_A}(K_B)$
  7. Alice sends $T_A$ to Bob. Bob sends $T_B$ to Alice.
  8. Alice generates $K'_B = Decrypt_{Priv_A}(T_B)$ and aborts if $Verify_{Publ_B}(S_B,K'_B)$ fails. Bob generates $K'_A = Decrypt_{Priv_B}(T_A)$ and aborts if $Verify_{Publ_A}(S_A,K'_A)$ fails.
  9. Alice generates $M'_B = AESDec_{K'_B}(C_B)$. Bob generates $M'_A = AESDec_{K'_A}(C_A)$.

The above scheme should only be regarded as a general outline.

Henrick Hellström
  • 10,406
  • 1
  • 30
  • 58
  • I think you know this, but just to be very explicit: The protocol in this answer doesn't meet the requirement of the original question. If Alice is malicious, she can arrange to learn Bob's message without revealing her own message. – D.W. May 13 '13 at 17:46
  • Yes, that perhaps should be made explicit. The best you can do without a trusted third party, is to get the ability to abort if the other party tries to change its message after you reveal yours. For some scenarios that is enough. – Henrick Hellström May 13 '13 at 17:57
  • I think that "designated aborter" (as you described) and "an aborter can't learn the honest party's $;;$ message with much less effort than the honest party can learn the aborter's message" are the two optimal properties for the setting without a third party (and that a protocol in that setting can't have both of those). $:$ –  May 13 '13 at 20:59
  • @RickyDemer: Without additional assumptions and constraints, protocols with the latter property are not possible without a third party. http://www.cs.utexas.edu/~shmat/courses/cs395t_fall04/pagnia.pdf – Henrick Hellström May 13 '13 at 21:24
  • I suppose the assumption/constraint needed for the latter property is that $\hspace{1.33 in}$ computation is not much easier for the adversary. $:$ –  May 13 '13 at 21:37
  • @RickyDemer: Do you mean use e.g. 32 bit encryption, and swap keys before the other party has a chance to decrypt the message by brute force? I guess there are Internet Poker protocols based on such primitives. – Henrick Hellström May 13 '13 at 21:55
  • No, I mean hiding the key with a time-lock puzzle. $:$ –  May 13 '13 at 22:00
  • @RickyDemer: That's basically the same thing as using contemporary key stretching techniques for deriving a 128 bit key from a 32 bit key, so I guess you could have answered yes. :) – Henrick Hellström May 13 '13 at 22:11
  • That approach would let an adversary, with a correspondingly small probability, compute the honest $;;$ party's secret an arbitrary factor faster than the honest party can compute the adversary's secret. –  May 14 '13 at 01:06
  • @RickyDemer: Done right, yes. OTOH did I implement a bignum library that is approximately 100 times faster for similar 8192 bit integer operations, than another existing bignum library, on the same machine. Either way it boils down to how you define "much". – Henrick Hellström May 14 '13 at 05:51
  • You have a good point there. $:$ –  May 14 '13 at 05:57
  • @HenrickHellström The exchanged message would be a private key of cryptocurrency, so both parties are actually exchanging something of value, and aborting would be too late. Ill guess its just not possible without trusted mediator. – Maestro May 14 '13 at 21:38