[Cryptography] Some recent work

Phillip Hallam-Baker phill at hallambaker.com
Sun Oct 8 22:14:29 EDT 2017


I thought people might be interested in two pieces of recent work.

http://prismproof.org/Documents/draft-hallambaker-jbcd-container.html
http://www.prismproof.org/Documents/draft-hallambaker-json-key-exchange.html

The first is a cryptographic container format that provides a combination of

* Zip file finctionality
* Blockchain with Merkle tree functionality
* Append only atomic log
* Efficient random access with zero initialization overhead.
* PKCS#7/CMS

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.

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.


The second is a new key exchange that uses public key composition as the
primitive.

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?

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.

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.

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.

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).


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.

If people look at the full prismproof.org 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20171008/c69225c4/attachment.html>


More information about the cryptography mailing list