Dmitry Chestnykh added the comment:
Christian: yes, and I'm also happy that you kept the drawing of hash tree, as
it helps a lot with understanding of terminology.
I had a quick look at the patch and it looks good to me.
Some comments, which you can ignore:
In keyed hashing example there's:
+>>> def verify(cookie, sig):
+... good_sig = sign(cookie)
+... if len(sig) != len(good_sig):
+... return False
+... # Use constant-time comparison to avoid timing attacks.
+... result = 0
+... for x, y in zip(sig, good_sig):
+... result |= ord(x) ^ ord(y)
+... return result == 0
Perhaps, you can replace comparison with hmac.compare_digest(sig, goodsig) now
that we have it in Python.
+*Salted hashing* (or just hashing) with BLAKE2 or any other general-purpose
+cryptographic hash function, such as SHA-256, is not suitable for hashing
+passwords. See `BLAKE2 FAQ <https://blake2.net/#qa>`_ for more
+information.
Maybe also point readers to hashlib.html#key-derivation
+On platforms with support for 64bit integer types (some 32bit platforms,
+all 64bit platforms), blake2b and blake2s are supported.
Theoretically, blake2s shouldn't require 64bit int, reference code only uses it
for sizes -- is this something worth fixing? Are there platforms that have
uint32_t, but not uint64_t?
@@ -162,7 +192,7 @@ class HashLibTestCase(unittest.TestCase):
for cons in self.hash_constructors:
h = cons()
self.assertIsInstance(h.name, str)
-self.assertIn(h.name, self.supported_hash_names)
+#self.assertIn(h.name, self.supported_hash_names)
self.assertEqual(h.name, hashlib.new(h.name).name)
Was this commented-out on purpose? Also, in setup.py:
+#if os.uname().machine == "x86_64":
+# Every x86_64 machine has at least SSE2.
+#blake2_macros.append(('BLAKE2_USE_SSE', '1'))
--
nosy: +dchest
___
Python tracker
<http://bugs.python.org/issue26798>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
