> 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
