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. 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. By the way, I'm not trying to propose a particular type of obfuscation - step 5 above is only meant to be an example showing that the obfuscation key can be derived from the short refs before the long refs are exchanged. 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. Cheers, Michael [1] http://people.csail.mit.edu/canetti/materials/jfk.pdf
