[messaging] libforwardsec: forward secure encryption for email and asynchronous messaging

[Ximin Luo]

On 05/09/15 12:27, Ximin Luo wrote:
> Do you have a paper that describes this in more detail?
> 

I just found the paper and skimmed through it. To answer my own questions, the differences between this and e.g. a typical ratchet is that:

- the encrypted messages are not ordered, within an interval; ratchets encode an implicit order to the messages, in when they must be decrypted. This is probably a good thing; you can always add ordering on the layer above if needed.
- don't need to generate a new random ephemeral key for each session, which is very good

So I can see the benefits of using this to seed Axolotl sessions (or a non-lossy ratchet as I suggested previously).

However, I don't think you suggest a good performance tradeoff for users of your library:

- In a solely interval-based scheme, after a delay/unsync of T the message become undecryptable. Messages sent within <T of each other, are not forward-secret with respect to each other. If we want them to be so, we must reduce T.

- Your scheme allows one to set a greater T, and still retain forward secrecy for individual messages within this time interval, at the cost of decryption performance. But then you suggest that users should set T to expect "1 message per interval", which roughly neutralises this benefit - messages delayed for longer than time T will again become undecryptable, just like in a naive interval-based scheme. Then the benefit is very small (i.e. those rare messages that are sent <T are still FS wrt each other), which probably doesn't justify the complexity of using this scheme.

In other words, the tradeoff can be expressed as "the application can pay extra CPU cost to allow for longer-delayed messages / worse-synchronised clocks", and this (I guess) is something that users of your library will need to understand, judge for themselves, and set when using your library. The topic could be studied further too, to figure out what the best way of actually making this trade-off is.

On another note, do you think it would be feasible to come up with a Puncture scheme that has a lower decryption cost? Or, alternatively, is this expected to be mathematically impossible?

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20150905/7f4addc1/attachment.sig>