[Cryptography-dev] Cryptographic recipes

[Ben Portner]

Hi Alex,

Maybe I don't get what pyca is intending to be. When I read this:

 >PGP is not misuse resistant, in fact there are legions of papers on 
how users are incapable of using it correctly. [...] PGP has innumerable 
configuration options and knobs.

I am thinking: Isn't this exactly where you come in and show *the one* 
configuration of the options and knobs that is safe to use? I mean, you 
are spelling it out right there. Many people (me included) have no idea 
what they are doing when they implement encryption themselves. That is 
the reason why cybersecurity and privacy are a mess in most tools and 
services today. But what choice do devs like me have when there are no 
tested free and open source recipes out there that we can use? I thought 
this is exactly the problem that pyca is trying to solve.

Ben

On 26-Jun-24 23:54, Alex Gaynor wrote:
> 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
> <webmaster at 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 at 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 at 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 at python.org
>>>> https://mail.python.org/mailman/listinfo/cryptography-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> Cryptography-dev mailing list
>>>> Cryptography-dev at python.org
>>>> https://mail.python.org/mailman/listinfo/cryptography-dev
>>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/cryptography-dev/attachments/20240630/7abb93fc/attachment.html>