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

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

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]

Reply via email to