James A. Donald wrote: >> I have figured out a solution, which I may post here >> if you are interested.
Ian G wrote: > I'm interested. FTR, zooko and I worked on part of > the problem, documented briefly here: > http://www.webfunds.org/guide/sdp/index.html I have posted "How to do VPNs right" at http://jim.com/security/how_to_do_VPNs.html It covers somewhat different ground to that which your page covers, focusing primarily on the problem of establishing the connection. "humans are not going to carry around large strong secrets every time either end of the connection restarts. In fact they are not going to transport large strong secrets any time ever, which is the flaw in SSL and its successors such as IPSec and DTLS "What humans are going to do, and what the user interface must support, and the cryptography somehow make secure, is set up a username and a rather short password, and enter that password on request - rather too easily enter it on request without necessarily checking who they are giving it to. Our security has to work with humans as they are, and make what humans are naturally inclined to do secure, rather than try to change what humans are naturally inclined to do." It covers the cryptography of packets only to the depth needed to establish the required properties of sessions: "each packet within a session must have its own unique IV (nonce), and each session must have its own symmetric encryption secret and authentication secret. We have to have a new session every client restart, every server restart, and every 2^64 bytes. At the beginning of each new session, new strong secrets, large truly random numbers, have to be negotiated for symmetric encryption and authentication." My page completely ignores the routing issue, another hard problem which existing VPNs frequently do wrongly, or not at all. It presupposes the existence of good random number sources. It does not address the question of denial of service attacks against the session establishment protocol, though I have written that up elsewhere, and will publish that shortly. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
