Mailman 3 July 2014 - Cryptography-dev

Asymmetric signing primitives
by Ron Frederick July 30, 2014

July 30, 2014

Hello, I recently began looking at adding support for PyCA to my AsyncSSH package (http://asyncssh.timeheart.net). It currently uses PyCrypto, but I see a lot of potential in being able to directly use OpenSSL and other more carefully scrutinized crypto libraries from a security perspective. In the process of adding this support, I ran into an issue with DSA signing and verification. The current implementation in PyCA seems to ASN.1 encode the signature it produces before returning it, while the SSH protocol requires a different encoding to be used of the raw ‘r’ and ’s’ values. I’ve worked around this for now by doing my own ASN.1 code of the return result before re-encoding it in the form SSH needs, but this is somewhat wasteful. I was wondering if it might be possible to provide an option or alternate API which would return the raw r & s values as integers, for protocols that want to use an encoding other than ASN.1. As I worked with these asymmetric key classes, I also noticed a bit of an inconsistency in the API used to access the various raw numbers that go into making up the keys. The current API uses a mixture of method calls and properties, and provides different ways to access some of the values depending on whether you are working with public or private keys. I think it would be good to make this a bit more consistent, at least about method calls vs. properties, but also ideally to provide a common way to access all the values common to public & private keys using the same API, with additional API calls for private keys to access values only applicable there. As an example of what I’m talking about, here are the calls needed to access the parameters of a DSA public key today: p: key.parameters().parameter_numbers().p q: key.parameters().parameter_numbers().q g: key.parameters().parameter_numbers().g y: key.public_numbers().y Note how in one case you can get to the public numbers directly, whereas in the other you have to go through an intermediate object first. It would be nice there to have parameter_numbers() available directly from the key similar to public_numbers(), at least as a convenience function. I would keep the existing parameters() function as well, as it has value to extract the parameters as a group to use in creating other keys. However, allowing access either that way or directly to the numbers object would be nice. For a DSA private key, the first three calls are the same, but the call to get the “y” value is different: y: key.private_numbers().public_numbers.y Also, note here how public_numbers is a property of the object returned by private_numbers(), rather than being a function call the way it is above. Again, it would be nice if private keys had parameter_numbers(), public_numbers(), and private_numbers() calls to expose these values directly, in a way consistent with public keys. The final call to get the private numbers is already consistent with this: x: key.private_numbers().x What I’m suggesting is something that looks more like: p: key.parameter_numbers().p q: key.parameter_numbers().q g: key.parameter_numbers().g y: key.public_numbers().y x: key.private_numbers().x RSA keys have similar issues. The current calls for public keys are: n: key.public_numbers().n e: key.public_numbers().e However, the calls for private keys are: n: key.private_numbers().public_numbers.n e: key.private_numbers().public_numbers.e d: key.private_numbers().d p: key.private_numbers().p q: key.private_numbers().q Having a directly callable public_numbers() function on both the public & private key classes here would be convenient. Finally, if I may, I have one final suggestion. It would be convenient to have the update() function return self (the signer object). That way, it would be possible to write something like: signature = key.signer(PKCS1v15(), SHA1()).update(data).finalize() instead of: signer = self._key.signer(PKCS1v15(), SHA1()) signer.update(data) signature = signer.finalize() in cases where you had only a single block of data to pass in. Thank you for listening, and for all the work that has gone into this package so far! -- Ron Frederick ronf(a)timeheart.net

5 6

Cross compile for OpenWRT/MIPS?
by sam＠samkronick.com July 28, 2014

July 28, 2014

Hi all, I’m trying to get a python library (mitmproxy/libmproxy) running on OpenWRT (https://openwrt.org/) on a router with a MIPS CPU. mitmproxy depends on cryptography, and I’m getting stuck trying to cross-compile cryptography for MIPS using the OpenWRT SDK. I have the cross compiler set up and have cross compiled a few python libraries with c code so I know that works (following http://whatschrisdoing.com/blog/2009/10/16/cross-compiling-python-extension…). The issue I’m having seems to be with cffi— it’s cross-compiling the c code from cryptography, but then it tries to load that and execute it on the build machine which throws a cffi.ffiplatform.VerificationError complaining “wrong ELF class: ELFCLASS32” Of course it can’t run the code that was compiled for another architecture, but is there any way around this? There is no native compiler available for OpenWRT, so cross-compiling seems necessary. Any ideas? Sam

1 0

Domain Name Renewed
by Donald Stufft July 24, 2014

July 24, 2014

Just a FYI that I just renewed the cryptography.io domain name for another year. -- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

1 0

PyCA cryptography 0.5.2 released
by Paul Kehrer July 10, 2014

July 10, 2014

0.5.2 has just been released to PyPI. This is another small bugfix release to handle a compilation error on OS X Mountain Lion (10.8) and add the TraditionalOpenSSLSerializationBackend to MultiBackend. To prevent recurrence of the OS X error the jenkins Mavericks builders are being switched to Mountain Lion. Mavericks will continue to be tested via Travis CI (which switched to Mavericks from ML builders several months ago).

1 0

PyCA cryptography 0.5.1 released
by Paul Kehrer July 8, 2014

July 8, 2014

I’ve just released 0.5.1 to PyPI. This is a small release to address an issue where PKCS8SerializationBackend was not implemented on MultiBackend.

1 0

PyCA cryptography 0.5 released!
by Paul Kehrer July 7, 2014

July 7, 2014

On behalf of all the contributors to PyCA cryptography I’m pleased to announce that version 0.5 has been released and is now available on PyPI. This release encompasses 497 commits from 140 separate pull requests. A few major changes of note: * OpenSSL is now bundled in our Windows wheels to improve the install experience on that platform. * Elliptic curve support was added. * The asymmetric key handling was reworked to allow backend specific key representation. This was done to support a wider variety of backends with varying capabilities in the future. You can see the full changelog here: https://cryptography.io/en/latest/changelog/ Master will be reopening shortly for development on the sixth release.

1 0

GCM tag truncation, backwards compatibility
by Alex Gaynor July 1, 2014

July 1, 2014

Background: Right now when you provide a tag to GCM for decryption/verification, we allow it to be truncated, always. This means that applications that don't want truncation must add their own length checking. Analysis: This is terrible, because it means most applications will silently allow truncation down to a 4-byte MAC (32-bits), which is much easier to brute force to otherwise exploit than the full 16-byte MAC. Proposal: Changing the constructor to disallow truncated MACs by default, and require the user to explicitly opt in to truncation. This is technically backwards-incompatible, but I think it's a good change, because of the enormity of the improvement in security. A patch doing this is here: https://github.com/pyca/cryptography/pull/1201 Feedback please! 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

6 9