On 06/09/15 12:51, Ximin Luo wrote: > 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. >
Whoops, notation mess-up here. By "T" I meant the interval for the FS-PKE, and
the previous quoted sentence is not exactly correct. To be more clear, I should
have instead said:
This is better for the user, who now only has to consider (1) when choosing the
{time beyond which to delete old keys}, since the library handles (2) in all
cases. (He also has to tell the library what the {expected message interval}
is, but this can in theory be measured objectively, and doesn't require
security-related considerations.)
> 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.
>
--
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
