Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Lightweight Obfuscated Datagram Protocol
Fetching latest commit…
Cannot retrieve the latest commit at this time.
|Failed to load latest commit information.|
Lightweight Obfuscated Datagram Protocol (LODP) Yawning Angel <yawning at schwanenlied dot me> "much key, so encrypt, such secure, wow" This is the reference implementation of LODP, a fingerprinting active scanning resistant unreliable datagram protocol, similar to Dust and SSU. It currently has the following external dependencies: * Compile time only * CMake * Doxygen (To generate the documentation) * libottery (https://github.com/nmathewson/libottery) * libuv (https://github.com/joyent/libuv) * Google Protocol Buffers (https://code.google.com/p/protobuf/) It currently incorporates code from the following 3rd parties: * Various flavors of "Public Domain"/CC-0 * Floodyberry's curve25519-donna.c (https://github.com/floodyberry/curve25519-donna) * Floodyberry's SipHash-2-4 implementation (https://github.com/floodyberry/siphash) * Floodyberry's (X)ChaCha implementation (https://github.com/floodyberry/chacha-opt) * BLAKE2 reference implementation (https://github.com/BLAKE2/BLAKE2) * 3 Clause BSD license * Google Protocol Buffers (https://code.google.com/p/protobuf/) * Google C++ Testing Framework (Unit tests only) (https://code.google.com/p/googletest/) Please see the COPYING file for information on licensing. The test suite gets built as lodpxx_test. It's half heartedly integreated into CMake's test functionality in that "make test" will run the suite but to see individual test results running the binary manually is required. Implementation notes: * Build related: * Your C compiler must support C99. * Your C++ compiler must support a reasonable amount of C++11 (GCC 4.7.2 or later). * No testing was done on Windows. Eventually the project will support mingw but it is unlikely that it will ever support Visual Studio. * By default x86-64 crypto is being built. The resulting library will not work on 32 bit systems unless this is changed. * Library related: * The library is neither thread nor fork safe. * The library is written under the assumption that Exceptions and RTTI are disabled. The behavior expected when an exception is thrown is that the program will abort() (g++'s -fno-exceptions will use this behavior). * The library was designed under the assumption that a event driven non-blocking I/O library is used to provide the actual networking bits. Utterly horrific things will happen if the socket calls used are blocking. * C++ is primarily used as "a better C", so do not expect the code to be very C++ like internally. * Components under src/schwanenlied that aren't part of the lodp namespace are written with the idea that they will be useful for other projects. Yay. TODO: * Update the spec for the brave new Protocol Buffers world. * Use git submodules for the ext directory. * C wrappers for liblodpxx would be nice. * Clean up the build system. * Write more unit tests. * The code hits up the heap more than I'd like. Not sure if trying to reduce this further really buys anything, and with the current design it's possible to ensure that sensitive data is allocated from a mlock()ed region in the future if so desired. * (MAYBE) Make the library thread safe. Single core performance on any modern system should be quite fast, and most event driven network libraries assume a single thread per event loop anyway. As long as Endpoints (and it's associated Sessions) don't cross thread boundaries, the library will work as is. * (MAYBE) Change crypto::Random to an abstract class so that people can plug in a different concrete implementation of a CSPRNG (Eg: OpenSSL). Not much to be gained from this since libottery is easier to manage as a dependency than OpenSSL is. * (UNLIKELY) Reconsider the stance on exceptions, though the only exception the code will ever generate is std::bad_alloc, which is irrecoverably fatal anyway. The irony of the fact that I'm using C++11 features and refusing to use exceptions is not lost on me. This wouldn't be hard since the code is exception safe to begin with, but I don't see what the potential gain is. * (UNLIKELY) Change inet_ntop() to getaddrinfo() to allow this to work on Windows XP. Windows XP will be EOL by the time this actually gets deployed. I could just use uv_ipv[4,6]_name() now that libuv is a dependency. * (UNLIKELY) Reconsider my stance on abort()ing when the user screws up massively. The magnitude of the error that the application code needs to make to actually trigger any of the assertions is rather large (Eg: Yanking out an endpoint from underneath a bunch of sessions), so I view this behavior as a debugging aid more than anything else. * (UNLIKELY) Reconsider the use of C++11 features. If functionality is broken with a sufficiently recent GCC release, I'll change the code (Note: Debian squeeze ships with gcc 4.4.5 which was released on October 1, 2010. That is not anything even vaguely resembling "sufficiently recent"). * GCC prior to 4.6.1 may puke on std::unique_ptr in associative containers. (GCC bug #44436). * GCC prior to 4.7.2 does not fully support std::chrono::steady_clock (And certain versions may need --enable-libstdcxx-time). * (NEVER) Support Visual Studio as a build environment. * God knows what their C++11 support is like (I know that steady_clock is broken at a minimum).