Mailman 3 January 2016 - Cryptography-dev

accessing elliptic curve domain parameters (a/b/p/etc)
by Matt Bullock March 20, 2016

March 20, 2016

For a project I am working on, I have a need to encode/decode elliptic curve points using point compression[1]. As this is not yet supported natively by the cryptography library, I have started implementing it myself but have hit a snag. Unlike the uncompressed point encoding, in order to decode a compressed curve point I need to be able to reference the curve parameters. I have been searching through the cryptography documentation and code but cannot find any way of retrieving these values from the backend. Is there a method for this that I am missing, or is this functionality not yet available? thanks --Matt [1] 2.3.3/2.3.4 http://www.secg.org/sec1-v2.pdf

2 4

PyCA/cryptography 1.2.2 released
by Paul Kehrer Jan. 29, 2016

Jan. 29, 2016

PyCA/cryptography 1.2.2 has been released to PyPI. This version updates the windows and OS X wheels to be compiled against 1.0.2f and contains no other changes. -Paul Kehrer (reaperhulk)

1 0

Buildroot support
by Mauro Condarelli Jan. 27, 2016

Jan. 27, 2016

Hi, I am trying to port cryptography to a Buildroot-based ARM system. Unfortunately basic cross-compilation fails with the message below. Since I am not a Python programmer and I just need Cryptography as a prerequisite for autobahn I am unable to understand what went wrong. It seems to me compilation is trying to use on Host (x86_64) a shared lib (/home/mcon/emotiq/new/Buildroot/output/target/usr/lib/python2.7/site-packages/_cffi_backend.so) meant to run on Target (ARM). Can someone help, please? Thanks in Advance Mauro (cd /home/mcon/emotiq/new/Buildroot/output/build/python-cryptography-1.2.1//; PATH="/home/mcon/emotiq/new/Buildroot/output/host/bin:/home/mcon/emotiq/new/Buildroot/output/host/sbin:/home/mcon/emotiq/new/Buildroot/output/host/usr/bin:/home/mcon/emotiq/new/Buildroot/output/host/usr/sbin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games" CC="/home/mcon/emotiq/new/Buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-gcc" CFLAGS="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O3 " LDFLAGS="" LDSHARED="/home/mcon/emotiq/new/Buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-gcc -shared" PYTHONPATH="/home/mcon/emotiq/new/Buildroot/output/target/usr/lib/python2.7/sysconfigdata/:/home/mcon/emotiq/new/Buildroot/output/target/usr/lib/python2.7/site-packages/" _python_sysroot=/home/mcon/emotiq/new/Buildroot/output/host/usr/arm-buildroot-linux-gnueabi/sysroot _python_prefix=/usr _python_exec_prefix=/usr /home/mcon/emotiq/new/Buildroot/output/host/usr/bin/python setup.py build --executable=/usr/bin/python ) Installed /home/mcon/emotiq/new/Buildroot/output/build/python-cryptography-1.2.1/.eggs/cffi-1.5.0-py2.7-linux-x86_64.egg Searching for pycparser Reading https://pypi.python.org/simple/pycparser/ Best match: pycparser 2.14 Downloading https://pypi.python.org/packages/source/p/pycparser/pycparser-2.14.tar.gz#m… Processing pycparser-2.14.tar.gz Writing /tmp/easy_install-OMTOyu/pycparser-2.14/setup.cfg Running pycparser-2.14/setup.py -q bdist_egg --dist-dir /tmp/easy_install-OMTOyu/pycparser-2.14/egg-dist-tmp-Oz3sRX warning: no previously-included files matching 'yacctab.*' found under directory 'tests' warning: no previously-included files matching 'lextab.*' found under directory 'tests' warning: no previously-included files matching 'yacctab.*' found under directory 'examples' warning: no previously-included files matching 'lextab.*' found under directory 'examples' zip_safe flag not set; analyzing archive contents... Moving pycparser-2.14-py2.7.egg to /home/mcon/emotiq/new/Buildroot/output/build/python-cryptography-1.2.1/.eggs Installed /home/mcon/emotiq/new/Buildroot/output/build/python-cryptography-1.2.1/.eggs/pycparser-2.14-py2.7.egg Traceback (most recent call last): File "setup.py", line 318, in <module> **keywords_with_side_effects(sys.argv) File "/home/mcon/emotiq/new/Buildroot/output/host/usr/lib/python2.7/distutils/core.py", line 111, in setup _setup_distribution = dist = klass(attrs) File "build/bdist.linux-x86_64/egg/setuptools/dist.py", line 272, in __init__ File "/home/mcon/emotiq/new/Buildroot/output/host/usr/lib/python2.7/distutils/dist.py", line 287, in __init__ self.finalize_options() File "build/bdist.linux-x86_64/egg/setuptools/dist.py", line 327, in finalize_options File "/home/mcon/emotiq/new/Buildroot/output/target/usr/lib/python2.7/site-packages/cffi/setuptools_ext.py", line 161, in cffi_modules add_cffi_module(dist, cffi_module) File "/home/mcon/emotiq/new/Buildroot/output/target/usr/lib/python2.7/site-packages/cffi/setuptools_ext.py", line 48, in add_cffi_module execfile(build_file_name, mod_vars) File "/home/mcon/emotiq/new/Buildroot/output/target/usr/lib/python2.7/site-packages/cffi/setuptools_ext.py", line 24, in execfile exec(code, glob, glob) File "src/_cffi_src/build_openssl.py", line 98, in <module> extra_link_args=extra_link_args(compiler_type()), File "src/_cffi_src/utils.py", line 64, in build_ffi_for_binding extra_link_args=extra_link_args, File "src/_cffi_src/utils.py", line 72, in build_ffi ffi = FFI() File "/home/mcon/emotiq/new/Buildroot/output/target/usr/lib/python2.7/site-packages/cffi/api.py", line 56, in __init__ import _cffi_backend as backend ImportError: /home/mcon/emotiq/new/Buildroot/output/target/usr/lib/python2.7/site-packages/_cffi_backend.so: wrong ELF class: ELFCLASS32 package/pkg-generic.mk:195: recipe for target '/home/mcon/emotiq/new/Buildroot/output/build/python-cryptography-1.2.1/.stamp_built' failed make[1]: *** [/home/mcon/emotiq/new/Buildroot/output/build/python-cryptography-1.2.1/.stamp_built] Error 1

2 1

Re: [Cryptography-dev] Python HSM Module
by Kevin Glisson Jan. 26, 2016

Jan. 26, 2016

I would also be interested in such a library. Cheers, Kevin On Tue, Jan 26, 2016 at 9:35 AM <cryptography-dev-request(a)python.org> wrote: > > Date: Tue, 26 Jan 2016 17:07:51 +0000 > From: "Pitucha, Stanislaw Izaak" <stanislaw.pitucha(a)hpe.com> > To: "cryptography-dev(a)python.org" <cryptography-dev(a)python.org> > Subject: Re: [Cryptography-dev] Python HSM Module > Message-ID: > < > F2CEBDD2D596EC45A4D5479F72C865C504E635BF(a)G1W3786.americas.hpqcorp.net> > > Content-Type: text/plain; charset="utf-8" > > I?m very much interested in a simple HSM interface for Anchor project > (ephemeral certs CA). Feel free to reach out if you?d like more info. > > > > Best Regards, > > Stanis?aw Pitucha > > > > From: Cryptography-dev [mailto:cryptography-dev-bounces+stanislaw.pitucha= > hp.com(a)python.org] On Behalf Of Benton Stark (bestark) > Sent: Wednesday, January 27, 2016 3:29 AM > To: cryptography-dev(a)python.org > Subject: [Cryptography-dev] Python HSM Module > > > > Hello everyone, > > > > I have a HSM (Hardware Security Module) Python library that supports > direct access to HSMs. I developed the library and companion C code for > internal use at my company specially for use with SafeNet HSMs but the > library can work with any PKCS#11 API compliant HSM. I am going through > our internal procedures to get the code open sourced. One of the > requirements before I can do that is collect information on a need or > interest in such a library to the Python community. I am not sure if this > mailer is the right place and if not maybe someone can direct me > elsewhere. I can provide more information if this is indeed the best place > to discuss it. > > > > Thanks, > > > > Benton Stark > >

1 0

Python HSM Module
by Benton Stark (bestark) Jan. 26, 2016

Jan. 26, 2016

Hello everyone, I have a HSM (Hardware Security Module) Python library that supports direct access to HSMs. I developed the library and companion C code for internal use at my company specially for use with SafeNet HSMs but the library can work with any PKCS#11 API compliant HSM. I am going through our internal procedures to get the code open sourced. One of the requirements before I can do that is collect information on a need or interest in such a library to the Python community. I am not sure if this mailer is the right place and if not maybe someone can direct me elsewhere. I can provide more information if this is indeed the best place to discuss it. Thanks, Benton Stark

4 3

[Proposal] Deprecating and removing support for OpenSSL 0.9.8
by Alex Gaynor Jan. 26, 2016

Jan. 26, 2016

Hi all, I'd like to propose we deprecate support for OpenSSL 0.9.8 in our next release, and remove support in the release after (we already emit warnings in our current release, so this is consistent with our schedule). Rationale: OpenSSL 0.9.8 is old, does not support modern web security (e.g. no TLS 1.2), and supporting it adds complexity, in the form of hundreds of additional lines of code and configuration options. Supporting data: As of pip 8 (released this week, already used for something like 1/3 of PyPI downloads), the user agent of pip includes the system's OpenSSL version. Looking at the data (excluding Windows and OS X, since on those platforms we include OpenSSL 1.0.2 in our wheels). The overall distribution is: Indicating that OpenSSL 0.9.8 on Linux repersents less than 1% of all installations. Looking at per-package data, here are the percent of downloads using OpenSSL 0.9.8 for some relevant packages: - unidecode: 7.6% (This is the package with the highest percent of 0.9.8 users) - rsa: 3.3% - pyasn1: 2.2% - requests: 1.6% - pycrypto: 0.8% - pip: 0.6% - pyopenssl: 0.4% - letsencrypt-apache: 0.3% - cryptography: 0.3% I think these numbers are low enough that we can safely drop OpenSSL 0.9.8 support. Platforms specifically known to be affected: - RHEL/CentOS 5 and older - Debian Squeeze (baed on OpenSSL version, this is where most of the affected users will be). Thoughts? Will you be affected by this? 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

5 9

[Proposal] Intent to deprecate and remove: Python 2.6
by Alex Gaynor Jan. 20, 2016

Jan. 20, 2016

Hi all, I'd like to propose we formally deprecate (in our next release) and remove (in the release thereafter) support for Python2.6. It is no longer under support from its developers (which makes it a security risk), its use is more or less confined to users of CentOS and RHEL (which means SCL is available to them, and they have a corporate benefactor to complain to if it doesn't work), and its seriously funking with our development workflow because it's so abysmally slow in CI (which means it's annoying me enough to want to solve this). There is genuinely no justifiable reason to use Python 2.6 anymore, both Django and Twisted have dropped it. If this would _seriously_ impact you, please reply to this thread. If possible I'd also like to hear from our downstreams. Cheers, 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 6

PyCA cryptography 1.2.1 released
by Paul Kehrer Jan. 8, 2016

Jan. 8, 2016

If one birthday release is good, two is surely better? To test that theory PyCA cryptography 1.2.1 has been released. This version, in addition to all the changes outlined in the 1.2 release, contains a fix for an issue that caused pyOpenSSL to raise an exception in many situations (https://cryptography.io/en/latest/changelog/). -Paul Kehrer (reaperhulk)

1 0

PyCA/cryptography 1.2 released
by Paul Kehrer Jan. 8, 2016

Jan. 8, 2016

On behalf of all our contributors I am pleased to announce the release of PyCA/cryptography (https://github.com/pyca/cryptography) version 1.2. cryptography is a package which provides cryptographic recipes and primitives to Python developers. Our goal is for it to be your "cryptographic standard library". We support Python 2.6-2.7, Python 3.3+, and PyPy. Changelog (https://cryptography.io/en/latest/changelog/): * BACKWARDS INCOMPATIBLE: RevokedCertificate extensions now uses extension classes rather than returning raw values inside the Extension value. * Deprecated support for OpenSSL 0.9.8 and 1.0.0. At this time there is no time table for actually dropping support, however we strongly encourage all users to upgrade as those versions no longer receive support from the OpenSSL project. * The Certificate class now has signature and tbs_certificate_bytes attributes. * The CertificateSigningRequest class now has signature and tbs_certrequest_bytes attributes. * The CertificateRevocationList class now has signature and tbs_certlist_bytes attributes. * NameConstraints are now supported in the CertificateBuilder and CertificateSigningRequestBuilder. * Support serialization of certificate revocation lists using the public_bytes() method of CertificateRevocationList. * Add support for parsing CertificateRevocationList extensions() in the OpenSSL backend. * Added CertificateRevocationListBuilder and RevokedCertificateBuilder to allow creation of CRLs. * Unrecognized non-critical X.509 extensions are now parsed into an UnrecognizedExtension object. ...and various other improvements. Please see the website changelog for documentation and additional details. -Paul Kehrer (reaperhulk)

1 0

Re: [Cryptography-dev] Keys/Certificates/CRLs/x509 in pyOpenSSL
by Dominic Chen Jan. 6, 2016

Jan. 6, 2016

To add on to the existing discussion, I agree with deprecating cryptography in favor of pyopenssl, although personally I’d prefer to see pyopenssl continue providing an updated low-level OpenSSL interface. As a bit of background, I originally started using pyopenssl when I was writing a research tool to parse a bunch of cryptography-related file formats (e.g. PEM/DER encoded X509, PKCS12, PKCS7, etc), and dump them into a SQL database for easy searching and filtering. I settled on pyopenssl after trying a number of other Python cryptography libraries, and discovering that they lacked support for features like elliptic curve cryptography, all of PCKS7/12, etc. But after discovering that pyopenssl was somewhat deprecated in favor of cryptography, I ended up switching to cryptography, since it appeared to better maintained, and I believe I encountered some bugs. However, I was annoyed to find out that cryptography only provided a higher-level interface, and there was a lack of feature parity between the two projects. This was a couple of months ago, so I don’t remember the exact details, but I recall that at the time, there was limited CRL parsing support, no parsing of unsupported OID’s in certificates, and no support for PKCS7. Additionally, the checks for standards compliance were frustrating to deal with, because I was only interested in parsing and dumping a bunch of certificates, not whether they were standards compliant, or whether the library would pars known OID’s into objects. Additionally, I also encountered some more bugs as well, which I believe are now fixed. As a result, I ended up implementing my own wrapper interface around both libraries. Thanks, Dominic Chen

3 2