3 ms·

>> And pyca/cryptography instead of something terrible like pycryptodome! pycrypto is terrible. The pycryptodome fork fixes most problems in it. Also, maybe w

>> And pyca/cryptography instead of something terrible like pycryptodome! pycrypto is terrible. The pycryptodome fork fixes most problems in it. Also, maybe worth sharing you are listed as fourth contributor [1] to the cryptography library, and your web book is prominent on the project homepage, so this piece of opinion may be biased. >> Concrete suggestion: use Fernet Please don't. Don't use boutique protocols with informal specs and without test vectors generated by a sufficient number of independent implementations. Stick to RFC-backed protocols. Use JWT with rigid parameters. Even other cryptography author states that just supporting JWT and not Fernet would have been better [2]. [1] https://github.com/pyca/cryptography/blob/master/AUTHORS.rst https://github.com/pyca/cryptography/blob/master/AUTHORS.rst [2] https://github.com/pyca/cryptography/issues/2900 https://github.com/pyca/cryptography/issues/2900

lvh 7y ago
I'm not super interested in debating 'zimmerfrei but for everyone else: no, I don't think you should use a library that randomly slaps copyright headers of the fork author on source files [0] and introduces C implementations of MD5 in 2018 [1]. I do think it's ironic that they suggest sticking to RFC'd specs with many competing implementations while defending a project with no mandatory code review, mostly 1 author, and currently failing CI :) [0]: https://github.com/Legrandin/pycryptodome/commit/8675e6f03fc6e12e723467567f3d6d9cd3b0b884 https://github.com/Legrandin/pycryptodome/commit/8675e6f03fc... [1]: https://github.com/Legrandin/pycryptodome/commit/87c2d6aedb3ada1a4729122e4c49441c761680ba https://github.com/Legrandin/pycryptodome/commit/87c2d6aedb3... The number of cryptographers willing to do hours and hours of free, often thankless, open source work is pretty small, so no, I'm also not going to write up a disclaimer every time I tell someone to use a library. Of course I'm going to work on the projects that I think are doing the right thing.

lvh 7y ago

I'm not super interested in debating 'zimmerfrei but for everyone else: no, I don't think you should use a library that randomly slaps copyright headers of the fork author on source files [0] and introduces C implementations of MD5 in 2018 [1]. I do think it's ironic that they suggest sticking to RFC'd specs with many competing implementations while defending a project with no mandatory code review, mostly 1 author, and currently failing CI :) [0]: https://github.com/Legrandin/pycryptodome/commit/8675e6f03fc6e12e723467567f3d6d9cd3b0b884 https://github.com/Legrandin/pycryptodome/commit/8675e6f03fc... [1]: https://github.com/Legrandin/pycryptodome/commit/87c2d6aedb3ada1a4729122e4c49441c761680ba https://github.com/Legrandin/pycryptodome/commit/87c2d6aedb3... The number of cryptographers willing to do hours and hours of free, often thankless, open source work is pretty small, so no, I'm also not going to write up a disclaimer every time I tell someone to use a library. Of course I'm going to work on the projects that I think are doing the right thing.