Browse Source

docs: authentication primitives: improved security and performance infos (1.2) (#6692)

docs: authentication primitives: improved security and performance infos
Christopher Klooz 3 years ago
parent
commit
c3bbb5e57a
1 changed files with 11 additions and 8 deletions
  1. 11 8
      docs/internals/security.rst

+ 11 - 8
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.
   and is also tracked locally on the client to avoid counter reuse.
 
 
 - The authentication primitive is either HMAC-SHA-256 or BLAKE2b-256
 - 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
 - The primitive used for authentication is always the same primitive
   that is used for deriving the chunk ID, but they are always
   that is used for deriving the chunk ID, but they are always