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
