<div dir="ltr"><div class="gmail_default" style="font-size:small">I thought people might be interested in two pieces of recent work.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default"><a href="http://prismproof.org/Documents/draft-hallambaker-jbcd-container.html">http://prismproof.org/Documents/draft-hallambaker-jbcd-container.html</a><br></div><div class="gmail_default"><a href="http://www.prismproof.org/Documents/draft-hallambaker-json-key-exchange.html">http://www.prismproof.org/Documents/draft-hallambaker-json-key-exchange.html</a><br></div><div class="gmail_default"><br></div><div class="gmail_default">The first is a cryptographic container format that provides a combination of</div><div class="gmail_default"><br></div><div class="gmail_default">* Zip file finctionality</div><div class="gmail_default">* Blockchain with Merkle tree functionality</div><div class="gmail_default">* Append only atomic log</div><div class="gmail_default">* Efficient random access with zero initialization overhead.</div><div class="gmail_default">* PKCS#7/CMS</div><div class="gmail_default"><br></div><div class="gmail_default">The key idea here is that the frames have length markers at the front and back so that it is equally efficient to access the last frame and work back as to read forward. So you can write out a file and then stick an index on the end. </div><div class="gmail_default"><br></div><div class="gmail_default">It also serves as a PKCS#7 replacement that avoids the need for ASN.1. The nice thing about this approach is that you can create an archive of encrypted and/or authenticated objects with separate public key information for each frame or information shared across frames as is needed.</div><div class="gmail_default"><br></div><div class="gmail_default"><br></div><div class="gmail_default">The second is a new key exchange that uses public key composition as the primitive.</div><div class="gmail_default"><br></div><div class="gmail_default">Something that has always struck me as odd with TLS is that we use encryption and signature to achieve key exchange. Why not just use Diffie Hellman?</div><div class="gmail_default"><br></div><div class="gmail_default">My exchange uses up to four keys. The client and the server ALWAYS contribute an ephemeral key that has the function of a nonce and also providing side channel resistance and forward secrecy. The client and/or server MAY also contribute an identity key.</div><div class="gmail_default"><br></div><div class="gmail_default">As the full paper shows, this key exchange is intended for use inside a TLS encrypted tunnel to authenticate transactions. Each transaction message is authenticated using a separate MAC. So injection attacks are defeated because only one command per message is valid.</div><div class="gmail_default"><br></div><div class="gmail_default">TLS client auth does not work very well because the TLS endpoint is usually not where you want it. So performing a second key exchange and authenticating within the tunnel is best.</div><div class="gmail_default"><br></div><div class="gmail_default">This leads to what I call the Triple Lock with three layers of encryption: Transport, Presentation and Data level. This provides for comprehensive protection unless traffic analysis with multiple observation points is a concern which can only be reasonably defeated using link layer encryption of some sort (including onion).</div><div class="gmail_default"><br></div><div class="gmail_default"><br></div><div class="gmail_default">The scheme may be used for rekey with a ratchet. The main reason for the ratchet is to make sure that rekey key exchanges never dilute the key strength. So if you start with a Ed448 exchange and then rekey with Ed25519, you still have the full Ed448 strength.</div><div class="gmail_default"><br></div><div class="gmail_default">If people look at the full <a href="http://prismproof.org">prismproof.org</a> site, you will note that I have authored 12 specs this year and have essentially designed and implemented an entire PKI from scratch in three years. I could really use some help on this. I am pretty sure that I can prove the key exchange correct but I don't have time to spend on that right now.</div><div class="gmail_default"><br></div><div class="gmail_default"><br></div><div class="gmail_default"><br></div></div>