@kushal I'm curious, why you are not just using sequoia's Python library, but implementing a new one (and even in Rust instead of Python). Can you explain your motivation?
@nwalfield

@kirschwipfel

As I understand the Python module for the whole of sequoia will come later. And have a look at the difference between the APIs provided here gitlab.com/sequoia-pgp/sequoia and my examples.

I am using sequoia to build something can be used by normal Python developers without much experience of OpenPGP internals.

@nwalfield

@kushal @kirschwipfel Sequoia provides a low-level, largely policy-free API. This is based on our experience with GnuPG: oftentimes GnuPG's API didn't quite match an application's requirements and that application would have to add 100s of lines of code to get GnuPG to do what it wanted.

@kushal @kirschwipfel We'll add a higher-level API to Sequoia too. But our goal will be to make it and the low-level API complementary. That is, it should be possible to use the higher-level API and tweak it's behavior using the low-level API.

@kushal @kirschwipfel The hard part, however, isn't the encryption and signing. The hard part is authentication. How do you know you are encrypting to the right key? How do you know a signature was created by the person stated in the user ID? If you look at "modern" crypto tools, they largely ignore this issue. It's what makes them so simple. But what's the point of AEAD if the message is encrypted to the wrong recipient?

Sign in to participate in the conversation
dgplug

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!