[147312] in cryptography@c2.net mail archive
Re: [Cryptography] [cryptography] Asynchronous forward secrecy
daemon@ATHENA.MIT.EDU (Eugen Leitl)
Sat Sep 28 12:43:27 2013
X-Original-To: cryptography@metzdowd.com
Date: Fri, 27 Sep 2013 12:49:29 +0200
From: Eugen Leitl <eugen@leitl.org>
To: Cryptography List <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============2543227471509678807==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="w7rMSzuJ2Q4FQLk/"
Content-Disposition: inline
--w7rMSzuJ2Q4FQLk/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
----- Forwarded message from zooko <zooko@zooko.com> -----
Date: Fri, 27 Sep 2013 00:08:32 +0400
=46rom: zooko <zooko@zooko.com>
To: Michael Rogers <michael@briarproject.org>
Cc: Randombit List <cryptography@randombit.net>
Subject: Re: [cryptography] Asynchronous forward secrecy encryption
User-Agent: Mutt/1.5.21 (2010-09-15)
Let me just mention that this conversation is AWESOME. I only wish the folks
over at Perry's Crypto List (http://www.metzdowd.com/pipermail/cryptography=
/)
knew that we were having such a great conversation over here.
On Thu, Sep 19, 2013 at 09:20:04PM +0100, Michael Rogers wrote:
>
> The key reuse issue isn't related to the choice between time-based and me=
ssage-based updates. It's caused by keys and IVs in the current design bein=
g derived deterministically from the shared secret and the sequence number.=
If an endpoint crashes and restarts, it may reuse a key and IV with new pl=
aintext. Not good.
Another defense against this is to generate the IV from the plaintext, poss=
ibly
=66rom the plaintext in addition to other stuff. There are three things tha=
t you
might want to throw into your IV generator: 1. the plaintext, 2. a persiste=
nt
secret key used only for this purpose and known only to this client, 3. a
random nonce read from the operating system.
I would suggest including 1 and 2 but not 3.
This *could* be seen as an alternative to the defense you described:
> In the new design, the temporary keys are still derived deterministically=
from the shared secret, but the IVs and ephemeral keys are random.
Or it could be used as an added, redundant defense. I guess if it is an add=
ed,
redundant defense then this is the same as including the random nonce -- nu=
mber
3 from the list above.
Regards,
Zooko
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
----- End forwarded message -----
--=20
Eugen* Leitl <a href=3D"http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org
AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5
--w7rMSzuJ2Q4FQLk/
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBAgAGBQJSRWK5AAoJEPRuNImsiU7FRf4QAJRwIZ9kS11CAwuOB7sP/1xC
11SMDVhYCUxWjPH2K1c48t+810cAPcNbBWBBsAEbsQDSBe+IlaCdlsCo6dyS9L02
TLRYybNwijsFpKex3PnTp+SzTlxsAsoHhQbT7reXO7MNVugisCApwCS9+K7jHAbY
u5Y/G4xxhcAEE1MJRZMFA+sPP2rRtw3NLqW0q+w0SoAvAtbhkzXYgMkEFch+uKy9
q0KxnbiS3DbFSvunbjqYFXPmCDbT1IwYuVGLEsC2+JjToA/klbppZf04WVAWOUlS
OvKRAjcSZJhkf4YhqTcTNyQdK34l4okRHSNBrCE0o7uvGyfHz0AtfKFAbwJkemse
sAMMtNpDpxMKFruQop7AnmPPOE9u4c6FV/S3DAIsFVcvQRXV5jZwmYS9By9CS1vl
5kUpf1YAQa+0618V2VJD5znEqr1z3zj94skVgHwV5hAl1HjxhOthTEwajOhPelAl
Gi71opFICQIJ6id/d8AM7oy1yWtE3ec0MaXYG7GyYo45QzDV/ABoAKtB4SY1kSjv
Fg/MYWDjYTztNNtqW0SXo/fRmD9DFc3LSvoDlsTjEfVr5UwLrPCzHoH5AM+GlOL9
evdrRaE6iynhre29M98/mSAnvqSpIRf/6jS6ipBLmO/XbsEotukG4cu8zcmuncOL
czvFArpW++HazQz8IZE0
=QOPn
-----END PGP SIGNATURE-----
--w7rMSzuJ2Q4FQLk/--
--===============2543227471509678807==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============2543227471509678807==--
