Metadata-Version: 1.0
Name: OTPTunnel
Version: 0.1.0
Summary: Create an encrypted tunnel interface using a one-time pad.
Home-page: UNKNOWN
Author: Robert Graham
Author-email: rpgraham84@gmail.com
License: LICENSE
Description: OTPTunnel
        =========
        
        OTPTunnel is privacy software, written in Python, that creates an
        encrypted network tunnel between two hosts. It works by creating a TAP
        interface; packets read in from the TAP interface are stream XOR'ed
        using a 'one time pad' as the XOR key and transmitted as udp datagrams
        across a network.
        
        #Installing
        
        `pip install pynetlinux`
        
        `git clone https://github.com/rpgraham84/otptunnel`
        
        #How To Use
        The idea is that two users would exchange a very large truly random
        keyfile before using OTPTunnel. Ideally, one would use a hardware random
        number generator based on some natural phenomenon like cosmic noise or
        radioactive decay. However, any file (yes, even a file full of zeros)
        can be used. The trouble with that of course being that any byte XOR 0
        is the same byte.
        
        The users then each take the same key to their respective endpoints on
        the network. For now, there can only be two participants. This will be
        changed soon so that the server can host multiple keyfiles and
        effectively serve as a router of a VPN. The server can be initiated as
        so:
        
        `./otptunnel -S -K keyfile -A 1.2.3.4`
        
        Where 1.2.3.4 is the client participant's ip. I know it's weird to have
        to specify this on the server but I will be changing this in the near
        future.
        
        The client would then connect:
        
        `./otptunnel -K keyfile -A 5.6.7.8 --tap-addr 10.8.0.2`
        
        Where 5.6.7.8 is the server's ip. From this point forward, the two hosts
        can interact with one another via their TAP interfaces. If either the
        server or client has any services bound to their TAP IP address, or
        0.0.0.0, they will be visible to the other party via that user's TAP. 
        
        For instance, in many common Linux distros, OpenSSHD by default, binds
        to 0.0.0.0. Therefore, if the server were running sshd bound to 0.0.0.0,
        the client could connect at 10.8.0.1 (the default server TAP IP) port
        22. 
        
        #How It Works
        The packets will be picked off the TAP at OSI layer 2 and have their
        16-byte md5 sum appended to them. The original packet plus 16-byte
        checksum are XOR'ed with that participant's keyfile bytes. Basically,
        the server gets the even bytes, the client gets the odd bytes. Then, a
        6-byte hex string representing the offset is appended to the packet so
        that the recipient knows where to seek to in the keyfile to begin
        decoding the packet. Finally, the packet is encapsulated with Ethernet,
        IP, and UDP headers and sent out on the wire over UDP port 12000.
        
        #Note From The Author
        
        Please feel free to modify this source to your liking and submit a
        pull-request! I've tried to maintain good PEP8 formatting throughout the
        code and comment wherever possible so that anyone can understand it. One
        key motivation for me in doing this project is to bring cryptography
        back down to an easily digestable and highly customizable system for
        experimenters, students and hobbyists from
        
        #TODO: (as of 9/13/2013)
        
        ##Immediate
        
        *  Fix server init code so that a remote ip doesn't have to be specified
           server-side but can be inferred from successfully reading a control
        packet.
        *  Give server `OTPTunnel` a `clients` object to track keyfiles and
           offsets for clients that it accepts.
        *  Make OTP object aware of the last decode offset used during every
           `OTP.decode()` call. This way, the recipient of a packet can reject
        it if it has a lower offset than the most recent one used.
        *  Introduce packet padding. At the beginning of every `OTP.encode()`
           call, the first byte at `OTP._current_encode_seek` is used as a
        random number 0-255 that will be the number of random bytes of padding
        prepended to the packet. The prepended bytes are taken from /dev/urandom
        so as to not waste keyfile. This is to defend against plaintext
        correlation based on every encrypted packet being predictably longer
        than it's plaintext counterpart.
        *  Introduce a "burning mode" which will write a pseudo-random byte
           (different bytes for each user) for every read into the keyfile. This
        way, even if the users attempt to use the same keyfile again, it wont
        work. Packets will we dropped because the client and server will have
        different bytes in their keyfiles where they've already used that
        portion of the key.
        * Introduce a configurable keybyte_zero counter that allows for a
          certain number of zeros to be allowed in a row from the keyfile. For
        instance, one might set the max_keybyte_zero counter at 3, and then no
        more than 3 zeroes would ever be pulled from the keyfile in immediate
        succession to help prevent leakage. During the `encode()` or `decode()`
        call, if the last 3 keybytes were zero, otptunnel will loop over the
        keyfile bytes (at regular stepping), until a non-zero byte is found and
        that will be the keybyte used in the XOR. 
        *  Design a config file. Make OTPTunnel read this file instead of having
           to specify a million flags.
        *  Offer users an ability to track and save session state in a state
           file.
        * Implement option to manually specify initial encoding seek offset
          value.
        * Introduce multiple clients per server.
        * Make server act as router, hand out IP addresses for VPN clients.
        * Introduce "control packets" as mechanism for servers and clients to
          exchange messages regarding establishing a new client connection to
        the server and for the server to hand out a TAP IP address to clients.
        Control packets always have an outermost offset of 0xFFFFFFFFFFFF -- the
        highest offset allowed in 6 bytes, the next 6 bytes are the actual
        offset into some (perhaps unknown) keyfile. 
        * Make server use a directory of keys instead of a single keyfile. When
          a new packet comes in, if it is a control packet, the server tries to
        decrypt the packet from the starting offset of every key in it's keyfile
        directory. 
        * Make web interface for monitoring state information, modifying
          configuration, adding new keys, etc.
        * Make OTPTunnel pip installable. Make debian-style init script for
          launching otptunnel as daemon.
        
Platform: UNKNOWN
