Mailman 3 February 2014 - Cryptography-dev

Loading RSA Certifcates
by Abhishek Ram Feb. 24, 2014

Feb. 24, 2014

Hi Team, I am building an AS2 lib in python and I want to use your library for encryption and signing. I have tried various other libraries and they do not satisfy my requirement. I have gone through your documentation and found the necessity algorithms for signing and encryption, however the problem I am facing is that I don't see a way to load RSA keys in your library. Is there a way that I can load RSA public and private keys? Regards Abhishek Ram

3 2

[ANN] pyOpenSSL 0.14
by exarkun＠twistedmatrix.com Feb. 23, 2014

Feb. 23, 2014

Greetings fellow Pythoneers, I'm happy to announce that pyOpenSSL 0.14 is now available. pyOpenSSL is a set of Python bindings for OpenSSL. It includes some low-level cryptography APIs but is primarily focused on providing an API for using the TLS protocol from Python. Check out the PyPI page (<https://pypi.python.org/pypi/pyOpenSSL>) for downloads. This release of pyOpenSSL adds: * Support for TLSv1.1 and TLSv1.2 * First-class support for PyPy * New flags, such as MODE_RELEASE_BUFFERS and OP_NO_COMPRESSION * Some APIs to access to the SSL session cache * A variety of bug fixes for error handling cases Additionally, there are three major changes to the project: First, the documentation has been converted from LaTeX (CPython's previous documentation system) to Sphinx (CPython's "new" documentation system ;). You can find the new documentation on the PyPI documentation site (<https://pythonhosted.org/pyOpenSSL/>) or <https://pyopenssl.readthedocs.org/>). Second, pyOpenSSL is no longer implemented in C as a collection of extension modules using the Python/C API. Instead, pyOpenSSL is now a pure-Python project with a dependency on a new project, cryptography (<https://github.com/pyca/cryptography>), which provides (among other things) a cffi-based interface to OpenSSL. This change means that pyOpenSSL development is now more accessible to Python programmers with little or no experience with C. This is also how pyOpenSSL is now able to support PyPy. Finally, the project's code hosting has moved from Launchpad to Github. Many branches remain only on Launchpad along with their associated bug reports. Over the coming releases I hope that the fixes and features in these branches will be ported to Python and incorporated into the pyOpenSSL master development branch. Bug tracking has been disabled on Launchpad so that the amount of useful information hosted there can gradually dwindle to nothing. Please use Github (<https://github.com/pyca/pyopenssl>) for further development and bug reporting. Thanks and enjoy, Jean-Paul

1 0

Cryptography_add_osrandom_engine failure?
by Jean-Paul Calderone Feb. 22, 2014

Feb. 22, 2014

Hi all, Does anyone know why cryptography.hazmat.bindings.openssl.binding.Binding has started to start failing on assert res == 1? This seems to indicate that Cryptography_add_osrandom_engine is failing. pyOpenSSL test suite on travis-ci has started failing because of this. For example, https://travis-ci.org/pyca/pyopenssl/jobs/19393936 Jean-Paul

3 6

Building on Windows 7, 64x
by Khalid [KAB] Feb. 21, 2014

Feb. 21, 2014

Hello all. I sent this sometime ago, but I don't know why it is not showing in the mail archives. Seeing the discussion about building on Windows, I am re-sending this, maybe it helps someone. Congratulations on the first release. Given the nature of the package, I opted to build everything from source. I started with openssl-1.0.0l and once that was built and installed, I set the include and lib environment variables for cryptography's build process to use. It turns out, however, that the openssl build creates two libraries: libeay32.lib and ssleay32.lib. This of course cause the build process of cryptography to fail since it cannot find crypto.lib and ssl.lib. But since I've come to know that libeay32.lib is crypto.lib and likewise ssleay32.lib is ssl.lib, I copied the original libraries (libeay32.lib and ssleay32.lib) to the same directory they were installed in by the openssl installation process and renamed them crypto.lib and ssl.lib respectively. This made cryptography's build complete successfully and the package was installed without problems. Here is the summary output of py.test: =================================== ERRORS ==================================== ____________________ ERROR collecting tests/test_fernet.py ____________________ tests\test_fernet.py:40: in <module> > class TestFernet(object): tests\test_fernet.py:42: in TestFernet > ("secret", "now", "iv", "src", "token"), "generate.json", tests\test_fernet.py:32: in json_parametrize > with open(path) as f: E IOError: [Errno 2] No such file or directory: 'J:\\projs\\cryptograp hy-0.1\\tests\\vectors\\fernet\\generate.json' =========== 15473 passed, 47261 skipped, 1 error in 291.69 seconds ============ I hope someone will find this useful. Khalid

2 1

Building cryptography on Windows for Python 3.3
by Alexander Belchenko Feb. 21, 2014

Feb. 21, 2014

Hi, I started to write an email with request for help building cryptography on Windows for Python 3.3, but then I figured out how to get the desired result, so now I only want to share some knowledge and also provide you a build log in the case you're interested in compiler warnings. Also I'd like to know it built correctly, is there any easy-to-use unittest suite I can run? I see there tests package, but I'm not sure what is your method to run tests in your project? Obvioulsly `python3 -m unittest` does not work. My intent was to build cryptography library against static libs of OpenSSL because I had problems with running simple C code with OpenSSL dlls, I found on StackOverflow suggestion that only linking against static libraries would help. It does help for me. Here is openssl directories I've used: include: C:\OpenSSL-Win32\include lib: C:\OpenSSL-Win32\lib\VC\static My C code successfully linked against this set of libraries: 'libeay32MD', 'ssleay32MD', 'gdi32', 'user32', 'advapi32' So here is my steps similar to what you wrote on Installation page: https://cryptography.io/en/latest/installation/#on-windows "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86 set LIB=C:\OpenSSL-Win32\lib\VC\static;%LIB% set INCLUDE=C:\OpenSSL-Win32\include;%INCLUDE% C:\Python33\python setup.py install That wasn't enough because of set of libraries you need to link against. So I just changed settings in bindings.py: === modified file cryptography/hazmat/bindings/openssl/binding.py --- cryptography/hazmat/bindings/openssl/binding.py 2014-02-18 13:18:03 +0000 +++ cryptography/hazmat/bindings/openssl/binding.py 2014-02-18 13:54:26 +0000 @@ -92,7 +92,9 @@ if sys.platform != "win32": libraries = ["crypto", "ssl"] else: # pragma: no cover - libraries = ["libeay32", "ssleay32", "advapi32"] + libraries = ["libeay32MD", "ssleay32MD", + "gdi32", "user32", "advapi32", + "Ws2_32", "Crypt32"] cls.ffi, cls.lib = build_ffi(cls._module_prefix, cls._modules, _OSX_PRE_INCLUDE, _OSX_POST_INCLUDE, With the last change I was finally able to build cryptography python library. \o/ Attached is the build log in the case you want to see compiler errors. Some warnings catched my eye, like this: cryptography\hazmat\primitives\__pycache__\_cffi__xcd368b2dx4a8b9ec1.c(218) : warning C4244: '=' : conversion from 'unsigned __int64' to 'uint8_t', possible loss of data or cryptography\hazmat\bindings\__pycache__\_cffi__xabccc2b1x4bab9030.c(4386) : warning C4308: negative integral constant converted to unsigned type Probably you might know that everything is OK, I just wanted to test somehow my build is OK. Alexander.

4 7

0.2 release
by Alex Gaynor Feb. 19, 2014

Feb. 19, 2014

Hi all, Unless there's any objection, it's my plan to do the 0.2 release tomorrow. This means that it looks like most of the RSA stuff will not land in time for the release. That's ok though, release early release often! My primary goal for this release is that pyOpenSSL's release will have everything it needs in the way of bindings and platform support and that we can get Windows wheels up. Given that, let's try to avoid landing any major things in the next day :-) 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

DSA
by skeuomorf Feb. 19, 2014

Feb. 19, 2014

Concerning issue #230 "Add DSA", DSA has the following parameters: p: prime modulus of bit length L q: prime divisor of (p-1) of bit length N g: a generator of a subgroup of order q in the multiplicative group GF(P) where 1<g<p x: private key, random where 0<x<q y: public key (y = (g^x) mod p) k: per message random number (nonce) where 0<k<q /domain_parameter_seed/ and /counter/ used in generation of p,q _*A typical work flow would involve:*_ * Domain parameter generation (and validation) (p,q,g) * Key pair generation (and validation) (x, y) * Signature generation (and verification and validation) (k, r, z) _*Signature process(r,z,s)*_ r = ((g^k) mod p) mod q z = The leftmost min(N, outlen) bits of Hash(M) where outlen is the bit length of the hash function output block. s = (k^-1 (z + xr)) mod q *_The case of OpenSSL 0.9.8_* * Uses SHA-1 as its hash function * Maximum seed length of 160 bits when generating parameters * Skimming the source code, I found that it has a FIPS directory but upon further examination I discovered that it isn't different from the normal DSA implementation in the crypto/dsa directory (Please double check) * Needs further examination... _*The case of OpenSSL 1.0.2-stable*_ * Supposedly has a FIPS module that's referred to throughout the code yet it's not implemented "/* Workaround bug in prototype */" maybe I misunderstood? * Needs further examination... (What's the hash function used?...etc) *_ Notes:_* * FIPS 186-4 lists recommends (L,N) pairs -in bits- (1024, 160), (2048, 224), (2048, 256), (3072, 256) * The security strengths for (L,N) pairs is listed in SP 800-57 * The Hash function should have a strength >= strength(L,N) * Length of digital signature is 2q * Private signature key has a cryptoperiod of 1-3 years * "The security strength associated with the DSA digital signature process is no greater than the minimum of the security strength of the (L,N) pair and the security strength of the hash function that is employed." * "The same domain parameters (p, q, g) may be used for both digital signatures and key establishment. However, using different values for the generator g reduces the risk that key pairs generated for one purpose could be accidentally used (successfully) for another purpose." * A calculation of the inverse of k is required i.e. k^(-1) * (k, r, p, q, g) maybe pre computed What do you guys think cryptography's API should expose? Support for 0.9.8's validation process is non-negotiable as a user might validate a signature that was generated using the old standard. Should the users be allowed to generate the domain parameters? and the nonce? and store the private key and the nonce if it was precomputed?...etc

1 0

RSA key generation -- minimum key size?
by Alex Gaynor Feb. 11, 2014

Feb. 11, 2014

Hey all, The last major issue blocking landing RSA key generation is a discussion over whether or not to enforce a minimum key size for newly generated keys. I am advocating for requiring that key_size be >= 1024. Here is why: * Smaller keys are factorable (768 is known to be factored publicly, it's extremely likely even larger is factorable by nation states); there is basically no reason to use these keys. * PyCrypto enforces a 1024 minimum, which means there is no difficulty in porting applications; as there would be if we used a larger minimum * Loosening the check in the future is much easier, from a backwards compatibility perspective, then tightening it. Thus, 1024 seems like a reasonable balance of these concerns. How do other people feel? 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

9 8

HOTP/TOTP in Cryptography
by Paul Kehrer Feb. 9, 2014

Feb. 9, 2014

In short: do we want to add HOTP/TOTP support to cryptography? An issue was filed last night by a developer who would like to add HOTP/TOTP support to the project (tracking issue: https://github.com/pyca/cryptography/issues/588). This led to a discussion in IRC this morning where Donald raised some concerns about what criteria we should have for adding/maintaining constructions under our umbrella (see the link above for his full thoughts). I would argue that HOTP/TOTP meet the threshold (whatever it is) of noteworthiness for inclusion in the project because they are well-defined, simple protocols that won’t be a maintenance burden and benefit from being inside a well-tested (and trusted?) library. They are also in common use, so we don’t have to be concerned about including code no one would ever use. The counterargument is well summarized by Donald: "As far as I know HOTP/TOTP do not need anything backend specific and can be completely implemented using the standard library's hashlib. Is there a benefit to using our backends? Is there anything that we'd want to use the backends for at all? (Storing secrets in a HSM?).” Opinions welcome. :) -Paul

1 0

Starting to think about release 0.2
by Alex Gaynor Feb. 4, 2014

Feb. 4, 2014

Hey all, David has conned me into volunteering to do our 0.2 release. Here are the things I see as high priority for this release: * RSA/DSA primitive APIs * New random engine for OpenSSL * Re-adding CAST5 * Making our release process include building wheels My hope is that this is about 1-2 weeks of work, but we'll see, the scope of the assymetric work is a bit variable depending on format loading and passwords and such, so we'll see. If you think someone is missing from this, please mention it, and if you can add it to the 0.2 milestone on github. 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