Douglas Crockford
PayPal
2016-09-01
The World Wide Web does an adequate job of document retrieval, but is has deficiencies when viewed as an application delivery system, being cursed with weaknesses in functionality and security. The Seif Project intends to remedy that.
The Seif Protocol is a message delivery system using secure JSON over TCP/IP. The Seif Handshake is the part of the protocol that establishes a secure session between two parties.
The Seif System assumes that every party has a pair of keys, a Public Key (P) that acts as the party's globally unique identifier, and a closely held Private Key (R) that is shared with no one. Information that is encrypted with the Public Key (P) can only be decrypted with the corresponding Private Key (R). It is by the act of decryption that a party can prove that they are the holder of the Public Key.
Alice wants to connect with Bob. Before the session begins Alice has her key pair (PA, RA). She also has Bob's Public Key (PB) and Bob's IP address. Bob has his own key pair (PB, RB). Bob might have Alice's Public Key (PA) if they have a pre-existing relationship, but Bob may not know that Alice is about to connect.
Alice generates a random H, a symmetric encryption key.
Alice's first message is sent in the clear.
{"seif": 1,PB(H),H(PA)}
The seif property indicates that this is a Seif Protocol handshake. The 1 indicates the version number of the Seif Protocol. This allows us to adapt the protocol over time. For example, if the cryptographic system proves to be too weak, the seif version can be advanced to a stronger system.
The message contains Alice's random H, encrypted with Bob's Public Key (PB) . Only Bob can recover Alice's H.
The message contains Alice's Public Key (PA) encrypted with Alice's H. This allows Bob to know who is attempting to connect. Encrypting Alice's Public Key (PA) provides a little bit of privacy, but traffic analysis could probably determine who Alice is, even without obtaining the use of H.
Alice's message could contain other information encrypted with H, such as a referral code or a request.
Bob received Alice's message. Bob generates a random S that will be used as a symmetric session encryption key for future messages.
Bob's first message is encrypted with Alice's H.
H({PA(S)})
Bob's message contains S encrypted with Alice's Public Key (PA). All subsequent messages sent by Alice and Bob will be encrypted by S.
Bob's message could contain other information.
Alice has H so she can decrypt the message, and she has her Private Key (RA) so she can decrypt the session key S .
Bob can send S-encrypted messages immediately. Bob does not have to wait for Alice to send a second message.
The Seif Handshake has some nice properties:
Given an underlying TCP connection, a secure session is set up with one round trip.
A man-in-the-middle requires knowledge of both Private Keys.
Forward secrecy for the session is retained as long as either Private Key is kept private.
Alice and Bob have both proven that they hold their Private Keys. For many applications no additional authentication is required.
The Seif Handshake does some obvious things with Public Key Cryptography. So why haven't we seen this before?
Public Keys are an excellent alternative to user names and passwords. While it is well understood that passwords work poorly for humans at scale, there has been a strong reluctance to consider better alternatives.
The World Wide Web has been remarkably influential. There are patterns of thought that are enforced by the Web. After a few decades, non-web thinking has become very difficult. For example, there is the problem of how Alice acquires Bob's Public Key (PB). Netscape chose to have Bob provide Bob's Public Key (PB) in response to Alice's attempt to connect, along with certification that Alice should trust this highly dubious process. This might have made sense in 1995, but today we have much better options for distribution of Public Keys. The old constraints are hard to give up, so it is difficult for many security practitioners to imagine a secure system that does not rely on PKI certificate authorities, despite the experience that certificate authorities are not reliable.
In 1995 Public Key operations were computationally prohibitively expensive. Yahoo did not start using SSL at scale until 2006 because it could not afford the computation. So something like the Seif Handshake that requires two Public Key operations seems unimaginable. But three fundamental things have changed since then. Moore's Law has continued to reduce the cost of cryptography, and we now have Elliptic Curve Cryptography, which offers cryptographic strength at a significantly lower cost, and we have specialized hardware. In today's technology, it is now feasible for all devices to do two Public Key operations on setting up a session. The cost of computation is more than compensated for by the elimination of network round trips.