DH is used to ensure that every connection between every pair of weave router nodes that ever gets established uses a unique session key. Yes, the public key is exchanged in the clear, and yes, that is MITMable. But as you say, the subsequent combination of the result of the DH with the non-exchanged password solves that.

What is the weakness with this approach? Is your point that there's nothing gained from doing the DH - you may as well just generate a secret key randomly, exchange that between the peers in the clear, and still have them combine that with the password secret, and the level of information exposed is the same?

I think there is a difference. Say you have a captured stream of traffic and you want to decrypt it. With the simpler non-DH scheme, you already have the basic key, so all you need to do is guess the password, and run that through sha256 and then you can decrypt the entire stream. Now you have the password, you can decrypt every stream you capture from now on. But with the DH scheme, you have to both guess the password, and the ephemeral private keys which are never exchanged (either that, or break Curve25519). Even once you've done that, you only get access to that one captured stream - sure, you now know the password, but every connection between weave routers will use different random private keys to their DH, so you'll still have to brute force those for every stream you capture (or, again, break Curve25519). So ISTM there is a substantial difference there. That, to me, is the point of using the DH. But maybe I'm missing something... I'm slightly wondering whether people here are considering the use of DH and Public Key crypto by weave in the context of the usual "generate keys once and save them". This is just not the case in weave - weave generates fresh public and private keys for EVERY connection between routers.

There is no requirement for weave that the password is human readable. It can be supplied through a file, so you can happily dd if=/dev/random of=/my/weave/passwd bs=1k count=1 to create a suitable weave password

So the DH does give you some degree of ephemerality, yes... but as used, only if you're not already being MITM'd. (If you are subject to MITM, then it degenerates to the case you describe where peers are just picking a random number and exchanging it in the clear.) You could upgrade this to not have that weakness under MITM at all by doing the DH after the KDF: use the KDF to key an HMAC, thus preventing MITMs by someone lacking the password at the time of the DH exchange. I don't think there are any additional expenses or drawbacks associated with doing this.

Just to clarify, the attack you want to protect against is that of an adversary being able to conclude the DH public key exchange with a bona fide weave peer, despite having no knowledge of the password. Correct?

But what can an adversary learn from doing so? All subsequent messages on the connection are encrypted with the secret key, which has the password mixed in.

> There is no requirement for weave that the password is human readable. It can be supplied through a file, so you can happily dd if=/dev/random of=/my/weave/passwd bs=1k count=1 to create a suitable weave password

Turns out that feature I was thinking about has been removed, so the above is not true.

I don't think that feature ever existed.

Though a representation in a particular character set does not prevent the password from being strong.

> All of the privacy and integrity you could produce with the system described is what comes from the password.

That is correct. I guess calling this a 'password' is perhaps misleading in our docs, since it could be seen as implying human-readability and cryptographic weakness. As msackman says, the 'password' can in fact be as strong as you like.