>
> When a node makes an outward connection, it always sends its public key in
> the clear (in step 3, where Alice sends Ya). This somewhat defeats the
> point of keeping public keys as quasi "secret". Anyone who eavesdrops
> on a node's outgoing traffic can learn its public key.
>
> One way to avoid this would be to postpone sending the public key and
> send it encrypted after the shared secret is established.
I agree. However, this would add a pass to the protocol. I'm not opposed
to it if it can be done in the HandshakeRequest/Reply, but I believe some
people had objections to that.
> Scott included a blinding step in the protocol to assure that Alice
> knows Bob's public key. However I don't think it is necessary as she
> signs his public key elsewhere in the protocol. If we remove that,
> the message flow is:
>
> Alice->Bob: Ca + Ya + Sign( Ca + Yb )
> Bob->Alice: Cb + Sign( Cb )
>
> If we take Ya out of the first message and include it in a later
> encrypted message, we would have:
>
> Alice->Bob: Ca + Sign( Ca + Yb )
> Bob->Alice: Cb + Sign( Cb )
> Alice->Bob: Encrypt_Z( Ya )
>
> (where Encrypt_Z means to encrypt under the shared secret value Z).
> With this change, Bob would verify Alice's signature only after the
> third step. (That step could possibly be made optional; if Bob already
> had Alice's key he could say so during step 2.)
>
> There are many algorithms in the literature for authenticated DH key
> agreement. A good place to look is section 12.6.1 of the Handbook of
> Applied Cryptography, online at http://www.cacr.math.uwaterloo.ca/hac/.
> This describes among others the MTI family of protocols, which do the
> authentication implicitly and so skip the signature-verification step,
> which can be costly.
>
> It also describes the Station-To-Station (STS) protocol, which is similar
> to Scott's proposal. However, the details are different. Using Scott's
> notation, the messages are:
>
> Alice->Bob: Ca
> Bob->Alice: Cb + Encrypt_Z( Sign( Cb + Ca ) )
> Alice->Bob: Encrypt_Z( Sign( Ca + Cb ) )
>
> This protocol assumes that both parties know each other's public keys
> ahead of time. We could modify it as follows for Alice to send public
> key information:
>
> Alice->Bob: Ca
> Bob->Alice: Cb + Encrypt_Z( Sign( Cb + Ca ) )
> Alice->Bob: Encrypt_Z( Ya + Sign( Yb + Ca + Cb ) )
>
> The change is that Alice includes her public key in her second message,
> and also signs Bob's public key to prove that she knows it.
>
> Comparing this to Scott's above, STS is more complicated, but it
> provides more explicit assurances. By putting the signatures inside
> the encryption, but making the signatures be on the exchanged values,
> it explicitly assures that the person signing knows the shared secret
> and received the earlier message from the counterparty.
>
> It also provides verification, so that at the completion of the protocol
> each party is confident that it has established communication with
> the other. Scott's doesn't fully achieve this, as at the end Alice has
> received only Cb + Sign(Cb) from Bob, which provides no evidence that
> he has seen her messages and could be replayed from earlier exchanges.
> (The expectation is that any such flaws will be detected at later stages,
> when messages begin to be exchanged and the two sides don't truly share
> the same secret key.)
The replay bit had been bothering me actually, but as you said I wrote it
off knowing that a person replaying one side of the authentication
wouldn't be able to communicate.
I like the STS protocol, but it does add another pass to the protocol, and
we are very pressed for time in the negotiation, as each pass adds up over
the numerous hops.
> STS is not much more work and is better analyzed in the literature,
> so I think it would be a preferred choice. Alternatively if
> greater efficiency is desired there are a number of protocols which
> are variants of the MTI family and provide provable security, for
> example http://www.manta.ieee.org/groups/1363/P1363a/KeyEstab.html and
> http://www.isi.edu/~gts/paps/ast99.ps.gz.
>
> Hal
>
>
> > 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
>
>
_______________________________________________
Freenet-dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
