<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><span style="-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);"><br>On Sep 7, 2013, at 3:25 PM, "Christian Huitema" <<a href="mailto:huitema@huitema.net" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="1">huitema@huitema.net</a>> wrote:<br><br></span><blockquote type="cite"><font color="#000000"><span style="-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);">Another argument is “minimal dependency.” If you use public key, you depend on both the public key algorithm, to establish the key, and the symmetric key algorithm, to protect the session. If you just use symmetric key, you depend on only one algorithm.<br></span></font></blockquote><blockquote type="cite"><font color="#000000"><span style="-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);"><br></span></font></blockquote><blockquote type="cite"><font color="#000000"><span style="-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);">Of course, that means getting pair-wise shared secrets, and protecting them. Whether that’s harder or more fragile than maintaining a key ring is a matter of debate. It is probably more robust than relying on CA.<br></span></font></blockquote><span style="-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);"><br>Pairwise shared secrets are just about the only thing that scales worse than public key distribution by way of PGP key fingerprints on business cards.  The equivalent of CAs in an all-symmetric world is KDCs.  Instead of having the power to enable an active attack on you today, KDCs have the power to enable a passive attack on you forever.  If we want secure crypto that can be used by everyone, with minimal trust, public key is the only way to do it.  <br><br>One pretty sensible thing to do is to remember keys established in previous sessions, and use those combined with the next session.  For example, if we do Diffie-Hellman today and establish a shared key K, we should both store that key, and we should try to reuse it next time as an additional input into our KDF.  That is, next time we use Diffie-Hellman to establish K1, then we get actual-key = KDF(K1, K, other protocol details).  That means that if even one session was established securely, the communications are secure (up to the symmetric crypto strength) forevermore.  <br></span><br><blockquote type="cite"><font color="#000000"><span style="-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);">- -- Christian Huitema</span></font></blockquote><br><div>--John</div></body></html>