Hacker News Reader

cjdns[1] is an encrypted ipv6 overlay network that uses the firstbits of your public key hash to generate your ip address.

theoretically, multiple keys can share an ip-hash, but the handshake will fail if the intended recipient doesn't have the expected keypair[2]. so far this hasn't been an issue, but you are better off if you know the destination's pubkey beforehand.

[1]: https://github.com/cjdelisle/cjdns

[2]: https://github.com/cjdelisle/cjdns/blob/master/doc/faq/doppl...

Just a half-baked idea: If you don't want to make a new request for every connection, and the recipient owns a huge block of IPv6 addresses, the recipient can create an asynchronous key pair where the public key is used as the IPv6 suffix. The United States Department of Defense owns /13. This provides 115 bits of public key information. The sender can use the IPv6 address as the public key.

115 bits of security is pretty good, for example 3DES, while not exactly a great choice today, is still considered secure and acceptable for use today, with its 112 bits of security. However, I know of no public key encryption scheme that would give acceptable security with only 115 bits of public key. With RSA, you need at least 1024 bits, and probably should rather use 2048. Elliptic curve cryptography is considerably better here, but an ECC key of length n stil gives you only n/2 bits of security, which would be way too little here.

2048 bits of RSA key is the same amount of security as 112 bits of symmentric key, though.

Yes, that’s my point — you need to use 2048 bits for key to get 128 bits of security, so there is no way to fit the public key in the IPv6 address.

Can't you do something with a key-stretching system [0] maybe, to turn 112 bits of IPV6 into 2048 bits of RSA input, though, since you definitely have the right amount of entropy?

0. https://en.wikipedia.org/wiki/Key_stretching

Nit-picking a bit/kind of augmenting your train of thought. You can have non-interactive Diffie-Helman key exchange (via a PKI). As you say, the client would need to know prior to that the public key/have access to the certificate and that would require certainly revamping the DNS approach we now have (even if we did not use DNS, we would still have to deal with DNS requests).

That's literally the second option I describe. What is your point?

Just wanted to clarify that the issue was not with the Diffie-Hellman key exchange itself, but the way we currently do DNS plus IP routing are the issues.

Technically, the client could encrypt their IP with the y=H(g^{scr}) key (result of the DH KE) and send (Enc(y, IP), g^{rc})-- where H is the oracle, g^s server public key, rc <session nonce>*key (or generally 1 time key). The server can then compute the same key (g^{rc}^s and then apply H) and decrypt.

So the second and third paragraph contradict a bit each other, which was the sole reason for my clarification. I am not stating you as wrong or anything; I was just augmenting, so other readers don't get the wrong impression and decouple Diffie-Hellman KE from public key cryptography.

P.S. The remaining issue is to make sure the server does not have to decrypt the IP for invalid connections etc (that is avoid DOS or leaking secrets as we are operating on not trusted ciphertext).

Your tone is unnecessarily harsh.

What you guys are describing is starting to sound more and more like onion routing.

Point is online security is a bad joke. You wrote it, you own it.

The real interesting question is what happens when you get owned by what you didn't write?

> but it leads to all kinds of practical problems, figuring out which is probably best left as an exercise for the reader.

Any examples? I honestly don't see any problems here.

That is a Huuuge number of IP's, at a very high request rate, required for every new connection. It is orders of magnitude greater than DNS, and would be expected to have much lower latency.

Throw onto that the trust issue - such IP certificate repositories are very quickly able to determine who is communicating with each other, and at what time. Whilst this is currently possible anyway, current methods are less centralised, more expensive, and more visible.

You'd have to go full onion

640k is all the memory you'll ever need.

ggm is referring to something more like every router using NAT and having enough room in the packet so they can store something there instead of main memory.