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