On Thursday 15 November 2007 23:21, Michael Rogers wrote: > Matthew Toseland wrote: > >> 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. > > 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? > > Message 1 of JFKi includes a field called ID_R', "an indication by the > initiator to the responder as to what authentication information (e.g., > certificates) the latter should use." In other words, the initiator has > to show that it knows the responder's identity. If someone scans the > port and puts the wrong value in ID_R', the responder is free to ignore > the message. We don't exactly implement JFK, we drop the bits that we don't need. > > Obfuscation raises the bar a bit further: the port scanner has to know > the identities of both peers to get a response, because otherwise the > message won't decrypt properly and ID_R' will be wrong. Right. Obfuscation using a per-message IV and the hash of both the pubkey hashes, similar to what we do now. > > > 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 ). > > I don't see the need for two nonces - the initiator just prepends a > nonce to message 1 (using the terminology from section 2.2 of the JFK > paper). The responder tries decrypting the packet with the hash of each > of its disconnected peers; if the decryption succeeds (i.e. the ID_R' > field has the right value) then it responds with message 2. Too complex, just use a random IV on each packet, and the wrapper key be the XOR of the two hashes, as it is now. > > > - 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. > > Right, and this can be done live or after the fact: if Mallory has a > list of intercepted refs and a huge database of, say, AT&T backbone > traffic, she can take the first packet in every encrypted flow, assume > it starts with a nonce, and try to decrypt the rest of the packet with > hash (nonce, ref_1, ref_2) for every pair of refs. 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. > > But obfuscation is cheap, so IMO it's worth raising the bar. Indeed, and if at least one side is true darknet, Mallory will not know it and therefore cannot decrypt it. > > > 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). > > Good point. We can get around that by merging the ARK with the long ref: > the ARK contains all the information from the long ref as well as the > list of addresses, ports, DNS names etc; the whole ARK is exchanged > during JFK; the short ref is the address, port and ARK key. You can > either use the ARK key to retrieve the ARK from Freenet, or you can do > JFK and use the ARK key to validate the ARK exchanged during JFK. Still doesn't work. As I said, we may very well need the ARK to connect in the first place, certainly if the exchange is "offline". Now, this assumes we already have a connection, but it's a fair assumption as the interesting case is a newbie who has a working opennet connection starting to get darknet refs. We need to include enough info to fetch the ARK in the short-ref. How? We can't make the ARK decryption key be dependant on the pubkey hash, because if we do we open up a gaping hole to harvesting. We can't include the full SSK as that's another 64 bytes. Suggestions? > > > 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. > > MITM can be solved by using the shared secret to generate a keypair, > then putting the hash of the public key in the invite. During > handshaking, the responder must sign both its own identity and the > initiator's identity with the corresponding private key. But designing > custom protocols is a bad idea... how can we fold this back into JFK? We would be using JFK, we'd just add a few bits to it for a challenge/response on the one-time shared secret. It's not vulnerable to in-band MITM. If Mallory passively intercepts the invite, he can connect first and then MITM. If we put the hash of the pubkey in the invite, then the shared secret is now the hash of the pubkey. If we do a challenge/response, then we cannot send the pubkey in stage 2 (as we would normally do in anonymous connect JFK); we add at least one stage to the whole process. If we include BOTH a pubkey hash AND a shared secret, we can have a secure connection, however it would then be rather long - 70 bytes in base64 is 94 characters, so shorter than an SSK, it can be posted on IRC or on an IM client, but definitely not sent over the phone; but then, can 32 bytes be sent over the phone? One possibility, given these are time limited, is to shrink the shared secret aka one-time key to say 8 bytes; this should still be safe as an attacker would have to try every possible 8 byte sequence which is not going to be possible over any plausible internet connection! Then we have 62 characters, which comfortably fits in a single line, even if we have to separate the IP address (which we will have to if it's a DNS name). > > Another issue is whether the advantage of one-way exchange outweighs the > danger of people using weak shared secrets such as dictionary words. I'd > be more comfortable if each peer generated a separate keypair using a > good source of randomness, and both peers exchanged invites. The shared secret is generated from Yarrow in this proposal, and is only used once. It's a one-time invite. > > Cheers, > Michael -------------- 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/20071116/59ce5073/attachment.pgp>
