summaryrefslogtreecommitdiffstats
path: root/share/man/man7
diff options
context:
space:
mode:
authorjsing <jsing@openbsd.org>2014-06-24 18:12:09 +0000
committerjsing <jsing@openbsd.org>2014-06-24 18:12:09 +0000
commit61bfdc17bc6088c6118a56366ced983452cbf3d1 (patch)
tree1d0c895e10086923cf405ca3fc4294160fa691f9 /share/man/man7
parentExtend the chacha regress to cover the ChaCha interface, in addition to the (diff)
downloadwireguard-openbsd-61bfdc17bc6088c6118a56366ced983452cbf3d1.tar.xz
wireguard-openbsd-61bfdc17bc6088c6118a56366ced983452cbf3d1.zip
If a chacha operation does not consume all of the generated key stream,
ensure that we save it and consume it on subsequent writes. Otherwise we end up discarding part of the key stream and instead generate a new block at the start of the next write. This was only an issue for callers that did multiple writes that are not multiples of 64 bytes - in particular, the ChaCha20Poly1305 usage does not hit this problem since it performs encryption in a single-shot. For the same reason, this is also a non-issue when openssl(1) is used to encrypt with ChaCha. Issue identified by insane coder; reported to bugs@ by Joseph M. Schwartz. ok beck@
Diffstat (limited to 'share/man/man7')
0 files changed, 0 insertions, 0 deletions