{ "info": { "author": "Robert Graham", "author_email": "rpgraham84@gmail.com", "bugtrack_url": null, "classifiers": [], "description": "OTPTunnel\n=========\n\nOTPTunnel is privacy software, written in Python, that creates an\nencrypted network tunnel between two hosts. It works by creating a TAP\ninterface; packets read in from the TAP interface are stream XOR'ed\nusing a 'one time pad' as the XOR key and transmitted as udp datagrams\nacross a network.\n\n#Installing\n\n`pip install pynetlinux`\n\n`git clone https://github.com/rpgraham84/otptunnel`\n\n#How To Use\nThe idea is that two users would exchange a very large truly random\nkeyfile before using OTPTunnel. Ideally, one would use a hardware random\nnumber generator based on some natural phenomenon like cosmic noise or\nradioactive decay. However, any file (yes, even a file full of zeros)\ncan be used. The trouble with that of course being that any byte XOR 0\nis the same byte.\n\nThe users then each take the same key to their respective endpoints on\nthe network. For now, there can only be two participants. This will be\nchanged soon so that the server can host multiple keyfiles and\neffectively serve as a router of a VPN. The server can be initiated as\nso:\n\n`./otptunnel -S -K keyfile -A 1.2.3.4`\n\nWhere 1.2.3.4 is the client participant's ip. I know it's weird to have\nto specify this on the server but I will be changing this in the near\nfuture.\n\nThe client would then connect:\n\n`./otptunnel -K keyfile -A 5.6.7.8 --tap-addr 10.8.0.2`\n\nWhere 5.6.7.8 is the server's ip. From this point forward, the two hosts\ncan interact with one another via their TAP interfaces. If either the\nserver or client has any services bound to their TAP IP address, or\n0.0.0.0, they will be visible to the other party via that user's TAP. \n\nFor instance, in many common Linux distros, OpenSSHD by default, binds\nto 0.0.0.0. Therefore, if the server were running sshd bound to 0.0.0.0,\nthe client could connect at 10.8.0.1 (the default server TAP IP) port\n22. \n\n#How It Works\nThe packets will be picked off the TAP at OSI layer 2 and have their\n16-byte md5 sum appended to them. The original packet plus 16-byte\nchecksum are XOR'ed with that participant's keyfile bytes. Basically,\nthe server gets the even bytes, the client gets the odd bytes. Then, a\n6-byte hex string representing the offset is appended to the packet so\nthat the recipient knows where to seek to in the keyfile to begin\ndecoding the packet. Finally, the packet is encapsulated with Ethernet,\nIP, and UDP headers and sent out on the wire over UDP port 12000.\n\n#Note From The Author\n\nPlease feel free to modify this source to your liking and submit a\npull-request! I've tried to maintain good PEP8 formatting throughout the\ncode and comment wherever possible so that anyone can understand it. One\nkey motivation for me in doing this project is to bring cryptography\nback down to an easily digestable and highly customizable system for\nexperimenters, students and hobbyists from\n\n#TODO: (as of 9/13/2013)\n\n##Immediate\n\n* Fix server init code so that a remote ip doesn't have to be specified\n server-side but can be inferred from successfully reading a control\npacket.\n* Give server `OTPTunnel` a `clients` object to track keyfiles and\n offsets for clients that it accepts.\n* Make OTP object aware of the last decode offset used during every\n `OTP.decode()` call. This way, the recipient of a packet can reject\nit if it has a lower offset than the most recent one used.\n* Introduce packet padding. At the beginning of every `OTP.encode()`\n call, the first byte at `OTP._current_encode_seek` is used as a\nrandom number 0-255 that will be the number of random bytes of padding\nprepended to the packet. The prepended bytes are taken from /dev/urandom\nso as to not waste keyfile. This is to defend against plaintext\ncorrelation based on every encrypted packet being predictably longer\nthan it's plaintext counterpart.\n* Introduce a \"burning mode\" which will write a pseudo-random byte\n (different bytes for each user) for every read into the keyfile. This\nway, even if the users attempt to use the same keyfile again, it wont\nwork. Packets will we dropped because the client and server will have\ndifferent bytes in their keyfiles where they've already used that\nportion of the key.\n* Introduce a configurable keybyte_zero counter that allows for a\n certain number of zeros to be allowed in a row from the keyfile. For\ninstance, one might set the max_keybyte_zero counter at 3, and then no\nmore than 3 zeroes would ever be pulled from the keyfile in immediate\nsuccession to help prevent leakage. During the `encode()` or `decode()`\ncall, if the last 3 keybytes were zero, otptunnel will loop over the\nkeyfile bytes (at regular stepping), until a non-zero byte is found and\nthat will be the keybyte used in the XOR. \n* Design a config file. Make OTPTunnel read this file instead of having\n to specify a million flags.\n* Offer users an ability to track and save session state in a state\n file.\n* Implement option to manually specify initial encoding seek offset\n value.\n* Introduce multiple clients per server.\n* Make server act as router, hand out IP addresses for VPN clients.\n* Introduce \"control packets\" as mechanism for servers and clients to\n exchange messages regarding establishing a new client connection to\nthe server and for the server to hand out a TAP IP address to clients.\nControl packets always have an outermost offset of 0xFFFFFFFFFFFF -- the\nhighest offset allowed in 6 bytes, the next 6 bytes are the actual\noffset into some (perhaps unknown) keyfile. \n* Make server use a directory of keys instead of a single keyfile. When\n a new packet comes in, if it is a control packet, the server tries to\ndecrypt the packet from the starting offset of every key in it's keyfile\ndirectory. \n* Make web interface for monitoring state information, modifying\n configuration, adding new keys, etc.\n* Make OTPTunnel pip installable. Make debian-style init script for\n launching otptunnel as daemon.", "description_content_type": null, "docs_url": null, "download_url": "UNKNOWN", "downloads": { "last_day": -1, "last_month": -1, "last_week": -1 }, "home_page": "UNKNOWN", "keywords": null, "license": "LICENSE", "maintainer": null, "maintainer_email": null, "name": "OTPTunnel", "package_url": "https://pypi.org/project/OTPTunnel/", "platform": "UNKNOWN", "project_url": "https://pypi.org/project/OTPTunnel/", "project_urls": { "Download": "UNKNOWN", "Homepage": "UNKNOWN" }, "release_url": "https://pypi.org/project/OTPTunnel/0.1.0/", "requires_dist": null, "requires_python": null, "summary": "Create an encrypted tunnel interface using a one-time pad.", "version": "0.1.0" }, "last_serial": 1222400, "releases": { "0.1.0": [ { "comment_text": "", "digests": { "md5": "71ace24da98ea17aad6683846851312c", "sha256": "59e44290338ab4e8b87ffbd8a7dc336d244e07c912a3b325e596c74c61e747b3" }, "downloads": -1, "filename": "OTPTunnel-0.1.0.tar.gz", "has_sig": false, "md5_digest": "71ace24da98ea17aad6683846851312c", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 8540, "upload_time": "2014-09-12T20:52:21", "url": "https://files.pythonhosted.org/packages/42/17/a455e9cc07528fa5b69c49b48c7ef0e76d144d5d0496634a39744fa35819/OTPTunnel-0.1.0.tar.gz" } ] }, "urls": [ { "comment_text": "", "digests": { "md5": "71ace24da98ea17aad6683846851312c", "sha256": "59e44290338ab4e8b87ffbd8a7dc336d244e07c912a3b325e596c74c61e747b3" }, "downloads": -1, "filename": "OTPTunnel-0.1.0.tar.gz", "has_sig": false, "md5_digest": "71ace24da98ea17aad6683846851312c", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 8540, "upload_time": "2014-09-12T20:52:21", "url": "https://files.pythonhosted.org/packages/42/17/a455e9cc07528fa5b69c49b48c7ef0e76d144d5d0496634a39744fa35819/OTPTunnel-0.1.0.tar.gz" } ] }