Seems to me neither of you read the reference I gave:
I (Adam) wrote:
It is tricky to get forward secrecy for store-and-forard messaging [2],
but perhaps you could incorporate rekeying into your protocol in some
convenient way.
...
[2] http://cypherspace.org/adam/nifs/
Not impossible just not-obvious. You can use any ID based scheme as a
non-interactive forward secrecy scheme (without the negative connotations of
an ID based scheme - there is no central server able to decrypt your files
in the non-interactive FS use of the same crypto).
For example the Boneh-Fanklin weil pairing based scheme of Katz is the main
(only?) secure and efficient setup ID based scheme.
Personally I would super-encrypt with something conventional in case
the weil-pairing turned out not to be secure.
Also there are a number of things you can do operationally to send keys with
messages or distribute keys, Ian Brown & I wrote an RFC with extensions for
PGP for forward secrecy:
http://www.cypherspace.org/openpgp/pfs/openpgp-pfs.txt
Adam
On Wed, Feb 20, 2013 at 11:56:59AM +1000, James A. Donald wrote:
On 2013-02-20 6:21 AM, Jonathan Warren wrote:
It is tricky indeed. The handshaking necessary to set up the session key could
piggyback on the first couple messages that users send to one another although
those first several messages would not be forward-secret. I suppose that the
session key could then be replaced with each message sent: The sender of a
message would keep track of two session keys- one that the other party used
previously (so that you can receive consecutive replies) and a new one that you
are encouraging them to use on the next message. I think it would work.
If store and forward, cannot be forward secrecy.
Suppose that human readable messages, messages that might contain
important secrets, are only exchanged when the sender and the final
recipient are both online at the same time, then forward secrecy no
problem. Both parties set up a shared transient secret session key,
as usual, which goes away when offline, reboot, or timeout.
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
