From de388dbe98c2e63162799ca79fbd1c3494c4e7f0 Mon Sep 17 00:00:00 2001 From: Michael Savage Date: Fri, 29 Dec 2017 23:56:40 +0000 Subject: [PATCH] Misc manual tweaks --- doc/man/man3/crypto_chacha20_encrypt.3monocypher | 12 +++++------- doc/man/man3/crypto_lock_init.3monocypher | 14 +++++++------- .../man3/crypto_sign_init_first_pass.3monocypher | 9 +++++---- 3 files changed, 17 insertions(+), 18 deletions(-) diff --git a/doc/man/man3/crypto_chacha20_encrypt.3monocypher b/doc/man/man3/crypto_chacha20_encrypt.3monocypher index f868c70..e72ab3e 100644 --- a/doc/man/man3/crypto_chacha20_encrypt.3monocypher +++ b/doc/man/man3/crypto_chacha20_encrypt.3monocypher @@ -60,7 +60,7 @@ messages, which allows decryption. 24-byte nonces can be selected at random. 8-byte nonces .Em cannot . -They are too small, and the same number may be selected twice by +They are too small, and the same nonce may be selected twice by accident. See .Xr intro 3monocypher @@ -95,23 +95,21 @@ The .Fa plain_text and .Fa cipher_text -buffers may -.Em not . -They must either be the same buffer (for in-place encryption), or -disjoint. +must either be the same buffer (for in-place encryption), or +non-overlapping. .Pp .Fn crypto_chacha20_init initialises the .Vt crypto_chacha_ctx context. -It uses an 8-byte nonce, too small to be selected at random. +It uses an 8-byte nonce, which is too small to be selected at random. Use a counter. .Pp .Fn crypto_chacha20_x_init initialises the .Vt crypto_chacha_ctx context. -It uses 24-byte nonce, big enough to be selected at random. +It uses a 24-byte nonce, which is big enough to be selected at random. .Pp .Fn crypto_chacha20_x_init is recommended over diff --git a/doc/man/man3/crypto_lock_init.3monocypher b/doc/man/man3/crypto_lock_init.3monocypher index 4664704..db38f52 100644 --- a/doc/man/man3/crypto_lock_init.3monocypher +++ b/doc/man/man3/crypto_lock_init.3monocypher @@ -235,14 +235,14 @@ XChacha20 derives from Chacha20 the same way XSalsa20 derives from Salsa20, and benefits from the same security reduction (proven secure as long as Chacha20 itself is secure). .Sh SECURITY CONSIDERATIONS -Using this incremental for decryption means authentication is -incremental as well. -This allows two errors: forgetting to call -.Fn crypto_unlock_final -altogether, and start processing the message before the authentication -is complete. +Messages must be completely decrypted before they can be verified. +Make sure to call +.Fn crypto_unlock_final , +and make sure to check its return value +.Em before +processing the message. Messages may be stored before they are verified, but they cannot be -.Em trusted . +trusted. Processing untrusted messages increases the attack surface of the system. Doing so securely is hard. diff --git a/doc/man/man3/crypto_sign_init_first_pass.3monocypher b/doc/man/man3/crypto_sign_init_first_pass.3monocypher index a7179e6..3797fda 100644 --- a/doc/man/man3/crypto_sign_init_first_pass.3monocypher +++ b/doc/man/man3/crypto_sign_init_first_pass.3monocypher @@ -167,10 +167,8 @@ These functions implement EdDSA with Curve25519 and Blake2b. This is the same as Ed25519, with Blake2b instead of SHA-512. Ed25519 is described in RFC 7748. .Sh SECURITY CONSIDERATIONS -In addition to those documented on -.Xr crypto_sign 3monocypher , -incremental signature verification encourages the user to start -processing the message before verification is done. +Messages are not verified until the call to +.Xr crypto_check_final . Messages may be stored before they are verified, but they cannot be .Em trusted . Processing untrusted messages increases the attack surface of the @@ -178,6 +176,9 @@ system. Doing so securely is hard. Do not process messages before calling .Fn crypto_check_final . +Additionally, the security considerations documented in +.Xr crypto_sign 3monocypher , +apply here too. .Sh IMPLEMENTATION DETAILS EdDSA signatures require two passes that cannot be performed in parallel. -- 2.47.3