3 ms·

If the source IP is encrypted, the recipient needs to decrypt it first in order to be able to send a response. To decrypt it, it needs to either have some share

by xyzzyz 8y ago

If the source IP is encrypted, the recipient needs to decrypt it first in order to be able to send a response. To decrypt it, it needs to either have some shared secret with the sender, or the sender needs to use the recipient's private key. The parties cannot obtain the shared secret the usual way, the Diffie-Helman exchange. It cannot be performed, because it requires back-and-forth communication, which we are trying to establish in the first place. Of course, we'd still need to use certificates signed by public authorities to deal with the standard MitM concerns. The alternative would be for the sender to use the recipient's public key to encrypt the source IP address. That would require a DNS-like system that would store and serve public keys corresponding to a given IP address you are trying to communicate with. This is something doable, especially in IPv6 world where you don't really have to reuse IPv6 addresses, but it leads to all kinds of practical problems, figuring out which is probably best left as an exercise for the reader.

eftychis 8y ago
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).
- xyzzyz 8y ago
  That's literally the second option I describe. What is your point?
  - schrodinger 8y ago
    Your tone is unnecessarily harsh.
  - therein 8y ago
    What you guys are describing is starting to sound more and more like onion routing.
    - User23 8y ago
      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?
  - eftychis 8y ago
    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).
thomastjeffery 8y ago
> 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.
- Normal_gaussian 8y ago
  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
  - User23 8y ago
    640k is all the memory you'll ever need.
geocar 8y ago
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.
eboyjr 8y ago
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.
- xyzzyz 8y ago
  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.
  - grkvlt 8y ago
    2048 bits of RSA key is the same amount of security as 112 bits of symmentric key, though.
    - xyzzyz 8y ago
      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.
      - grkvlt 8y ago
        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 https://en.wikipedia.org/wiki/Key_stretching
xj9 8y ago
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 https://github.com/cjdelisle/cjdns [2]: https://github.com/cjdelisle/cjdns/blob/master/doc/faq/doppleganger.md https://github.com/cjdelisle/cjdns/blob/master/doc/faq/doppl...

by xyzzyz 8y ago

eftychis 8y ago

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

xyzzyz 8y ago
That's literally the second option I describe. What is your point?
- schrodinger 8y ago
  Your tone is unnecessarily harsh.
- therein 8y ago
  What you guys are describing is starting to sound more and more like onion routing.
  - User23 8y ago
    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?
- eftychis 8y ago
  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).

thomastjeffery 8y ago

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

Normal_gaussian 8y ago
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
- User23 8y ago
  640k is all the memory you'll ever need.

geocar 8y ago

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.

eboyjr 8y ago

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.

xyzzyz 8y ago
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.
- grkvlt 8y ago
  2048 bits of RSA key is the same amount of security as 112 bits of symmentric key, though.
  - xyzzyz 8y ago
    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.
    - grkvlt 8y ago
      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 https://en.wikipedia.org/wiki/Key_stretching

xj9 8y ago

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 https://github.com/cjdelisle/cjdns [2]: https://github.com/cjdelisle/cjdns/blob/master/doc/faq/doppleganger.md https://github.com/cjdelisle/cjdns/blob/master/doc/faq/doppl...