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 (
15 matches
Mail list logo
