docs: authentication primitives: improved security and performance infos (master)

docs/internals/security.rst

@@ -141,7 +141,7 @@ Depending on the chosen mode (see :ref:`borg_init`) different AEAD ciphers are u
 
 The chunk ID is derived via a MAC over the plaintext (mac key taken from borg key):
 
-- HMAC-SHA256 - super fast IF you have hw accelerated SHA256.
+- HMAC-SHA256 - super fast IF you have hw accelerated SHA256 (see section "Encryption" below).
 - Blake2b - very fast, purely software based algorithm.
 
 For each borg invocation, a new session id is generated by `os.urandom`_.
@@ -223,14 +223,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:
+  AMD Ryzen and new 12th+ Generation Intel Core processors (beginning with 
+  the Alder Lake architecture) support SHA extensions and are likely to perform
+  best with HMAC-SHA-256. Among ARM processors, support for SHA extensions varies.
+  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