diff --git a/docs/internals/security.rst b/docs/internals/security.rst
index 3f79e66bd7..e58778f6bf 100644
--- a/docs/internals/security.rst
+++ b/docs/internals/security.rst
@@ -142,14 +142,17 @@ Depending on the chosen mode (see :ref:`borg_init`) different primitives are use
   and is also tracked locally on the client to avoid counter reuse.
 
 - The authentication primitive is either HMAC-SHA-256 or BLAKE2b-256
-  in a keyed mode. HMAC-SHA-256 uses 256 bit keys, while BLAKE2b-256
-  uses 512 bit keys.
-
-  The latter is secure not only because BLAKE2b itself is not
-  susceptible to `length extension`_, but also since it truncates the
-  hash output from 512 bits to 256 bits, which would make the
-  construction safe even if BLAKE2b were broken regarding length
-  extension or similar attacks.
+  in a keyed mode.
+
+  Both HMAC-SHA-256 and BLAKE2b have undergone extensive cryptanalysis  
+  and have proven secure against known attacks. The known vulnerability
+  of SHA-256 against length extension attacks does not apply to HMAC-SHA-256.
+  
+  The authentication primitive should be chosen based upon SHA hardware support:
+  all AMD Ryzen, Intel 10th+ generation mobile and Intel 11th+ generation
+  desktop processors, Apple M1+ and most current ARM64 architectures support
+  SHA extensions and are likely to perform best with HMAC-SHA-256.
+  64-bit CPUs without SHA extensions are likely to perform best with BLAKE2b.
 
 - The primitive used for authentication is always the same primitive
   that is used for deriving the chunk ID, but they are always