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

[Ximin Luo]

Thanks for the explanation previously. Let me put it into different terms, which might make it clearer for others. Your scheme decouples these two things:

1. the ability to prevent decryption of messages sent in the past (that were not received)
2. the abliity to prevent re-decryption of already-decrypted ciphertext

The first one as you say is dependent on the user, and is something that would affect *all* forward secrecy schemes; the second one is always safe to do.

In a simple interval-based approach, these two things are bound together. So we keep the key for one interval around, because keeping keys for N intervals is equivalent to setting T = N * T'. Then the user has the awkward decision of having to choose T to balance (1) with (2).

In your scheme, you can keep keys for multiple intervals around, and this has equivalent security to setting T = N * T', but lets us avoid paying the Puncture decryption cost. (I see now that you did actually suggest this in section VIII of the paper.) This is better for the user, who now only has to consider (1) when choosing T, since the library handles (2) in all cases.

I think it's good to make this point (the decoupling) with more weight moving forward. It is, at first, non-intuitive to suggest to set T to expect 1 message per interval, since this "feels pointless" ("if you Puncture once most of the time, how is this different from just deleting the key"), but it's this decoupling of concerns that makes this not actually pointless.

X

On 05/09/15 22:17, Ian Miers wrote:
> Yep. There definitely is that issue. At some point, you should delete interval keys to protect you from a TLA dropping your messages in transit and then sending a black bag team into your house/cave/press office or grabbing your computer at the border.   At  least  that decision is completely an OPSEC consideration  and one that varies considerably between users. For some, an hour is probably too long. For others, 24 hours might be on the short side. But it's a completely free choice (you can even change it after making your keys) for individuals or for application developers using libforwardsec. And unlike previous schemes, if you choose a long window you are not exposing messages you did receive.
> 
> I think this is an inherent problem with the intersection of  offline delivery and forward security.  If I recall correctly, TextSecure faces a similar trade off on when to delete  prekeys. 
> 
> - Ian (apparently that one)
> 
> On Sat, Sep 5, 2015 at 3:28 PM, Ian Goldberg <ian at cypherpunks.ca <mailto:ian at cypherpunks.ca>> wrote:
> 
>     Ian,
> 
>     Overall, a very nice scheme, and it's great you're producing
>     production-quality code for it!
> 
>     There's still the potential issue I asked about at the end of your
>     Oakland talk, though: the forward secrecy only kicks in if the intended
>     recipient actually _receives_ the original message, which is a slightly
>     different property than "traditional" forward secrecy.  If the TLA
>     (three-letter agency) doesn't just snoop the message, but actually
>     intercepts (blocks) it, they can come a-knocking an arbitrary(*) time
>     later to the intended recipient to compel the key that will decrypt it.
> 
>     (*) Up to when you _do_ decide to delete old keys, which is when you
>     give up on any messages that arrive late/desynchronized.
> 
>        - Ian (not that one)

-- 
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/20150906/4db6bcd3/attachment.sig>