summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/buffer/buffer.h
diff options
context:
space:
mode:
authorjsing <>2014-06-24 18:12:09 +0000
committerjsing <>2014-06-24 18:12:09 +0000
commit125ab32227935a33d4c3ef80e58ed8f9d7cfbe8d (patch)
tree77b512bc366b09aa3f9194007a50fa04d944872c /src/lib/libcrypto/buffer/buffer.h
parent6769d1991fea1c3627ae6df2bf0232cba30798a8 (diff)
downloadopenbsd-125ab32227935a33d4c3ef80e58ed8f9d7cfbe8d.tar.gz
openbsd-125ab32227935a33d4c3ef80e58ed8f9d7cfbe8d.tar.bz2
openbsd-125ab32227935a33d4c3ef80e58ed8f9d7cfbe8d.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 'src/lib/libcrypto/buffer/buffer.h')
0 files changed, 0 insertions, 0 deletions