gvsurenderreddy / lodp Goto Github PK

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).