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

[Ximin Luo]

Hey, thanks for the post. It's always nice to hear about new work on ratchets.

+1 for writing new applications/libraries in Rust and ditching C/C++.

On 04/09/15 21:42, Ian Miers wrote:
>   * Performance: depends on message distribution. Assuming a poisson process for initial messages (you only need this for initial messages, after that use Axolotl or another ratchet):  
> 

Could you explain the intention of {combining this with a ratchet} in a bit more detail? From your description, it sounds like your protocol "offers the same service" as a ratchet. What is the point of using two of them? Or from another viewpoint, why don't I use only "a ratchet" and avoid your scheme entirely?

In general, I think lossy ratchets are not good things to use for *a single session* which should have its whole integrity guaranteed. But one can use them to bootstrap "seed keys" for non-lossy ratchets that protect a whole session, to prevent drop attacks forcing you to re-use the same long-term key for the first message of each session. (By "non-lossy ratchet" I mean ones that don't allow holes in the middle of the session as Axolotl does; one can always implement a "delete keys and end the session if I don't get a heartbeat within X time", as you mentioned later.)

> [..]
> 
> While this ensures forward security, it means late arriving messages (either due to delays or badly set clocks) can't be decrypted. This means we face a choice: either have fine grained forward security with short intervals and risk losing messages or have long intervals and leave more exposed.
> 
> Our scheme, Puncturable Forward Secure Encryption, avoids this. Instead of deleting keys, we update ("puncture" them) every time we receive a ciphertext. Once punctured on a ciphertext, a key cannot decrypt that message but can decrypt new ciphertexts (e.g. late arrivals). Obviously, keys can be deleted at some point to avoid an attacker dropping messages and then breaking into your computer later.
> 
> Unfortunately, decryption is linear in the number of punctures. However, punctures are per time interval and don't cary over, so if we make our time intervals short, we only expect to see one message per interval and never need to decrypt with a punctured key. This ends up being very efficient. It does mean performance depends on your message distribution. When you only get one message in an interval it works very well.
> 

Do you have a paper that describes this in more detail?

It sounds sort of like an inside-out Axolotl - i.e. chaining ("intervals") then a DH-ratchet inside that ("puncturing"), or maybe even a chain-inside-a-chain? Could you compare your scheme with those options?

I'm not sure why you distinguish "puncture" as a different operation from "delete". In forward-secure protocols, whenever you "delete" a key you usually replace it with a new one so you can keep decrypting later ciphertext, but that's what you also define "puncture" to be.

> If you get many messages in an interval, performance only in that interval linearly worse but is still manageable for a while. (For those of you wondering about DOS, the system can always fall back to the time based approach. If too many messages arrive in an interval we can stop puncturing and lock in whatever performance we have for that interval.... you probably should delete that key soon after the interval expires). If you have high variance in your message distribution, you're going to need to use shorter intervals to ensure you usually get one message per interval. Past a certain point, this will also get expensive and the entire scheme might not be well suited to your needs.   I don't think this is close to the common case at all. For most applications, I think you can reasonably ensure you get one message per interval on average.
> 

Are you expecting the application / higher layer to manage this itself? This would get awfully complex to do "properly", especially for non-security-trained application writers.

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/7469f427/attachment.sig>