Thank you for the answer Jason, I appreciate your time and excellent work. After deep dive I’ve found transport messages and RFC6479 replay detection implementation.
Cheers, Hristo > On 25 Aug 2019, at 18:56, Jason A. Donenfeld <[email protected]> wrote: > > On Sun, Aug 25, 2019 at 9:36 AM Hristo Georgiev <[email protected]> > wrote: >> >> Hello >> I’m working on file transfer protocol inspired by Noise and Wireguard over >> UDP with static keys so the handshake pattern is going to be >> Noise_IK_25519_ChaChaPoly_BLAKE2s or KK. In general i’m trying to follow >> NoiseSocket spec but adapted to UDP and i was wondering where to place the >> ‘nonce’ into packet to extend the protocol as described into p.11.4 in >> NoiseProtocol spec >> http://www.noiseprotocol.org/noise.html#out-of-order-transport-messages . >> So I had a look into WireGuard implementation (which I use a lot in multiple >> sites, mostly on EdgeRouters) >> so what i found in noise.c line 445 message_decrypt: >> >> chacha20poly1305_decrypt(dst_plaintext, src_ciphertext, src_len, >> hash, NOISE_HASH_LEN, >> 0 /* Always zero for Noise_IK */, key)) >> >> Correct me if I’m mistaken, I’m not C programer nor cryptographer, I think >> this zero here is the Nonce. If that’s the case what security sacrifices and >> the chance for replay attacks are? >> Would it be Ok if I also hardcode the Nonce to 0 in my implementation? > > This isn't the nonce used as part of the transport object, but rather > a single encryption/decryption that happens with a unique key as part > of the handshake. It being zero is a natural consequence of the > protocol flow. > > Don't hardcode a zero nonce in transport messages. _______________________________________________ WireGuard mailing list [email protected] https://lists.zx2c4.com/mailman/listinfo/wireguard
