5

DH key agreement protocols require the participation of both parties, so are only suitable for synchronous connections. Is it possible to implement PFS in a fashion usable for asynchronous protocols, like e-mail, or storage? I'm intuitively thinking not, but I haven't be able to find conclusive proof one way or the other.

David
  • 334
  • 2
  • 9
  • http://google.com/#output=search&q=forward-secure+PKE $;$ –  Jul 17 '13 at 05:20
  • 2
    @RickyDemer Pointing to a search engine like Google is not really useful, as the results are changing. Could you select some relevant papers and add them? Or even better, write an answer with the key points of some of these papers? – Paŭlo Ebermann Jul 17 '13 at 17:50

2 Answers2

5

Asynchronous forward secure encryption is possible if you allow users to have synchronous clocks. It seems impossible without that or a third party, though I am aware of no formal result.

A trivial(and hence awful) solution is to generate N key pairs and use one for each interval, discarding them as we go. A somewhat more efficient solution is to use Identity Based Encryption(IBE) to have one public key and N private keys.

The most efficient scheme I know of is due to Canetti, Halevi, and Katz in this paper. It provides for constant size public keys and $O(log(N))$ private keys where N is the number of time intervals. As far as I know, no paper has improved on that bound, though several have achieved that bound with more efficient techniques.

The gist of the design is you have a tree of keys where there is one root public key and messages can be encrypted to any node in the tree with the root public key and the index identifying the node. (So far, this is just an IBE scheme). Unlike IBE, the decryption key for a given node can be computed from it's parent key.

We now map time intervals to nodes using a pre order traversal (i.e. the root is interval one, the left child interval 2, the left left grandchild of root is interval 3 ...). So once time interval 1 is up, we derive the keys for both the left and right nodes and then delete the root key. Now messages encrypted to interval one are safe, but we can still decrypt everything targeted at the remaining N-1 intervals.

kelalaka
  • 48,443
  • 11
  • 116
  • 196
imichaelmiers
  • 1,614
  • 10
  • 13
  • Your suggested traversal will eventually require storing $:\Omega(N):$ private keys. $;;;$ –  Jul 17 '13 at 09:26
  • @RickyDemer I don't see how. Call the node you had for the previous interval node X. You will have node X's right child key(if X is an internal node) and the left child key of every node between X and Root inclusive. Since the tree is of height $log(N)$ this gives you at most N keys at any given time. – imichaelmiers Jul 17 '13 at 17:23
  • Ah, I see that I misunderstood what the pre-order traversal is. $:$ (However, the last sentence of your comment would be compatible with my previous comment.) $;;;$ –  Jul 17 '13 at 19:13
  • @Yes, I should have said you end up with $log(N)$ keys. – imichaelmiers Jul 17 '13 at 20:17
2

There's been some interesting research published since @imichaelmiers's answer. It looks like asynchronous messaging / 0-RTT / store-and-forward isn't quite as incompatible with practical perfect forward secrecy as was once thought!

I don't think any of these actually have production-ready implementations yet - especially not the first two, which are too slow for practical use - and of course you want cryptographers to beat them up and see if any problems shake out.

sam
  • 21
  • 1