Mailman 3 June 2016 - Cryptography-dev

Fernet NG or alternative simple, high-level, encrypted message module?
by Frank Siebenlist July 20, 2016

July 20, 2016

Hi pyca/cryptography community, We're looking to migrate away from pycrypto - most probably to pyca/cryptography. Pretty sure there will be no objections to that choice on this mailing list. ;-) We also have internally developed libraries for symmetric-key message encryption and such, which we’d love to migrate to some simple, high-level Fernet/KeyCzar-like lib for our developers to use. Our requirements for such a high-level, simple, symmetric-key message encryption library are: — * based on pyca/cryptography * simple interface that hides all low-level crypto, like algo, mode, iv, tag, and their respective sizes ** transparently uses the “correct" defaults for the developers. ** ideally just new_key, encrypt & decrypt functions with opaque tokens ** although implementation could hard-code choices, changes over time should be compatible with already encrypted tokens * make the keys and encrypted messages opaque tokens for developers ** no need to know what’s inside - just move those tokens from Alice to Bob and vice versa. * make both key and encrypted message tokens html&url-friendly ** base64url * token format enables/allows for algo/mode/size policy changes over time ** ideally a change of policy should not affect existing tokens and code ** (I’ve been bitten one time too many by hard-coded message formats…) * key versioning ** not sure yet about the details… ** maybe something like aws-kms: use newest key version by default and transparently decrypt any message encrypted with older versions (?). * key time-to-live ** Fernet has that TTL feature built-in for encrypted messages… but we haven’t seen that requirement yet (encrypted cookie life-time maybe?) * make key-management as transparent as possible ** use key-identifiers (kid) under-the-covers ** all keys should have identifiers ** all encrypted message tokes should include the associated key-identifier ** possible transparently deploy a default kid-key-db — The current Fernet module does not meet a number of those requirements, like the flexibility of transparently changing ciphers or sizes, no key-tokens, and no key-management help. Changing key-sizes or modes (AES256GCM anyone…), would brake the current implementation because the iv, cipher text and tag are essentially byte-concatenated in the token. Looking at the recent standards, an implementation based on jose's json web tokens would give you a lot of primitives to work with: well defined token format, enough meta-data about keys and encrypted messages to ensure the ability to change policies over time, overhead and increased message size acceptable for most (somewhat bigger than concatenating bare-bytes but not as overly verbose as XML-Encryption). Unfortunately, there is no jose library included in pyca/cryptography (yet)… The best jose library based on cryptography that I found seems to be jwcrypto, but its GNU GPL is less friendly (just observation - not a religious statement (I actually contributed to jwcrypto…)). Furthermore, it’s a lot of code to pull-in. We have prototype code that shows that a simple Fernet-style interface based on AES256GCM and jose’s jwt should be feasible. The coding was an exercise to test our requirements and possible token formats - production quality code was not aimed for. Ideally, we would prefer to leverage those kind of crypto libraries from efforts like pyca/cryptography… happy to help or contribute, but we’re very hesitant to take on the support of a crypto library as it’s not core to our business. Questions for the pyca/cryptography community: * Any others who share the need/dream for such a high-level, simple Fernet-style library based on jose/jwt? * Did we possibly miss an existing effort that meets (most of) those requirements? * Comments? Suggestions? Thanks, Frank. "From a security perspective, if you're connected, you're screwed." - Daniel J. Bernstein

3 8

use of poor implementations of algorithms
by Jay Gupta June 30, 2016

June 30, 2016

could you provide concrete examples of your criticism of other Python cryptographic packages, especially about poor algorithm interpretations?

3 2

pyOpenSSL: non-blocking socket support
by Nikolaus Rath June 28, 2016

June 28, 2016

Hello, IIAC, when using the standard library's ssl module, the following can happen (distilled from http://bugs.python.org/issue22499): 1. User calls SSLSocket.send(something) 2. SSLSocket.send raises SSLWantRead (or SSLWantWrite) 3. User calls select() to wait for Read (or write) readyness of the underlying fd. 4. User calls SSLSocket.send(something) again 5. SSLSocket.send raises SSLError If I understand correctly, this is because the ssl module does not actually implement the 'struct iostate' state machinery required by OpenSSL and instead just blindly raises SSLWantRead/SSLWantWrite. Can someone tell me how pyOpenSSL supports non-blocking socket? Does it also require the caller to maintain struct iostate, or does it allow to work with just SSLWantRead/Write and select()? (Background: I'm wondering if switching to pyOpenSSL would be a feasible way to tackle https://bitbucket.org/nikratio/s3ql/issues/87). Thanks, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«

4 9

High-level password hashing module for cryptography?
by Frank Siebenlist June 21, 2016

June 21, 2016

Hi pyca/cryptography community, In my company, we're currently confronted with all the bcrypt vs pbkd2 vs scrypt vs argon discussions and choices. For each there are further choices to be made about salts-sizes, hash-counts, hash-algos... Currently pyca/cryptography only has a PBKDF2HMAC module in the hazmat section, that can be used for password hashing but is presented as a key-derivation algo... which it technically is. I'm looking for a higher, non-hazmat, level password-hashing specific module... Any good libraries available? Ideally based on pyca/cryptography - although the implementation choices seem limited (just PBKDF2 unless I missed some...). I've got some prototype code to see how much we could possibly abstract the interface to deal with passwords. Please look at the example python notebook in this gist: https://gist.github.com/franks42/6edb914203ab7f5a0b151fe0a21e6150 Hopefully that shows some of the interface requirements: * hide low level key-derivation "stuff" from developers * work with opaque html/url-friendly tokens to store in the user-passwd-db * find easy way to manage policy changes and upgrade affected passwordhash-tokens * make "easy" migration to the ultimate future algo feasilble (argon2?) Ideas/suggestions/feedback much appreciated! Thanks, Frank.

3 5

pyOpenSSL CRL chaining
by Ansley Peduru June 15, 2016

June 15, 2016

Hi all, WIth the recent changes made to enable CRL in verify context objects (see here https://github.com/pyca/pyopenssl/pull/483) I would like to know some further functionality. In particular, if this API supports CRL chaining and/or CRL concatenation. Would a CRL need to contain a full chain of issuing intermediate CA's and the issuing root CA? Also when we create an X509Store object we add the certificate in question using add_cert() but when we use it to verify in the X509StoreContext, must we use the same certificate? It seems slightly confusing given the lack of documentation. I am basing most of my assumptions on the unit tests that were merged in. Regards, Ansley

1 0

Python cryptography-1.4 install fails on SLES 10 SP3
by Rob Marshall June 8, 2016

June 8, 2016

Hi, I'm trying to install cryptography-1.4 on SLES 10 SP3 running Python 2.7.8 that I installed from source. I installed: libffi-devel-3.0.11-9.1 libffi6-3.0.11-9.1 openssl-devel-0.9.8a-18.36 openssl-0.9.8a-18.36 When I try to build cryptography I'm getting: creating build/temp.linux-i686-2.7/build/temp.linux-i686-2.7 gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/usr/local/include/python2.7 -c build/temp.linux-i686-2.7/_openssl.c -o build/temp.linux-i686-2.7/build/temp.linux-i686-2.7/_openssl.o build/temp.linux-i686-2.7/_openssl.c: In function ‘_cffi_const_NID_certificate_issuer’: build/temp.linux-i686-2.7/_openssl.c:9048: error: ‘NID_certificate_issuer’ undeclared (first use in this function) build/temp.linux-i686-2.7/_openssl.c:9048: error: (Each undeclared identifier is reported only once build/temp.linux-i686-2.7/_openssl.c:9048: error: for each function it appears in.) build/temp.linux-i686-2.7/_openssl.c: In function ‘_cffi_const_NID_issuing_distribution_point’: build/temp.linux-i686-2.7/_openssl.c:9237: error: ‘NID_issuing_distribution_point’ undeclared (first use in this function) build/temp.linux-i686-2.7/_openssl.c: In function ‘_cffi_const_X509_V_ERR_UNNESTED_RESOURCE’: build/temp.linux-i686-2.7/_openssl.c:11781: error: ‘X509_V_ERR_UNNESTED_RESOURCE’ undeclared (first use in this function) build/temp.linux-i686-2.7/_openssl.c: In function ‘_cffi_d_SSL_CIPHER_description’: build/temp.linux-i686-2.7/_openssl.c:47399: warning: passing argument 1 of ‘SSL_CIPHER_description’ discards qualifiers from pointer target type build/temp.linux-i686-2.7/_openssl.c: In function ‘_cffi_f_SSL_CIPHER_description’: build/temp.linux-i686-2.7/_openssl.c:47450: warning: passing argument 1 of ‘SSL_CIPHER_description’ discards qualifiers from pointer target type error: command 'gcc' failed with exit status 1 Any ideas? Thanks, Rob

3 4

PyCA cryptography 1.4 released
by Paul Kehrer June 4, 2016

June 4, 2016

Courtesy of the PyCon sprints, PyCA cryptography 1.4 has been released to PyPI. 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: * Support for OpenSSL 0.9.8 has been removed. Users on older versions of OpenSSL will need to upgrade. * Added KBKDFHMAC. * Added support for OpenSSH public key serialization. * Added support for SHA-2 in RSA OAEP when using OpenSSL 1.0.2 or greater. * Added "one shot" sign() and verify() APIs to RSA keys. -Paul Kehrer (reaperhulk)

1 0

PyCA cryptography 1.3.4
by Paul Kehrer June 3, 2016

June 3, 2016

PyCA cryptography 1.3.3 has been released to PyPI. 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: * Added another OpenSSL function to the bindings to support an upcoming pyOpenSSL release. -Paul Kehrer (reaperhulk)

1 0

PyCA cryptography 1.3.3 released
by Paul Kehrer June 2, 2016

June 2, 2016

PyCA cryptography 1.3.3 has been released to PyPI. 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: * Added two new OpenSSL functions to the bindings to support an upcoming pyOpenSSL release. -Paul Kehrer (reaperhulk)

1 0

Fernet with AES192/256
by Todd Knarr June 1, 2016

June 1, 2016

Would there be an interest in, or philosophical/design objections to, a patch to allow Fernet to use AES192 and AES256 encryption? I've got a situation where Fernet would be a good fit but 256-bit encryption is highly desired.

3 8