lupine/hide-eid
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Another night's work - move to ECDH + AES256 from RSA pubkey

Browse Source
This commit is contained in:
Nick Thomas
2013-08-08 00:48:02 +01:00
parent c77557b6ee
commit 118b7b8125
10 changed files with 364 additions and 148 deletions
Download Patch File Download Diff File Expand all files Collapse all files

92
README.md
View File

@@ -6,7 +6,6 @@ participants in the Internet.
Overview
--------
As the Location/Identity Separation Protocol people have noted, IPv4 and IPv6
both use IP addresses (Endpoint IDs, in the lingo) to make routing decisions.
Focusing on this from the point of view of routing table efficiency / features,
@@ -60,6 +59,7 @@ the scheme over onion routing, such as tor; no significant latency is added.
When received by the destination ISP, it can use its private key to decrypt the
encapsulated packet, and send that decrypted packet on to its final hop.
Usage
-----
Pass 1 now exists, in a rudimentary form. Here's how to put together a couple of
@@ -76,12 +76,12 @@ maintained by this project - they can even be RFC1918 space, as long as there
are no overlaps within this registry. Remember, EIDs aren't used to make routing
decisions across the Internet..
Generate some RSA private keys, and their public components, in PEM format:
Generate some ECC private keys, and their public components, in PEM format:
$ openssl genrsa -out rloc1.private.pem 4096
$ openssl rsa -in rloc1.private.pem -pubout -out rloc1.public.pem
$ openssl genrsa -out rloc2.private.pem 4096
$ openssl rsa -in rloc2.private.pem -pubout -out rloc2.public.pem
$ openssl ecparam -genkey -out rloc1.private.pem -name secp160r2
$ openssl ec -in rloc1.private.pem -pubout -out rloc1.public.pem
$ openssl ecparam -genkey -out rloc2.private.pem -name secp160r2
$ openssl ec -in rloc2.private.pem -pubout -out rloc2.public.pem
Add entries to the rloc-registry.json file to reflect your mappings. You need to
put an entry (a JSON object) to the "eid_rloc_map" array, like this:
@@ -124,8 +124,58 @@ vice-versa, and get an ICMP echo reply back. You can also run TCP or UDP
servers on one of the IPs, and connect to them from the other IP. If you run
wireshark or tcpdump on an intermediate machine (or just one of the hosts, if
you focus on the egress/ingress traffic) you'll see obscure IP packets with
just the RLOC addresses as source and destination, with no visible UDP/TCP
headers.
just the RLOC addresses as source and destination, and no visible UDP/TCP
headers. IP Protocol is set to 99 - "any private encryption scheme".
Encryption
----------
Encryption scheme is really the only novel portion of this project; the rest is
covered in the L/ISP RFCs. This code is all about slapping together a basic
L/ISP router (badly), and implementing cryptography for the encapsulated IP
packets, for the sake of experimenting. Crypto is hard, and experimentation is
key (ha ha).
Current scheme:
~~~~~~~~~~~~~~~
This seems less stupid.
* EC public keys in central repository
* Each participant knows only their private key
* Generate ECDH secret for each peer using their public + your private key
* pseudo-random 128-bit IV per-packet, put at the start of encrypted data
* Use as256 symmetric encryption with sha256( ecdh ) to encrypt / decrypt
Main point is that routers don't need to communicate with each other to
negotiate a shared key - they can independently derive the same asymmetric key
as long as they share some common assumptions, have their own private key, and
the peer's public key.
Asymmetric key size is smaller, and we're moving to a symmetric cipher for the
actual packet encryption, so hopefully this will be much faster than scheme 0.
Which curve should we be using? No clue. What size of key should we be using?
No clue. Is this kind of shared key appropriate when we're passing considerable
traffic? No clue.
Scheme 0:
~~~~~~~~~
This was stupid.
* RSA public keys in central repository
* Just use public key to directly encrypt packet data
* Use private key to decrypt packets addressed to you.
This is slow, and you can only encrypt data that's smaller than the key modulus,
or something like that.
First result: rtt increased from 37ms to 80ms.
For access<->hosting, that kind of latency increase is bad, but bearable. For
hosting<->hosting, it's completely unacceptable.
Not all of it may be crypto-related - worth implementing a no-op branch that
just encapsulates, and checking the difference.
Limitations
@@ -136,30 +186,18 @@ Certainly for access ISPs, even with the best will in the world, the
infrastructure between them and their layer 1/2 service providers may be bugged.
This is not protected against by this scheme; if you suspect this is happening
to your ISP without their knowledge, you can run IPSec over the link and allow
them to terminate it just before the box that wraps the packets. If you suspect
it is happening with their knowledge, the best you can do is change ISP. If we
run out of good ISPs, this scheme adds nothing.
them to terminate it just before (or on) the box that wraps the packets. If you
suspect it is happening with their knowledge, the best you can do is change ISP.
If we run out of good ISPs, this scheme adds nothing. You can always start a VPN
ISP.
If the other side of the link is complicit, this scheme does nothing. It isn't
going to stop Facebook from handing all their records of your accesses to them
over to the NSA. Stop using Facebook.
Public-key encryption is relatively slow compard to block ciphers; making this
scale is going to be a challenge. Hopefully not impossible - but if it's too
expensive, uptake will be low or zero. If it's too unreliable, uptake will be
low or zero.
First result: rtt increased from 37ms to 80ms. There are four cryptographic
operations in each trip - encrypt outgoing packet, decrypt outgoing packet,
encrypt return packet, decrypt return packet. This is on a laptop and VM with
no hardware crypto support of any kind, of course. but it's also with nothing
else to do at all.
For access<->hosting, that kind of latency increase is bad, but bearable. For
hosting<->hosting, it's completely unacceptable.
Not all of it may be crypto-related - worth implementing a no-op branch that
just encapsulates, and checking the difference.
There are four cryptographic operations in each trip - encrypt outgoing packet,
decrypt outgoing packet, encrypt return packet, decrypt return packet. This is
going to be slower than no crypto. Too slow?
May break ICMP and other responses from intermediate ISPs. Path MTU discovery
breaks, for instance, with a naive implementation of this scheme, as does