[Cryptography-dev] Cryptographic recipes

[Ben Portner]

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 26-Jun-24 22:41, Benjamin W. Portner 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
>>
>>