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@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
_______________________________________________
Cryptography-dev mailing list
Cryptography-dev@python.org
https://mail.python.org/mailman/listinfo/cryptography-dev
