|
@@ -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
|