Will Morton wrote:
I am designing a transport-layer encryption protocol, and obviously wish
to use as much existing knowledge as possible, in particular TLS, which
AFAICT seems to be the state of the art.
In TLS/SSL, the client and the server negotiate a 'master secret' value
which is passed
Will Morton wrote:
Eric Rescorla wrote:
May I ask why you don't just use TLS?
I would if I could, believe me. :o)
The negotiated key will be used for both reliable (TCP-like) and
non-reliable (UDP-like) connections, all tunnelled over a single UDP
port for NAT-busting purposes. For
Eric Rescorla wrote:
May I ask why you don't just use TLS?
I would if I could, believe me. :o)
The negotiated key will be used for both reliable (TCP-like) and
non-reliable (UDP-like) connections, all tunnelled over a single UDP
port for NAT-busting purposes. For the TCP-like component,
I am designing a transport-layer encryption protocol, and obviously wish
to use as much existing knowledge as possible, in particular TLS, which
AFAICT seems to be the state of the art.
In general, it's probably a good idea to look at existing mechanisms and
analyze why they're not
I am designing a transport-layer encryption protocol, and obviously wish
to use as much existing knowledge as possible, in particular TLS, which
AFAICT seems to be the state of the art.
In TLS/SSL, the client and the server negotiate a 'master secret' value
which is passed through a PRNG and
Will Morton [EMAIL PROTECTED] writes:
I am designing a transport-layer encryption protocol, and obviously wish
to use as much existing knowledge as possible, in particular TLS, which
AFAICT seems to be the state of the art.
In TLS/SSL, the client and the server negotiate a 'master secret'
