Re: Gutmann Soundwave Therapy
On Fri, Feb 01, 2008 at 02:51:36PM +0800, Sandy Harris wrote: > What I don't understand is why you think tinc is necessary, > or even worth the trouble. > > IPsec is readily available -- built into Windows, Mac OS > and various routers, and with implementations for Linux > and all the *BSDs -- has had quite a bit of expert > security analysis, and handles VPNs just fine. > > Does tinc do something that IPsec cannot? Yes, there are a few reasons why people use tinc instead of IPsec. Those people who tried both tell me tinc is much easier to set up. Tinc tunnels over UDP and/or TCP. This allows it to work in situations where IPsec would not, for example behind (masquerading) firewalls. Tinc does not need fixed IP addresses at endpoints; endpoints can have more than one IP address, or hostnames, so it even works when one has dynamic DNS. With tinc, you can set up VPNs with more than 2 nodes, not by configuring more tunnels, but just by specifying endpoints. Tinc itself will handle the packet routing. It tries to set up a full mesh, but it has a built-in routing protocol, not unlike OSPF, that can route packets via intermediate nodes if that is necessary. As a side effect it provides some redundancy. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: questions on RFC2631 and DH key agreement
- Original Message -
From: "' =JeffH '" <[EMAIL PROTECTED]>
To:
Cc: "' =JeffH '" <[EMAIL PROTECTED]>
Sent: Friday, February 01, 2008 1:53 PM
Subject: questions on RFC2631 and DH key agreement
(ya and yb) if { p, q, g, j } are known to both parties.
So if p, q, g are not static, then a simplistic, nominally valid, DH
profile
would be to..
a b
-- --
g, p, ya >
<--- yb
..yes?
I would actually recommend sending all the public data. This does not take
significant additional space and allows more verification to be performed. I
would also suggest looking at what exactly the goal is. As written this
provides no authentication just privacy, and if b uses the same private key
to generate multiple yb the value of b will slowly leak.
Other than for b perhaps wanting to verify the correctness of { p, q, g,
j }
("group parameter validation"), is there any reason to send q ?
You can then use the gpb trio for DSA, leveraging the key set for more
capabilities.
Joe
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: questions on RFC2631 and DH key agreement
Oh, yeah, sorry, your diagram (or whoever drew it) does in fact answer my second question wrt what one needs to send over the wire wrt a simplistic DH profile. Just g, p, and a public key (y). thanks again, =JeffH - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: questions on RFC2631 and DH key agreement
[EMAIL PROTECTED] said: > http://www.xml-dev.com/blog/index.php?action=viewtopic&id=196 thanks, but that doesn't actually answer my first question. It only documents that a and b (alice and bob) arrive at the ZZ value independently. My question is actually concerning section 2.1.2 "Generation of Keying Material" in RFC2631. My interpretation is that both parties are expected to generate "keying material" per that section on their own, rather than one party doing so and transmitting the results to the other party. This may seem obvious to those steeped in the tradition here, but it perhaps isn't to outsiders (i have a foot in both worlds). thanks, =JeffH - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
