Initial commit. Migrates over basic project files, and the OpenSSL bindings #1
Conversation
|
I've been meaning to bring this up on the mailing list, but I'd really like for the fact that we are using OpenSSL as the backing library to be an implementation detail (and thus the c bindings be private api) with a low level wrapper around them. What that means, if that is agreed upon, is that it probably makes sense for the C API to be called |
|
I hate naming modules with an underscore prefix. I think not documenting |
|
Sounds reasonable enough, we should probably at least include the fact it's a private API in the docstring for |
|
Sounds good, maybe include a note in teh docs as well. Seems orthagonal to this PR though? |
|
I have two naive questions:
Additionally, cryptography lacks an |
As I mentioned on the mailing list, my interest in this project is as a replacement for the C code in pyOpenSSL. If this project isn't going to give me bindings to the OpenSSL C API, then I'll probably excuse myself from contributing. I am far too overcommitted already, and this project was supposed to save me work, not create a whole new world of it. |
|
@hynek Addressed the commented out code. I apparently failed to add the .travis.yml, I'll add a new PR for it. |
|
I've significantly streamlined this patch, it's now only some scaffolding, I removed all the C headers, we should add those back as needed. |
|
|
||
| setup( | ||
| name="cryptography", | ||
| license="Apache License, Verison 2.0", |
There was a problem hiding this comment.
still saying “Verison” instead of “Version”
|
Could you still please add some kind of test that shows that the code does what it should? Working imports on all Python versions would be a start. That would have also caught the missing |
|
Ok, even less now, we can add back pieces with tests. |
|
Time to write some code. |
These are implemented such that they don't depend on the backend. This means we don't have to worry about passing an RSA key created with one backend to a different one so much at the expense of having to create a backend specific context on demand. This is slightly non-trivial in (at least) OpenSSL as there are 3 additional derived parameters kept in its RSA struct. They aren't difficult to generate but it requires adding 30-40 lines of BN_* stuff to the backend so I'm leaving that out for now. We'll need to implement that before we can actually do any useful operations with the keys. This also adds a loader for some of the PKCS pyca#1 test vectors. It only extracts the 10 key pairs from pss_vect.txt currently be should be extenable to include the example signatures and other files later.
PKCS #1 RSA test vector loader
These are implemented such that they don't depend on the backend. This means we don't have to worry about passing an RSA key created with one backend to a different one so much at the expense of having to create a backend specific context on demand. This is slightly non-trivial in (at least) OpenSSL as there are 3 additional derived parameters kept in its RSA struct. They aren't difficult to generate but it requires adding 30-40 lines of BN_* stuff to the backend so I'm leaving that out for now. We'll need to implement that before we can actually do any useful operations with the keys. This also adds a loader for some of the PKCS pyca#1 test vectors. It only extracts the 10 key pairs from pss_vect.txt currently be should be extenable to include the example signatures and other files later.
* master: PKCS #1 RSA test vector loader Removed pointless anchor Docs need virtualenv as well Everything about bash is the worst Some reST markup nonsense Fix for OS X More clearly describe the behavior of constant_time.bytes_eq Run the doc tests under OS X Made OpenSSL's derive_pbkdf2_hmac raise the right exception Document which backends implement which itnerfaces. Fixes #538 pep8 Fixed a typo in the docs Make the default backend be a multi-backend Conflicts: tests/hazmat/backends/test_openssl.py
Adds SSL_renegotiate binding
Github changes
In 2005, IETF devised a more secure padding scheme to replace PKCS pyca#1 v1.5. To make sure that nobody can properly support or use it, they mandated lots of complicated parameters in the certificate, unlike any other X.509 signature scheme. https://tools.ietf.org/html/rfc4056 `_SIG_OIDS_TO_HASH` and `Certificate.signature_hash_algorithm` cannot be supported as-is, because the hash algorithm is defined in the signature algorithm parameters, not by the OID itself.
In 2005, IETF devised a more secure padding scheme to replace PKCS pyca#1 v1.5. To make sure that nobody can easily support or use it, they mandated lots of complicated parameters in the certificate, unlike any other X.509 signature scheme. https://tools.ietf.org/html/rfc4056 `_SIG_OIDS_TO_HASH` and `Certificate.signature_hash_algorithm` cannot be supported as-is, because the hash algorithm is defined in the signature algorithm parameters, not by the OID itself.
In 2005, IETF devised a more secure padding scheme to replace PKCS pyca#1 v1.5. To make sure that nobody can easily support or use it, they mandated lots of complicated parameters in the certificate, unlike any other X.509 signature scheme. https://tools.ietf.org/html/rfc4055 `_SIG_OIDS_TO_HASH` and `Certificate.signature_hash_algorithm` cannot be supported as-is, because the hash algorithm is defined in the signature algorithm parameters, not by the OID itself.
In 2005, IETF devised a more secure padding scheme to replace PKCS #1 v1.5. To make sure that nobody can easily support or use it, they mandated lots of complicated parameters in the certificate, unlike any other X.509 signature scheme. https://tools.ietf.org/html/rfc4055 `_SIG_OIDS_TO_HASH` and `Certificate.signature_hash_algorithm` cannot be supported as-is, because the hash algorithm is defined in the signature algorithm parameters, not by the OID itself.
In 2005, IETF devised a more secure padding scheme to replace PKCS pyca#1 v1.5. To make sure that nobody can easily support or use it, they mandated lots of complicated parameters in the certificate, unlike any other X.509 signature scheme. https://tools.ietf.org/html/rfc4055 `_SIG_OIDS_TO_HASH` and `Certificate.signature_hash_algorithm` cannot be supported as-is, because the hash algorithm is defined in the signature algorithm parameters, not by the OID itself.
No description provided.