Matthew Toseland wrote: >> Right, I understand that port scanning is an issue, but it's independent >> from the question of whether we use short or long refs. > > Is it?
Yes. The only difference between short and long refs is this: with long refs, you exchange most of the ID information up front, and a summary of the ID information during JFK. With short refs, you exchange a summary of the ID information up front, and most of the ID information during JFK. The issue of obfuscation is completely separate, because you can generate a suitable obfuscation key from any kind of ref, long or short. That means the issue of port scanning is also separate. > We don't exactly implement JFK, we drop the bits that we don't need. 0_o JFK doesn't exactly strike me as a bloated protocol. In fact it was designed to be the simplest possible protocol that would get the job done securely. What did you leave out? > Right. Obfuscation using a per-message IV and the hash of both the pubkey > hashes, similar to what we do now. Yup, exactly. As I said before, I'm not arguing that the obfuscation method should be changed. The only reason I mentioned it at all was because Nextgens seemed to be saying that obfuscation required long refs, and I wanted to show that you could use short refs instead of long refs to generate the obfuscation key. But once you've generated the key I'm not trying to tell you what to do with it. :-) >> So it's by no means >> secure - it just raises the bar from wholesale filtering/data mining to >> targetted filtering/data mining using a list of intercepted refs. > > Right, but this is possible *now*, with long references. Agreed, short refs make no difference here, just pointing out the possibility of data mining. But I guess we're all paranoid enough to have thought of that already. ;-) > We need to include enough info to fetch the ARK in the short-ref. How? The short ref could be the address, port and ARK key, and the ARK could include the node's pubkey and all other details required to authenticate the connection. Address+port+key comes to something like 70 bytes, which isn't ideal, but still better than what we have now. > We would be using JFK, we'd just add a few bits to it for a > challenge/response > on the one-time shared secret. Homebrew security protocols make me nervous... let's stick to JFK if possible. > If we put the hash of the pubkey > in the invite, then the shared secret is now the hash of the pubkey. I'm suggesting that we don't use a shared secret at all. We generate a single-use keypair, and put the hash of the single-use public key in the invite. The single-use keypair is the responder's ID for the purposes of JFK; the initiator generates its own single-use keypair. The ID_I and ID_R fields contain the peers' long-term identities as well as the single-use public keys. Both parties sign the other party's ID during JFK, making MITM detectable by the initiator. We don't need to add any extra steps to the protocol. > The shared secret is generated from Yarrow in this proposal, and is only used > once. It's a one-time invite. Ah cool, sorry for the misunderstanding. Cheers, Michael _______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
