Guus Sliepen [EMAIL PROTECTED] writes:
Compared with the entire TLS protocol it is much simpler, compared with
just the handshake protocol it is about as simple and probably just as
efficient, but as I said earlier, I want to get rid of the client/server
distinction.
You can't get rid of the
=Step 1:
Exchange ID messages. An ID message contains the name of the tinc
daemon which sends it, the protocol version it uses, and various
options (like which cipher and digest algorithm it wants to use).
By name of the tinc daemon, do you mean identification information?
That data
I wrote:
For some recent relevant papers, see the ACM-CCS '02 paper my colleagues
and I wrote on our JFK protocol (http://www.crypto.com/papers/jfk-ccs.ppt),
...
But of course I meant the url to be
http://www.crypto.com/papers/jfk-ccs.pdf
I don't know what I could have been thinking; I
If we use RSA encryption, then both sides know their message can only
be received by the intended recipient. If we use RSA signing, then we
both sides know the message they receive can only come from the assumed
sender. For the purpose of tinc's authentication protocol, I don't see
the
Guus Sliepen [EMAIL PROTECTED] writes:
On Mon, Sep 29, 2003 at 09:35:56AM -0700, Eric Rescorla wrote:
Was there any technical reason why the existing cryptographic
skeletons wouldn't have been just as good?
Well all existing authentication schemes do what they are supposed do,
that's
Bill Stewart [EMAIL PROTECTED] writes:
If we use RSA encryption, then both sides know their message can only
be received by the intended recipient. If we use RSA signing, then we
both sides know the message they receive can only come from the assumed
sender. For the purpose of tinc's
On Mon, Sep 29, 2003 at 11:54:20AM -0700, Eric Rescorla wrote:
Well all existing authentication schemes do what they are supposed do,
that's not the problem. We just want one that is as simple as possible
(so we can understand it better and implement it more easily), and which
is
On Mon, Sep 29, 2003 at 09:51:20AM -0700, Bill Stewart wrote:
=Step 1:
Exchange ID messages. An ID message contains the name of the tinc
daemon which sends it, the protocol version it uses, and various
options (like which cipher and digest algorithm it wants to use).
By name of
Guus Sliepen [EMAIL PROTECTED] writes:
On Mon, Sep 29, 2003 at 02:07:04PM +0200, Guus Sliepen wrote:
Step 2:
Exchange METAKEY messages. The METAKEY message contains the public part
of a key used in a Diffie-Hellman key exchange. This message is
encrypted using RSA with OAEP padding,
On Mon, 2003-09-29 at 06:07, Guus Sliepen wrote:
TLS makes a distinction between a client and a server. If possible I
wish to avoid making that distinction. If possible, I would also like to
continue to be able to use an RSA public/private keypair. This made me
*sketch* the following
Guus Sliepen [EMAIL PROTECTED] writes:
On Sat, Sep 27, 2003 at 07:58:14PM +0100, M Taylor wrote:
TLS makes a distinction between a client and a server. If possible I
wish to avoid making that distinction. If possible, I would also like to
continue to be able to use an RSA public/private
On Mon, Sep 29, 2003 at 07:53:29AM -0700, Eric Rescorla wrote:
I'm trying to figure out why you want to invent a new authentication
protocol rather than just going back to the literature and ripping
off one of the many skeletons that already exist (
Several reasons. Because it's fun, because
On Mon, Sep 29, 2003 at 05:57:46PM +0200, Guus Sliepen wrote:
Now, the attacker chooses 0 as his DH public. This makes ZZ always
equal to zero, no matter what the peer's DH key is.
I think you mean it is equal to 1 (X^0 is always 1).
Whoops, stupid me. Please ignore that.
--
Met
EKR writes:
I'm trying to figure out why you want to invent a new authentication
protocol rather than just going back to the literature and ripping
off one of the many skeletons that already exist (STS, JFK, IKE,
SKEME, SIGMA, etc.). That would save people from the trouble
of having to
Guus Sliepen [EMAIL PROTECTED] writes:
On Mon, Sep 29, 2003 at 07:53:29AM -0700, Eric Rescorla wrote:
I'm trying to figure out why you want to invent a new authentication
protocol rather than just going back to the literature and ripping
off one of the many skeletons that already exist (
M Taylor [EMAIL PROTECTED] writes:
On Fri, Sep 26, 2003 at 06:26:16PM -0700, Joseph Ashwood wrote:
Both SSL and SSH have had their security
problems . . , as perfect as Peter Gutmann would let us believe.
They may not be perfect but in neither case can Mallet do as much damage as
On Sat, Sep 27, 2003 at 07:58:14PM +0100, M Taylor wrote:
Perhaps a HMAC per chunk, rather than per the payload of a single UDP
datagram. I suspect per every 5 UDP datagrams, roughly ~7000 bytes of
payload may work. This will increase latency.
That would not work either. It would have the
M Taylor wrote:
Oh, and they fixed their flaws. SSHv1 is not recommended for use at all,
and most systems use SSHv2 now which is based upon a draft IETF standard.
SSL went through SSLv1, SSLv2, SSLv3, TLSv1.0, and TLSv1.1 is a draft IETF
standard.
It is curious, is it not, that there has
Adam Back wrote:
What conceivable trade-offs could you have to make to get acceptable
performance out of symmetric crypto encrypted+authenticated tunnel?
All ciphers you should be using are like 50MB/sec on a 1Ghz machine!!
There's fairly detailed performance data for Linux FreeS/WAN IPsec
On Fri, Sep 26, 2003 at 06:26:16PM -0700, Joseph Ashwood wrote:
I would have CC'd the author of the response page, but it fails to mention
an author, in spite of the Comments are welcome statement at the
beginning.
There is a Contact link left of it. You could've replied to me as
well.
On Fri, Sep 26, 2003 at 06:26:16PM -0700, Joseph Ashwood wrote:
Truncated MAC
tinc will continue to use only the first 32 bits by default.
Simply put this is unacceptable from a security standpoint. The view taken
is that the extra 128 bits represents a significant overhead in the
Hello Peter Gutmann and others,
Because of its appearance on this mailing list and the Slashdot posting
about Linux's answer to MS-PPTP, and in the tinc users' interest, we
have created a section about the current security issues in tinc, which
currently contains a response to Peter Gutmann's
,
Because of its appearance on this mailing list and the Slashdot posting
about Linux's answer to MS-PPTP, and in the tinc users' interest, we
have created a section about the current security issues in tinc, which
currently contains a response to Peter Gutmann's writeup:
http://tinc.nl.linux.org
And a response. I have taken the liberty of copying the various portions of
the contents of the webpage to this email for response. I apologize for the
formatting confusion which may mistake Peter Gutmann's comments with those
of the semi-anonymous misinformed person under scrutiny.
I would have
24 matches
Mail list logo
