tinc/src/Makefile.am

64 lines
1.8 KiB
Makefile
Raw Normal View History

2000-03-26 00:33:07 +00:00
## Produce this file with automake to get Makefile.in
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
2011-07-24 13:44:51 +00:00
sbin_PROGRAMS = tincd tincctl sptps_test
2000-03-26 00:33:07 +00:00
EXTRA_DIST = linux bsd solaris cygwin mingw openssl gcrypt
2002-02-10 21:57:54 +00:00
tincd_SOURCES = \
utils.c getopt.c getopt1.c list.c splay_tree.c dropin.c fake-getaddrinfo.c fake-getnameinfo.c \
buffer.c conf.c connection.c control.c edge.c graph.c logger.c meta.c net.c net_packet.c net_setup.c \
net_socket.c netutl.c node.c process.c protocol.c protocol_auth.c protocol_edge.c protocol_misc.c \
protocol_key.c protocol_subnet.c route.c sptps.c subnet.c subnet_parse.c tincd.c \
dummy_device.c raw_socket_device.c multicast_device.c
if UML
tincd_SOURCES += uml_device.c
endif
if VDE
tincd_SOURCES += vde_device.c
endif
nodist_tincd_SOURCES = \
2011-07-03 21:44:43 +00:00
device.c cipher.c crypto.c ecdh.c ecdsa.c digest.c prf.c rsa.c
2000-03-26 00:33:07 +00:00
tincctl_SOURCES = \
utils.c getopt.c getopt1.c dropin.c \
info.c list.c subnet_parse.c tincctl.c top.c
nodist_tincctl_SOURCES = \
ecdsagen.c rsagen.c
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
2011-07-24 13:44:51 +00:00
sptps_test_SOURCES = \
logger.c cipher.c crypto.c ecdh.c ecdsa.c digest.c prf.c \
sptps.c sptps_test.c utils.c
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
2011-07-24 13:44:51 +00:00
if TUNEMU
tincd_SOURCES += bsd/tunemu.c
endif
tincctl_LDADD = $(CURSES_LIBS)
DEFAULT_INCLUDES =
INCLUDES = @INCLUDES@ -I$(top_builddir)
2000-03-26 00:33:07 +00:00
noinst_HEADERS = \
xalloc.h utils.h getopt.h list.h splay_tree.h dropin.h fake-getaddrinfo.h fake-getnameinfo.h fake-gai-errnos.h ipv6.h ipv4.h ethernet.h \
buffer.h conf.h connection.h control.h control_common.h device.h edge.h graph.h logger.h meta.h net.h netutl.h node.h process.h \
protocol.h route.h subnet.h tincctl.h top.h bsd/tunemu.h
nodist_noinst_HEADERS = \
cipher.h crypto.h ecdh.h ecdsa.h digest.h prf.h rsa.h ecdsagen.h rsagen.h
2000-03-26 00:33:07 +00:00
LIBS = @LIBS@ @LIBGCRYPT_LIBS@
2000-03-26 00:33:07 +00:00
if TUNEMU
LIBS += -lpcap
endif
AM_CFLAGS = -DCONFDIR=\"$(sysconfdir)\" -DLOCALSTATEDIR=\"$(localstatedir)\" -DSBINDIR=\"$(sbindir)\"
2000-12-22 17:15:26 +00:00
dist-hook:
rm -f `find . -type l`