Hi Ben, Unfortunately OpenPGP is more or less the canonical example of something we would _not_ want to offer as a recipe. Going back to my original criteria:
* It should comprehensively address a common use case: It may do this. * It should reflect current (and anticipated future) best practices: It absolutely does not do this, PGP has been extremely laggard in adopting things like AEADs, and most implementations have indefensible defaults like using CAST5 for encryption. * It should be misuse-resistant: PGP is not misuse resistant, in fact there are legions of papers on how users are incapable of using it correctly. * It should reflect an external standard so that we can interoperate with other libraries and ecosystems: This is true! * It should be parameter-free: PGP has innumerable configuration options and knobs. You've noted that one _library_ offers PGP with a preset options, but this is not the same as the standard and ecosystem as a whole being misuse resistant and parameter free. Alex On Wed, Jun 26, 2024 at 4:41 PM Benjamin W. Portner <webmas...@benjamin-portner.de> wrote: > > Hi Alex, > > Let me try again: How about PGPy's encryption implementation > (https://github.com/SecurityInnovation/PGPy/blob/master/pgpy/pgp.py#L1189)? > It is based on the OpenPGP standard, it can be used without additional > parameters (which prevents misuse), and it addresses a common use case > (message encryption). > > Cheers, > > Ben > > On 25-Jun-24 00:09, Alex Gaynor wrote: > > Mis-use resistant means that it should be impossible (or as close as > > is practicable) for developers to misuse the APIs. Put another way: > > it's never acceptable to say that a system is insecure because a > > developer was holding it wrong. (c.f. > > https://www.wired.com/2010/06/iphone-4-holding-it-wrong/). > > > > In terms of what a standard means: it means there needs to be an > > external reference that other people can use to implement it and > > articulates what the goals are, what the security properties are, and > > how to implement it. https://github.com/C2SP/C2SP is an effort to > > build a community repository of such specifications. > > > > The fact that something is widely used is not, by itself, sufficient > > for us to treat it as a standard. > > > > Alex > > > > On Mon, Jun 24, 2024 at 5:42 PM Ben Portner via Cryptography-dev > > <cryptography-dev@python.org> wrote: > >> Hi Alex, > >> > >> thanks for your swift reply. Let me try to map your conditions to the > >> Ansible implementation: > >> > >> * It should comprehensively address a common use case > >> > >> Check. Use case is encryption of sensitive data, such as passwords, in > >> version control systems. > >> > >> * It should reflect current (and anticipated future) best practices > >> > >> As a cryptography noob I am not sure about this one. Someone else would > >> have to analyze the implementation. > >> > >> * It should be misuse-resistant > >> > >> Not entirely sure what misuse refers to here. It cannot be used by crypto > >> gangs? User errors are minimzed? The latter would be a check. > >> > >> * It should reflect an external standard so that we can interoperate with > >> other libraries and ecosystems > >> > >> Ansible's vault implementation follows no existing standard. However, > >> Ansible is the most widely used config management tool so vault could be > >> called a de-facto standard by transitive properties? > >> > >> * It should be parameter-free > >> > >> Check. > >> > >> > >> It seems that Ansible checks most of the boxes. What do you think? Is this > >> enough to include Ansible's vault implementation in the recipes section? > >> > >> - Ben > >> > >> > >> On 21-Jun-24 16:03, Alex Gaynor wrote: > >> > >> 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 > >> > >> > >> _______________________________________________ > >> 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
