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

[Ximin Luo]

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

-------------- 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/8b385992/attachment.sig>