Gutmann Soundwave Therapy

[James A. Donald]

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 majordomo at metzdowd.com