Misc manual tweaks

diff --git a/doc/man/man3/crypto_chacha20_encrypt.3monocypher b/doc/man/man3/crypto_chacha20_encrypt.3monocypher
index f868c70b7d3a1280216e0fb52612d04cf9c0755d..e72ab3e49e767cd1e45b28eefbe72713eef3d6ed 100644 (file)
--- 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 46647046a4ff81e573b353aa4c8aa411477de6fc..db38f5206b6a7b54bacbdfb7118ab801b3088803 100644 (file)
--- 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 a7179e6465e8450abb435b6a682ad7f5ef72e2b6..3797fda7449d0ed4c5c05ff86b76d0fb8d0a7ae4 100644 (file)
--- 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.