Mailman 3 October 2013 - Cryptography-dev

Criteria for first release?
by Alex Gaynor Nov. 6, 2013

Nov. 6, 2013

Hi all! We're at an exciting point where it's actually possible to do stuff with cryptography. You know what that means... time to start thinking about a release! I'd like us to make a list of the stuff we think should be in our first release. Here's my list: * Figure out our packaging / bundling story with OpenSSL * Finish binding OpenSSL to the point where JP can use it for PyOpenSSL * The last two block ciphers that conch would need (CAST and Blowfish) * Finalizing the iterator APIs for BlockCipher * Padding APIs Here's stuff I'm not sure about: * Everything that conch needs (this means figuring out the API for RSA/DSA) * GCM * CommonCrypto backend What do ya'll think, am I missing anything, do I have to much? As a heads up: once we're ready to do the release and we've frozen a release-candidate I plan to investigate getting it audited. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084

7 12

Bundling OpenSSL
by Donald Stufft Oct. 20, 2013

Oct. 20, 2013

I've started working on bundling OpenSSL within cryptography and fixing the packaging up. There are a number of things I'd like to do that will make things smoother in the long run but require some changes right now. These things are: Disable implicit compile - This masks problems with the packaging. I tried leaving it on when doing the same thing for PyNaCl and it caused immense frustration with strange edge cases breaking. Further more the cffi devs say they are planning on removing it anyways. Move the cryptography directory into a src directory - Since cryptography will require an implicit compile step with the above, it's easy to accidentally import the cryptography that is sitting on the file system that hasn't been compiled yet, moving it means you have to install cryptography somehow to import it (or cd into the src directory). This should lower confusing errors when ``python -c 'import cryptography'`` does work. Further since we'll need a folder for the OpenSSL code it makes sense I think to have a single folder for all the things we have in repo, see: https://github.com/pyca/pynacl/tree/master/src Lazily load the compiled library - Right now the compiled library is loaded when the cryptography.bindings.openssl.api library is imported, this is the way CFFI currently works. As i've done in PyNaCl i'd like to make the Api object lazy so that it loads the compiled library on first access and proxies the calls to the exposed functions/variables to the lazily loaded underlying library object. You can see this at: https://github.com/pyca/pynacl/blob/master/src/nacl/_lib/__init__.py#L59-L84 The final solution to this would be that we have a library that is always built at build time with a consistent version of OpenSSL. Thoughts on these steps? ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

2 3

Bundling OpenSSL
by Zooko Wilcox-OHearn Oct. 8, 2013

Oct. 8, 2013

[in response to https://mail.python.org/pipermail/cryptography-dev/2013-October/000091.html ] > 1 Do we want to bundle a backing library to ensure that there is always a minimal level of support? We've found it necessary to do this in pycryptopp, even though it means we support both the bundled and non-bundled builds. > 2 Do we want to bundle OpenSSL or is there another backing library that we'd want to bundle? (Easier to build, more portable etc?) I personally wouldn't recommend OpenSSL, because its source code is a mess and it has a bad reputation among cryptographers who've looked at it (by which I mean Matt Green). When we faced this decision in 1999, and then when we faced it again in 2006, we chose, both times, Crypto++. This has worked out acceptably well for us, and I'm not eager to move pycryptopp from Crypto++ to anything else, since the current thing is working, and changing it would be a pain, and would introduce risk of bugs/vulns/regressions. I would love to share code, and hard-earned experience, and mutual support between the pyca and pycryptopp projects! So please feel free to copy what we do. If I were starting over again today I would probably choose Botan over Crypto++, because Botan is more actively developed nowadays, and because its primary author and maintainer has provided some Python wrappers. If you are going to go with OpenSSL, you should of course try to benefit from the work that has gone into pyOpenSSL. That includes some work for bundling a copy of the OpenSSL libs into the resulting pyOpenSSL distributions. Regards, Zooko Wilcox-O'Hearn Founder, CEO, and Customer Support Rep https://LeastAuthority.com Freedom matters.

4 3

Bundling OpenSSL
by Donald Stufft Oct. 7, 2013

Oct. 7, 2013

Something that's come up in the terms of Camella, but is going to keep coming up, is that sometimes the OpenSSL on a system is really old (OSX), or neutered (RHEL), or non existent (Windows). In these cases it would be useful to bundle a copy of OpenSSL with cryptography in order to be assured we have a minimal and consistent base to work off of. Bundling does not mean we must always use it, in PyNaCl I've worked my setup.py so that it will detect if it's backing library is available on the system and if the system version is new enough for what I require. There is also the ability to force it to either use or not use the bundled library. Questions: 1 Do we want to bundle a backing library to ensure that there is always a minimal level of support? 2 Do we want to bundle OpenSSL or is there another backing library that we'd want to bundle? (Easier to build, more portable etc?) ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

1 0

Moving to an org
by Alex Gaynor Oct. 5, 2013

Oct. 5, 2013

Hi all, A while ago we discussed moving the repo off my account name, and into a seperate org. We've gone ahead and done that, Donald set up a new pyca (Python Cryptographic Authority) org, the name suggested by Hynek, and endorsed by a few people, in the same vein as PyPA (The Python Packaging Authority). Besides needing to repoint your repos, nothing should change. The pyca org also owns a few other repos: a bcrypt impl, pynacl, and ed25519 (an optimized version of DJB's reference implementation, properly packaged). Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084

2 1

Disabling force push
by Alex Gaynor Oct. 3, 2013

Oct. 3, 2013

Hey all, I've been told that if you request it, you can get GitHub to disable force pushes on a repository. Is that a thing we want to do, it seems like it might be? Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084

3 4

Message Digest Naming / PEP247
by Paul Kehrer Oct. 1, 2013

Oct. 1, 2013

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. 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! -Paul

2 1