Hi Ben, We are interested in having more cryptographic recipes, however we have a number of things we want from a recipe:
* It should comprehensively address a common use case * It should reflect current (and anticipated future) best practices * It should be misuse-resistant * It should reflect an external standard so that we can interoperate with other libraries and ecosystems * It should be parameter-free Unfortunately there's been a real dearth of standardization of these types of recipes in the cryptographic world. I continue to hope that more will come into existence, and we'll add support for them though! Alex On Fri, Jun 21, 2024 at 9:56 AM Ben Portner via Cryptography-dev <cryptography-dev@python.org> wrote: > > Dear Cryptography Developers, > > First off, thank you for developing the Cryptography package! The Python > developer community is growing and robust cryptography is desperately needed > to have a safe fundament to build on. > > TL;DR: Are more cryptographic recipes (AES256, KDF incl. parameter storage) > going to come soon? > > In your package description you write that "cryptography is a package which > provides cryptographic recipes and primitives". As a developer and > cryptography noob, I am especially interested in the recipes. In your docs, > there are code snippets for the Fernet algorithm, which are very helpful. I > am wondering if you are planning to expand this section in the near future. > For example, I would be interested in learning how to store the key > derviation parameters (salt, length, rounds) with the encrypted cipher text > to facilitate decryption later on. Also, a version with 256 bit keys would be > interesting. I believe that such a "reference implementation" would also > benefit other developers. Ansible already uses Cryptography for its vault > implementation, however with "only" 10k rounds for the KDF. As a cryptography > noob, I am not sure if this is safe enough for my application (archive > encryption for offsite backups). Having a "first hand" implementation with > safe defaults would help to reduce developer uncertainty and also prevent us > from "reinventing the wheel". > > Thanks again and best regards. > > Ben > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev@python.org > https://mail.python.org/mailman/listinfo/cryptography-dev -- All that is necessary for evil to succeed is for good people to do nothing. _______________________________________________ Cryptography-dev mailing list Cryptography-dev@python.org https://mail.python.org/mailman/listinfo/cryptography-dev
