3 ms·
Sequoia is an implementation of OpenPGP, i.e. RFC 4880. It also supports a few non-standard extensions to OpenPGP, e.g. ECDSA and EdDSA signatures, better strea
by woodruffw 3y ago
Sequoia is an implementation of OpenPGP, i.e. RFC 4880. It also supports a few non-standard extensions to OpenPGP, e.g. ECDSA and EdDSA signatures, better stream ciphers than CAST5, etc.
I think a legitimate selling point of Sequoia is simplicity: it's a new implementation, written in a memory-safe language[1], and it can make better (but still not optimal) default decisions.
At the same time, I don't think Sequoia succeeds in avoiding PGP's baggage or drawbacks: PGP is defined by its baggage, and any greenfield implementation that avoids that baggage is intentionally breaking compatibility with the thing it's meant to be compatible with.
It's unclear to me (personally) what the value proposition for Sequoia is meant to be, given that it's shackled to the past and can't do better on basic things like certificate malleability. If the goal is for it to be something better, I think it'd be best to cut the losses and start from stronger (and more modern) foundations.
[1]: Except that they've chosen to use Nettle for the cryptographic components, meaning that there's still a good chunk of C under the hood.
- WesolyKubeczek 3y ago> PGP is defined by its baggage, and any greenfield implementation that avoids that baggage is intentionally breaking compatibility with the thing it's meant to be compatible with. Is there a way in PGP to say "I won't talk to you if you have a weak key, or use ciphers that are not one of <some reasonable list of modern ciphers>"? Like you have in TLS, SSH, and IKE handshakes?
- SAI_Peregrinus 3y agoNot and be compatible with the OpenPGP spec. You can define a safe subset of OpenPGP with some additional restrictions (like no weak keys) but that won't be PGP any more, it'll be a new protocol.
- Avamander 3y agoTechnically true and it would certainly avoid a bunch of confusion if the new subset carries a new name. However there are a bunch of "OpenPGP" implementations out there but when you start comparing them, it's obvious that they differ quite a bit.
- giantrobot 3y agoPGP doesn't use handshakes because it's mostly used for offline communication.
- WesolyKubeczek 3y agoThen the tool could issue warnings much like the browsers do if the certificate is crap. And/or refuse to work with weak keys for new documents.
- woodruffw 3y agoWarnings are unfortunately worthless without enforcement, much less adequate presentation. GPG doesn't even bother to prominently warn the user when a key is expired: they tuck the message below the "verification succeeded" message, which is the exact opposite of what they should be presenting.
- WesolyKubeczek 3y agoIf the key was valid back when the message had been signed, and the key wasn't revoked later, what's wrong with verification having succeeded?
- woodruffw 3y agoAs the original analysis notes: many of the keys weren't valid at message signing time.
- giantrobot 3y agoI think you misunderstand how PGP works. There's no real-time interaction between participants. Participants don't have certificates, only keys. The ciphers and signing algorithms are determined by the OpenPGP spec rather than some negotiation between parties. The trust model in PGP isn't a certificate with a signing chain but a "web of trust". I know Alice and Alive knows Bob. Alice vouches for Bob by signing his key and giving it to me. Since I trust Alice personally I have some level of trust in Bob.
- thayne 3y agoI think the use is to have a better implementation that works in cases where you need compatibility with PGP, because lots of stuff still uses PGP.