On Fri, 28 Apr 2000, hal at finney.org wrote: <snip> > This would allow us to change the nodes now to respond to that > DHKeyExchange command with some kind of error message. The client could > then fall back to a non encrypted exchange. This is what I had in mind > earlier when I asked about backwards compatibility.
The problem is the current nodes out there won't respond correctly to this either. If we can get some sort structure for it maybe we could get a correct "I don't do crypto" response in by Monday, but personally I favor just going for breaking backwards compatibility : we released early, but we can't pay the price of having released an alpha by being stuck with not being able to change the protocol. I say, get a fairly stable node out that uses the current protocol and no encryption that people can play with. And then let us go wild on the dev version and change whatever we want, not having our hands tied by people using it. > I don't think it is all that helpful to hide the choice of which cipher > is used. In practice there are only a few options so it doesn't add > much security. I think it was more a question of trying to make the communications hard to detect. Of course hiding the protocol is not going to help the security of it. <snip> > Leaving aside the question of whether this exchange needs to be encrypted, > note that Bob has enough information once he receives Alice's message > to know which cipher will be chosen. Therefore the usual response for > Bob is to simply pick one of Alice's ciphers and return that (or return > a refusal if none of them are acceptable). I agree. I think it is important that we not have any unnecessary forward-back communications, since getting as low latency as possible when setting up connections is important to making requests fast. > One final point: this kind of protocol is very secure against passive > attacks, where an eavesdropper wants to know what is being said. > But it does not defend against active attacks, where the adversary can > intervene in the message stream, altering, removing or adding messages. > To prevent those it is necessary to share information ahead of time, > such as long term public keys used for signatures. This is something > that can be added later as it requires a much larger infrastructure. Right, but if the attacker wants to be a node, he can be a node, why would he want to pretend to be another node? I guess a very powerful attacker could possibly delude you completely into thinking your node is on Freenet, when actually all the nodes connections have been taken over by the attacker, so he can see exactly what transactions start from you. But that sort of ultra-paranoid security has to wait for a number of other things anyways. > Hal > > _______________________________________________ > Freenet-dev mailing list > Freenet-dev at lists.sourceforge.net > http://lists.sourceforge.net/mailman/listinfo/freenet-dev -- Oskar Sandberg md98-osa at nada.kth.se #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1 lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/) _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
