Add cipher and AEAD-cipher functions #4
Conversation
|
I do not have any plans to maintain a complete cipher implementation in this project. I consider that to be a huge task that requires a lot of time and effort that I cannot provide. In addition I see no need for it as there are other already available and better implementations and there is no need to duplicate their work. Providing a cryptographic API is full of dangers and pitfalls for the developers using it if not done right. My suggestion would be to use the python-cryptography package (https://cryptography.io/en/latest/). They provide a comprehensive and well documented cryptography API. As an example of what I mean when I say that a cryptography API can be full of dangers and pitfalls, take a look at the documentation of the AEAD based ciphers (https://cryptography.io/en/latest/hazmat/primitives/symmetric-encryption/#cryptography.hazmat.primitives.ciphers.modes.GCM), where you can see not only recommended values for nonce and tag length and values, but also they document the dos and dont's (like the nonce should be unique and you should not reuse a nonce with a given key). Without this kind of documentation and without a clear API, it is very easy for the developers using the API to get a false sense of security, while actually making their application more insecure. |
It's not about maintaining a complete cipher implementation, it's only about wrapping a few existing gnutls functions, which seems reasonable for a project named "python-gnutls".
Given that python-gnutls is merely a binding for gnutls, users of python-gnutls MUST refer to the gnutls documentation when using the python wrapper.
python-cryptography is simply not as complete as the crypto API of gnutls. For example, it does not support CCM mode (and it does not seem planned anyway), while gnutls does.
Once again, python-gnutls is a wrapper to gnutls, so the real documentation is gnutls's one. Wrapping gnutls does not require documentation explaining the dangers of rolling your own crypto protocols. Letting gnutls be the main doc reference seems to be already the approach taken by python-gnutls anyway, given how little documentation there is in in python-gnutls. |
I will not add cryptography support, be that complete or partial into python-gnutls, which has never meant to be a crypto library and will not start being one. python-gnutls was written to allow TLS connections to be made from python with both the client and the server capable of verifying the certificate of the peer, something that none of the SSL implementations at the time python-gnutls was written provided and I'm not sure they have this ability even today.
Python-gnutls is not a binding for gnutls and was never meant to be one. Yes it uses gnutls, but it doesn't try to export it's C API verbatim. At the time of writing it, gnutls didn't expose any crypto API and why they chose to add it later is beyond me considering that libgnutls never claimed to be a crypto library, in fact it uses a crypto library like libgcrypt or nettle for its cryptography needs. As for the gnutls documentation, that only enforces my point. That documentation is completely useless unless you are a cryptography expert. Description of the function arguments simply repeats their names and tells you nothing about their meaning or how they should be used:
Where do they say what a nonce or a tag is, what their content should be or the minimum recommended sizes? Where are the pitfalls described, like never reuse a nonce with a key or don't use tags shorter than 96 bits because it compromises security? Anyway the quality of the gnutls documentation is beside the point here. My resolution remains the same even if that documentation would be impeccable: python-gnutls will not become a crypto library, especially not a partial and obscure one that only experts can use. |
Really? Then you should update the project's README which clearly states
(Emphasis is mine) |
|
Maybe I should, that description is no longer accurate for a while now. At the same time the description is still somewhat accurate as it exposes all the low level types and functions used by the high level interface. In the beginning we used to expose all the low level types and functions, but it proved to be error prone and difficult to maintain as they often fell out of sync and it was hard to guarantee correctness for the ones that were not in use. In the end we decided that it was more practical and safer to only provide the ones that are used (also at the time python-gnutls was written, gnutls was not claiming to do more than TLS connections and didn't expose secondary APIs). |
|
Hi @hydrargyrum -- I wanted to let you know I've forked python-gnutls and included your patches there. The new https://github.com/hughsie/PyGnuTLS is under the same licence as before (LGPLv2+) of course, but it's now Python 3 only. I'm reviewing pull requests so if you are using a private fork with your changes it would be great to merge them back into a common codebase. I'm planning to clean up the fork some more and then submit it to PyPI when API stable. Comments welcome! |
Glad I could help.
Unfortunately, indeed I kept a private fork due to the complete lack of collaboration from this project, but it was tedious so after some time I just completely abandoned using gnutls, less trouble. (I only had changes from this PR though though) Still, that's nice you notified me about this. I see your repository has much less commits than this repository. What approach did you take for your fork? You started from an older point? |
I smashed together all the python-gnutls commits I thought were useful, and rewrote the branch to get rid of any extra files I didn't need. I also black'ened the files on each sub-commit. |
No description provided.