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 <[email protected]
> <mailto:[email protected]>> 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
