diff options
author | Jonathan Nieder <jrnieder@gmail.com> | 2018-08-04 01:52:47 -0700 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2018-08-07 07:40:43 -0700 |
commit | 0ed8d8da374f648764758f13038ca93af87ab800 (patch) | |
tree | dfc6bfc90c19dace8f5d84092a3f06dc14a5f734 /Documentation/RelNotes/1.7.12.2.txt | |
parent | doc hash-function-transition: note the lack of a changelog (diff) | |
download | tgif-0ed8d8da374f648764758f13038ca93af87ab800.tar.xz |
doc hash-function-transition: pick SHA-256 as NewHash
From a security perspective, it seems that SHA-256, BLAKE2, SHA3-256,
K12, and so on are all believed to have similar security properties.
All are good options from a security point of view.
SHA-256 has a number of advantages:
* It has been around for a while, is widely used, and is supported by
just about every single crypto library (OpenSSL, mbedTLS, CryptoNG,
SecureTransport, etc).
* When you compare against SHA1DC, most vectorized SHA-256
implementations are indeed faster, even without acceleration.
* If we're doing signatures with OpenPGP (or even, I suppose, CMS),
we're going to be using SHA-2, so it doesn't make sense to have our
security depend on two separate algorithms when either one of them
alone could break the security when we could just depend on one.
So SHA-256 it is. Update the hash-function-transition design doc to
say so.
After this patch, there are no remaining instances of the string
"NewHash", except for an unrelated use from 2008 as a variable name in
t/t9700/test.pl.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: brian m. carlson <sandals@crustytoothpaste.net>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Acked-by: Dan Shumow <danshu@microsoft.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'Documentation/RelNotes/1.7.12.2.txt')
0 files changed, 0 insertions, 0 deletions