[861] in cryptography@c2.net mail archive
refreshing shared secrets (Re: forward secrecy and email protocols)
daemon@ATHENA.MIT.EDU (Adam Back)
Mon May 19 12:29:31 1997
Date: Sat, 17 May 1997 00:50:50 +0100
From: Adam Back <aba@dcs.ex.ac.uk>
To: pgut001@cs.auckland.ac.nz
CC: hal@rain.org, cryptography@c2.net
In-reply-to: <86381673303941@cs26.cs.auckland.ac.nz>
(pgut001@cs.auckland.ac.nz)
Peter Gutmann <pgut001@cs.auckland.ac.nz> writes:
> >[Hal's K' = H( K ) protocol]
>
> You don't really get forward secrecy because if someone compromises session
> key n then they also have n+1, n+2, ... A while back I thought of using
> something like SKEME to exchange a master secret and derive new session keys
> from this (that is, from the master secret, not from another session key),
> which still isn't perfect because a compromise of the master secret (rather
> than one session key) compromises the session keys.
For email, a solution I considered is to use any replies to email
which happen to occur to replace the shared secret. Reduces the value
of the current shared secret, and the previous shared secrets in the
chain which are related via K' = H( K ), in that less messages are
obtainable with passive attack only on key compromise.
You can also use the same thing to avoid the need for an interactive
(at the comms level) communication to obtain forward secrecy, just
have the system be non forward secret until there is a reply.
I also think that the shared secret K should be protected similarly to
your authentication key. Although it is of lesser value, it would
benefit greatly from being password protected as this greatly
increases the level of attack required.
So perhaps Alice and Bob might communicate as follows:
Alice Bob comments
1) M1 & DH public value --> not foward secret yet
2) <-- M2 & DH public val forward secret from
this point onwards
relying on shared
secret K0
K1 = H( K0 ) K1 = H( K0 ) discard K0
3) M3 & new DH public val --> PFS relying on K1 & K0
4) M4 & new DH public val --> PFS relying on K0
5) <-- M5 & new DH public val Start with a new K0
and so on. It is forward secret from the point of first reply. Both
parties send a new DH public value with each message so that in the
event there is a reply they will be using as recent as possible keying
material to minimise exposure. Message 1 is non forward secret,
message 2 is forward secret. Message 3 and 4 are also forward secret
but the keying material has been exposed for longer (stored on both
parties hard disks).
You may as well take the opportunity to develop more recent forward
secrecy if you reply to someone where you already have previous
forward secrecy which has been stretched out using Hal's hashing
technique.
The typical relative sensitivity of communications for which there are
replies as compared to those for which there are not is something
which it is worthwhile thinking about also.
If you send a message once via a remailer, the recipient may be
particularly keen for it the decryption to be forward secret.
If you send out a mass mailing to many people (an announcement,
newsletter, etc), where no reply is expected in the majority of cases,
forward secrecy is less meaningful because many people have seen the
message, and so the message is less `secret' in general because many
people have read it, printed it out, saved it in plain text, scribbled
it across their swap file etc.
If you have on ongoing discussion with someone, you may like the
contents to be forward secret. You probably care more about the
forward secrecy of such messages than you do about the mass mailing
kind. You might care less about such messages than you would about
something which arrived via a remailer unsolicited, although this
depends on the topic, your correspondent, etc.
The remailer problem is the worst to address, you have no opportunity
to exchange keys, and it may be the most sensitive situation.
Mass mailings are also hard to address, but presumably typically less
sensitive.
The ongoing discussion can be covered somewhat by using one
interactive exchange, and the security is improved by refreshing the
shared secret where replies take place.
Adam
--
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/
print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
