> My concern to this is that we are adding extra latency rather then using > the system to cut down on it. I'm worried about the time it takes per hop > as it is - I would almost consider sacrificing forward security if it > means we can save the seconds the keyexchange takes. > > Of course, maybe caching session keys for several connection is a better > idea.
I think caching keys will make latency a non-issue. If the lifetime of a session key is equal to the lifetime of a handshake, then there won't be any added latency except for the time to transmit the public key. Of course the expiration is different. I decide when my session key expires, whereas the nodes talking to me decide when my handshake expires. But it still doesn't matter if the key lifetime exceeds the handshake lifetimes of the nodes talking to you. The thing I can't figure out is how to gracefully deal with the situation that my session key has changed, but nodes are still trying to talk to me without handshaking (the handshake hasn't expired). The obvious thing to do is to detect the problem and request a new handshake. I'm not sure how to detect it elegently, though. > Another detail we should consider in the final crypto system is making it > possible to run an invisible node - ie one that comes alive only when a it > gets a signed request from a recognized peer. Such a node should be able > to masquerade as another service while waiting for the authentication. An excellent idea. _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
