Okay, I'm a bit late on this post because I changed my mind
in a couple of places on the spec. But here's the P/K key exchange.
The full document (on my not responding machine) contains more detail
including key management and the ARK spec as well, but I can't get that
to you guys until the 8th.
The P/K key-exchange specification:
-----------------------------------
For the system, we want an exchange that establishes a shared
secret (Z) between two parties that can be used for symmetric
encryption (with key k). We want a system that requires each side
to prove their identity. For this description, assume Alice is
a Freenet node connecting to Bob, another node. Bob is accepting the
connection.
Among the requirements; Alice *must* know Bob's identity (his
public key) beforehand. Bob must not reveal his identity to Alice
in any way. This ensures that no 'dumb' connections can be made to
Bob.
The system must have perfect forward secrecy. This means that if
an attacker logs all the encrypted traffic between two nodes and later
seizes the private keys of each node, he/she still cannot decrypt the
traffic.
Also, there are some optional goals; First, we would like the protocol
to be optimized for time. The protocol should have as few wait states
or passes as possible. The current exchange protocol has one pass.
Also, each side should be able to optimize the protocol through
precalculation of some of the parameters. Also, the protocol parameters
should be transmitted in an order that allows both sides to maximize
their use of CPU time. Whenever possible, a node should be able
to calculate a value early, and while waiting for the response from
the other side.
We would like the protocol to be flexible for 'fringe' cases.
It would be nice, for example, if Bob could remain silent until he
has received enough information from Alice for Alice to prove that she
in fact knows she is talking to Bob. Also, this would allow Bob to
disguise his identity as a Freenet node until appropriate credentials
are presented.
The protocol should completely defeat the Man in the Middle attack
as well.
All said, here is the protocol:
Assume that the network shares a common generator (g), and a common
modulus (p). Assume that Alice's public key is Ya, Bob's is Yb. Alice's
private key is Xa, Bob's is Xb. Assume that '+' is the concatenation
operator, not addition.
1) Alice knows Bob's public key in advance. She generates
a random value, Ra, and calculates:
Ca = g^Ra mod p.
2) She also generates a signature, Sa, as the signature of Ca and Bob's
public key Yb:
Sa = sign(Ca + Yb)
3) Alice then sends Bob:
Ca + Ya + Sa
4) Bob generates a random value, Rb and calculates:
Cb = g^Rb mod p
5) He blinds Cb with his public key:
B = Cb XOR Yb
6) He also signs Cb with his private key:
Sb = sign(Cb)
7) Then sends Alice:
B + Sb
8) Alice receives Bob's values, and, knowing Bob's public key, unblinds
Cb:
Cb = B XOR Yb
9) She calculates their shared secret Z:
Z = Cb^Ra mod p
10) Finally, she verifies Bob's signature on Cb.
11) Bob receives Alice's values, and calculates their shared secret Z:
Z = Ca^Rb mod p
12) He verifies Alice's signature on Ca and Yb.
Rationale:
Steps 1,4,9, and 11 are the conventional Diffie-Helman anonymous key
agreement.
In step 2, Alice signs Bob's public key *and* her Diffie-Helman parameter,
which proves she is Alice, binds her to the DH parameter, and proves that
she knows Bob's public key. Bob can choose to remain silent until he
receives Alice's information. If he does so, he can keep his identity
secret until he finds that Alice really knows she is talking to Bob.
In step 3, Alice sends her public key in addition to the DH parameter
and her signature. This is because, though Alice must know Bob's public
key in advance, Bob may not have ever spoken to Alice. She must
assume that she is new to Bob (which will often be the case) and provide
Bob with her public key.
In step 5, Bob blinds his DH parameter with his public key. In most
circumstances, both sides will wish to perform the calculations
independently and transmit all their values as soon as possible (the
opposite of the "Silent Bob" situation). By blinding his DH parameter
with his public key, he can be certain that Alice cannot communicate
with him unless she does know his public key. Note that Bob *never*
sends an identification, unlike Alice. Steps 5 and 2 (where Alice
includes Bob's PK) are technically redundant. I'd like to hear
everyone's feelings on that.
In step 6, Bob generates a signature as well. This proves Bob's
identity and bind him to his DH parameter.
Notice also that in both transmissions the DH parameter is sent first.
This allows each side to begin calculating the shared secret while
waiting for the rest of the values to be received. In practice this
may not matter, but its possible that it may allow the implementers
more flexibility.
Both sides can precalculate the entire first transmission to the
other. This means that in the best case, each side need only do the
shared secret calculation and one signature verification. This should add
no more than 100ms (the signature verification) to one side. Signature
verification takes about 20ms on a P2-300 iirc. Also note that
all calculation, whether precalculated or not, is done in parallel on
both sides, so the total time is the max of any one sides calculation
plus the max network latency.
Scott
_______________________________________________
Freenet-dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
