]> git.meshlink.io Git - meshlink/commit
Start of "Simple Peer-To-Peer Security" protocol.
authorGuus Sliepen <guus@tinc-vpn.org>
Sun, 24 Jul 2011 13:44:51 +0000 (15:44 +0200)
committerGuus Sliepen <guus@tinc-vpn.org>
Sun, 24 Jul 2011 13:44:51 +0000 (15:44 +0200)
commit3d75dbc0880484ff6d2f689a9b981def3cd75b5e
tree791c75d90dc9b95b4ef47d3fc56b1e50a3798f8a
parentff751903aa82bd6dd66a099f9c05dcdae9fc57f2
Start of "Simple Peer-To-Peer Security" protocol.

Encryption and authentication of the meta connection is spread out over
meta.c and protocol_auth.c. The new protocol was added there as well,
leading to spaghetti code. To improve things, the new protocol will now
be implemented in sptps.[ch].

The goal is to have a very simplified version of TLS. There is a record
layer, and there are only two record types: application data and
handshake messages. The handshake message contains a random nonce, an
ephemeral ECDH public key, and an ECDSA signature over the former. After
the ECDH public keys are exchanged, a shared secret is calculated, and a
TLS style PRF is used to generate the key material for the cipher and
HMAC algorithm, and further communication is encrypted and authenticated.

A lot of the simplicity comes from the fact that both sides must have
each other's public keys in advance, and there are no options to choose.
There will be one fixed cipher suite, and both peers always authenticate
each other. (Inspiration taken from Ian Grigg's hypotheses[0].)
There might be some compromise in the future, to enable or disable
encryption, authentication and compression, but there will be no choice
of algorithms. This will allow SPTPS to be built with a few embedded
crypto algorithms instead of linking with huge crypto libraries.

The API is also kept simple. There is a start and a stop function. All
data necessary to make the connection work is passed in the start
function. Instead having both send- and receive-record functions, there
is a send-record function and a receive-data function. The latter will
pass protocol data received from the peer to the SPTPS implementation,
which will in turn call a receive-record callback function when
necessary. This hides all the handshaking from the application, and is
completely independent from any event loop or socket characteristics.

[0] http://iang.org/ssl/hn_hypotheses_in_secure_protocol_design.html
src/Makefile.am
src/openssl/cipher.c
src/openssl/digest.c
src/openssl/digest.h
src/openssl/prf.c
src/openssl/prf.h
src/sptps.c [new file with mode: 0644]
src/sptps.h [new file with mode: 0644]
src/sptps_test.c [new file with mode: 0644]