On Friday 16 November 2007 14:49, Michael Rogers wrote: > 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?
Only the constants that can be happily implied: the bits we don't need in regular Freenet connections i.e. the pubkeys. > > > 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. The ARK could be inserted using the node crypto key yes, but I'd really prefer it wasn't, because the pubkey can be read by any node which has the ARK: trivial harvesting of pubkeys, which can be used for some of the above attacks. (Of course they'd have to figure out it was an ARK, but still, it's *bad*). > > > 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. We are using standard protocols. Where we have additional requirements we add additional protocols, possibly piggybacking them. > > > 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. Okay, so how do we do this? We need to authenticate in both directions: the client needs to prove it has the invite, and the server needs to prove it is the server. Neither pubkey should be sent in plaintext. If we use JFK with I's real pubkey and R's temporary pubkey: - If Eve sees the invite, she can decrypt the exchange, and see the pubkeys, but she can't get connected. - If she doesn't see the invite, she's completely clueless. We don't need a challenge/response because encrypting a message with the key is proof enough. Replaying messages doesn't help Mallory since he can't forge the pubkey. We could tighten this up even more by using a temporary pubkey on I's end as well. The real pubkeys are then exchanged in stage 3 and 4. > > 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. Agreed, with one minor change: JFK uses temporary keys on both sides and exchanges the real ones encrypted once Ke is known. Benefit is that Eve cannot see the pubkeys even if she saw the invite. > > Cheers, > Michael
pgpgh9rglSUHJ.pgp
Description: PGP signature
_______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
