FIFiloSottile·Feb 19, 2023
There is no description of the protocol or of its security goals, so I am making some guesses based on a cursory look at the source and what I imagine this might be for.
A single symmetric key is derived for both directions, and there is no checking of nonces, so as far as I can tell any message can be dropped, reordered, or replayed in both directions. (Including replaying message from A to B as if they were from B to A.) This is a bit like using ECB and likely to lead to fun application-specific attacks like [0].
This is very much rolling your own crypto, in a dangerous way. I am on the record as being "against" the "don't roll your own crypto" refrain [1], but mostly because it doesn't work: it should discourage people from publishing hand-rolled protocols such as this, but instead people think it means "don't roll your own primitives"
Read the rest
and accept any use of "Ed25519/X25519" as probably secure.
Please read about the Noise framework [2] to get an idea of how much nuance there is to this, and consider using a Go implementation of it [3] instead.
P.S. This kind of issue is also why I maintain that NaCl is not a high-level scheme [4]: this could have used NaCl and have the exact same issues. libsodium has a couple slightly higher-level APIs that could have helped, secretstream [5] and kx [6], but again please use Noise.
[0] https://cryptopals.com/sets/2/challenges/13
[1] https://securitycryptographywhatever.buzzsprout.com/1822302/...
[2] https://noiseprotocol.org/noise.html
[3] https://github.com/flynn/noise
[4] https://words.filippo.io/dispatches/nacl-api/
[5] https://libsodium.gitbook.io/doc/secret-key_cryptography/sec...
[6] https://libsodium.gitbook.io/doc/key_exchange