-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> encryption method part of the address. For example, what if you have a
> reference in your datastore from last year which points to:
> twof:tcp/piclab.com:19114, but since then twofish has been broken and
> everyone is using threefish now? Or if you have a node which supports
> multiple encryption types you will have a messy proliferation of different
> addresses for the same node, and you might end up using a weaker algorithm
> than you have to. (e.g., Alice supports both DES and rot13, Bob only
> supports rot13, so Bob's reference to Alice's node is
> rot13:tcp/alice:19114; Chandler gets this reference from Bob, but even
> though Chandler speaks DES he ends up speaking rot13 to Alice.)
I have to agree here. Cipher negotiation is a must.
> But you can't just start speaking encrypted gibberish right away. There
> has to at least be a key exchange first. =)
>
> Why not just make the negotiation look like something commonplace like
> SSH2? (Or even just -use- SSH2? I'm not too familiar with the issues
> involved, but my impression is that the transport part is a generic way
> to negotiate and secure any transport-level connection?)
Key exchange is indecipherable from random communications. They involve
sending large random numbers back and forth. So it isn't necessary to
worry about this phase of the protocol.
At least initially, the servers will share a large prime P and a generator
G, and will perform diffie-helman key exchange (which again to an
adversary appears no different than random data)
This will provide both ends with a cipherkey, at which point both can
transition to secure traffic. I propose that at least initially, we agree
on a single cipher that *must* be supported by all the servers. In fact,
I propose XOR. (hold your lynching for a moment)
The diffie-helman key exchange provides a random key that is usually quite
a bit larger than the required cipherkey. This means that both servers
will share an additional n bits (where n is usually P's bits minus the
number you need for the cipher later). Cipher negotiation requires that
we send a list of ciphers that both ends support, and selecting the
strongest cipher that both share. Imagine this scenario:
Alice and Bob perform DH key negotiation, and then share a common k of
length 1120 bits.
Then Alice sends Bob her choiced of ciphers, XOR'ed with the first 256
bits of k (padding her cipherlist with nulls):
"Blowfish 3DES DES" ^ k(0-256) = M1
Bob does the same with the second 256 bits (so they dont share key
material and facilitate some easy cryptanalsis):
"MARS 3DES" ^ k(256-512) = M2
Alice sends bob M2, Bob sends Alice M1. Even if the attacker decodes the
message (which isn't necessarily unlikely), he only knows which cipher is
being used. The rest of the bits are used as the key for the cipher.
Bob and Alice intersect M1 and M2, finding 3DES as the cipher to
use. They then use the next 168 bits as the key for 3DES.
Mainly, the XOR negotiation acts as a one-time-pad encryptor, primarily to
disguise the fact that the connection is anything other than random data
(so Mallory can't see the negotiation and peg the traffic as a freenet
connection).
Scott
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE5CcaRpXyM95IyRhURAh9ZAKC8bliJuqW3/p5xVtLMZ5g0wmdG8wCfSOuv
4jEbU9wpE+8TG22b6/6AVV8=
=guAv
-----END PGP SIGNATURE-----
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
