On Wednesday 14 November 2007 19:05, Michael Rogers wrote: > Matthew Toseland wrote: > >> OK, here's my suggestion: > >> > >> 1. Remove the address and port from the current ref > >> 2. Call what remains (crypto parameters, public key etc) the "long ref" > >> 3. The address, port, and the hash of the long ref form the "short ref" > >> 4. The short refs (38 bytes) are exchanged out of band > >> 5. Obfuscation key = hash (A's short ref, B's short ref, nonce) > >> 6. The long refs are exchanged during obfuscated JFK (in the ID_I and > >> ID_R fields of messages 3 and 4) > >> 7. Before completing JFK, the long refs are verified by hashing them and > >> comparing the hashes contained in the short refs > > > > Is it port-scan resistant? How exactly would phase 0 work? > > In terms of port scanning, it doesn't make any difference whether the > users exchange short or long refs. The CPU burden remains on the initiator.
No. If they get any sort of response at all, they can deduce that there is a high probability of its being a node. > > The paper I've looked at [1] doesn't mention phase 0 - does that refer > to pre-computing/reusing the DH exponents? If so, it wouldn't be > affected by the use of short refs. The only change to JFKi would occur > at the end of the protocol, where the IDs are verified. I meant phase 1, sorry. So what we have here then is we prepend the nonce to the phase 0 packet, and another nonce to the beginning of the phase 1 packet. The rest of the exchange is then encrypted with H ( nonce + A's pk hash + B's pk hash ). Okay, that's reasonable. Any downsides? - If the attacker knows, or can guess, *BOTH* A and B's pk hashes, he can decrypt the exchange and prove that one is occurring. So if you get busted and promise not to run a node again, and then do, you could be in trouble if you don't change the pubkey. Not a very realistic scenario - if they care that much they'll do traffic flow analysis. So all in all, this looks like a good idea. One advantage of long refs is they are big enough to include the ARK, so if you're already on the network, you can connect later on. Short refs must be exchanged in real time, while both sides' IPs are valid (or one side if only one side NATed). How does this compare to one-time invites? We should have both mechanisms, yes? An invite would be almost the same as a short ref, except that the hash would be a one-time shared secret allowing you to connect once to a (port forwarded) node. The advantage is you only need to pass them in one direction, and they can therefore be used comfortably "offline", provided you have a stable IP and a port forward. The disadvantage is they are more vulnerable to out-of-band MITM. So something like: A -> B: H(secret), g^x B -> A: challenge, g^y A -> B: E(H(secret + challenge), ...) ... Once we have port forward detection we can put a button in for this. Comments? > As Nextgens pointed out, obfuscation doesn't give us any real security, > it just raises the bar for the attacker or data miner. We still depend > on the out-of-band ref exchange being secure - but IMHO that will be > easier if the refs are short. Well sure, if the out of band ref exchange is busted we are visible, there's nothing we can do about that as Eve will know the IP's involved. > > Cheers, > Michael > > [1] http://people.csail.mit.edu/canetti/materials/jfk.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20071115/87fcf4db/attachment.pgp>
