The Seif Handshake
The World Wide Web does an adequate job of document retrieval, but it 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 that acts as the party's globally unique identifier, and a closely held Private Key that is shared with no one. Information that is encrypted with the Public Key can only be decrypted with the corresponding Private Key. 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 (alice_public_key, alice_private_key). She also has Bob's Public Key (bob_public_key) and Bob's network address. Bob has his own key pair (bob_public_key, bob_private_key). Bob might have alice_public_key if they have a pre-existing relationship, but Bob might not know that Alice is about to connect.
Alice's Message
Alice generates a random handshake_key.
Alice's first message is sent in the clear, but it contains some encrypted components. It is sent to Bob's network address.
{
"seif": 1,
"handshake": encrypt_pk(bob_public_key, handshake_key),
"payload": encrypt(handshake_key, alice_public_key)
}
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 handshake_key encrypted with bob_public_key. Only Bob can recover the handshake_key.
The payload contains alice_public_key encrypted with the handshake_key. This allows Bob to know who is attempting to connect. Encrypting alice_public_key provides a little bit of privacy, but traffic analysis could probably determine who Alice is, even without obtaining the use of handshake_key.
Alice's message could contain other information encrypted with handshake_key, such as a referral code or a request or routing information.
Bob's Message
Bob received Alice's message. Bob generates a random session_key that will be used as a symmetric session encryption key for future messages.
Bob's first message is encrypted with Alice's handshake_key.
encrypt(handshake_key, {"session": encrypt_pk(alice_public_key, session_key)})
Bob's message contains session_key encrypted with alice_public_key. All subsequent messages sent by Alice and Bob will be encrypted by session_key.
Bob's message could contain other information.
Alice has handshake_key so she can decrypt the message, and she has alice_private_key so she can decrypt session_key.
Bob can send session_key-encrypted messages immediately. Bob does not have to wait for Alice to send a second message.
Properties
The Seif Handshake has some nice properties:
Given an underlying network 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.
Discussion
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_public_key. Netscape chose to have Bob provide bob_public_key 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.