[Cryptography-dev] Message Digest Naming / PEP247

[Donald Stufft]

On Oct 1, 2013, at 5:10 PM, Paul Kehrer <paul.l.kehrer at gmail.com> wrote:

> Hey guys,
> 
> I'm implementing some basic hashes in cryptography (specifically the
> ones NIST has test vectors for: SHA-1 and SHA-2 family) and wanted to
> get some opinions on a few questions.
> 
> 1) What would people like the module to be named? OpenSSL generally
> refers to them as "message digests" but pedantically they're
> cryptographic hash functions that output message digests. I currently
> have the module as cryptography.primitives.digests, but we could do
> cryptography.primitives.hashes, or some third option.

I'd call the module hashes, it's the proper name for it and we should
base our API on what's correct and not inherent OpenSSL's brokenness.

> 
> 2) My current implementation complies with PEP247 with the exception
> of the new function. In its place you do something like this:
> 
> from cryptography.primitives import digests
> digest = digests.SHA512()
> digest.update("text goes here")
> digest.update("more things to hash into the object state")
> digest.hexdigest()
> 
> I'm leaning against implementing new since I don't really see much
> advantage, but this is your chance to tell me how wrong I am!

Theoretical advantage is that you can swap it out with any other PEP247
compliant hash. However I think PEP247's new() function is particularly
bad. It forces a module per hash layout which is pretty terrible.

Additionally hashlib itself doesn't even support this, it has a new() function
but it takes a string to do the lookup which I find A) pointless compared to
getattr() and B) it's slower than just using the named constructors.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20131001/f7e0b29c/attachment.sig>