Hi Glyph,
thanks for chiming in and for the interesting insights from the
implementation side. I wasn't aware of the difficulties involved in
providing the recipient side of OpenPGP. It totally makes sense though.
Personally, I am kind of happy with your recipe short list. The only
thing that is missing for my personal use case is how to encapsulate the
parameters that were used for the key derivation alogirhtm together with
the cipher text so that they can be recovered by the recipient. The only
reason why I suggested OpenPGP is because I assume that the standard
prescribes a way to do that. Is there any chance that you will add steps
for this in the Fernet recipe?
Thanks.
Ben
On 30-Jun-24 20:42, Glyph wrote:
On Jun 30, 2024, at 10:45 AM, Ben Portner via Cryptography-dev
<cryptography-dev@python.org> wrote:
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.
The difficulty of implementing something like PGP is that once PGP is
implemented, there is pressure to actually implement all the parts of it. PGP
is only configurable on the sending side; on the recipient side, you have to
accept whatever terrible cipher suite and weak hashing algorithm that the
sender has selected, or you just have to fail the operation. If the
implementation failed most of the time (as it should, most PGP messages are
malformed in some way), users would be constantly unhappy, generating a huge
support burden for this list.
In other words, it's not really possible to provide a full, interoperable,
correct OpenPGP implementation that is also secure.
I agree that I really want cryptography to include some asymmetric messaging recipes, the short list of
"X509" and "Fernet" is a little anemic, but the engineering effort to construct a
standardized, secure one is a huge challenge beyond the scope of the Cryptography project itself. Sort of
like how Wikipedia has a "no original research" project, because an encyclopedia is already a big
enough project, Cryptography's mandate is to provide high-quality implementations, not to design entire new
protocols.
-g
_______________________________________________
Cryptography-dev mailing list
Cryptography-dev@python.org
https://mail.python.org/mailman/listinfo/cryptography-dev
