
Towards Sequoia OpenPGP v1.0 - nwalfield
https://sequoia-pgp.org/blog/2020/04/26/202004-towards-sequoia-v1.0/
======
qqii
Having an alternative implementation to GnuPG is a pretty important. Although
many would argue against the use of PGP encryption for many use cases such as
email, there are other use cases where PGP's ideas have no replacement.

For a specific example take signing git commits. Even fossil scm delegates
this task to pgp. Personally keybase is the only project that may provide some
form of alternative, but they do so by supporting pgp.

I definitely agree that PGP was and is no longer the correct tool for every
use case as it sort out to be, but I find there are still pockets where PGP
has no alternative. I'd be interested what HN's thoughts are on PGP for this
specific use case and if there could be an alternative.

~~~
nickray
First, that's a limitation of git.

Second, it's easy to fake PGP: [https://boats.gitlab.io/blog/post/signing-
commits-without-gp...](https://boats.gitlab.io/blog/post/signing-commits-
without-gpg/)

Third, we're adding support to SoloKeys to do this using a hardware token:
[https://github.com/solokeys/solo/issues/395#issuecomment-612...](https://github.com/solokeys/solo/issues/395#issuecomment-612059329)

We're also collaborating with [https://keys.pub/](https://keys.pub/) to make
"sign/verify" use cases easily usable with a GUI for everyone. So I'd say
there's hope?

~~~
jeltz
Your linked post is not about faking PGP, it is about replacing PGP with his
own implementation which supports only a subset of the PGP standard, the
subset necessary to properly sign git commits.

------
superdug
I still use PGP to encrypt files with secrets in them that I am sending to a
known source, and I know it's still the base encryption for a few well known
file servers. A new player in the market is welcomed.

~~~
nickray
Keybase's "Crypto tools" tab can do this, with "known destination" determined
via social proof.

[https://keys.pub](https://keys.pub) is a re-implementation of this use case
without the messenger/cryptocurrency baggage that some dislike about Keybase.

------
jolmg
Here's the command line documentation:

[https://docs.sequoia-pgp.org/sq/index.html](https://docs.sequoia-
pgp.org/sq/index.html)

I have to admit that it looks more digestible than gpg's. It seems it's still
missing a way to manage OpenPGP smartcards like Yubikeys. Also, I can't see a
way to manage an arbitrary set of subkeys for a given primary key.

I'm really happy to see an alternative to GnuPG, though. This looks promising.

------
saurik
As someone who has been trying to use this library but haven't had the time to
finish build integration to cross compile for all of my target platforms, I
really wish it weren't using nettle, particularly as it is _also_ using
openssl :(. Does rust not have useful cryptography libraries yet? Or couldn't
it _just_ openssl?

------
longtermd
Off topic af: what does the picture on their landing page symbolize?
[https://sequoia-pgp.org/](https://sequoia-pgp.org/)

~~~
qqii
[https://wellcomecollection.org/works/s8yb9bt9](https://wellcomecollection.org/works/s8yb9bt9)

------
pgt
Note that this project is unrelated to Sequoia Capital.

~~~
DyslexicAtheist
note that Sequoia Capital is totally unrelated to the Indian silversmith and
inventor of the Cherokee syllabary

------
mratsim
What's the threat model?

I've looked into the code. It uses Nettle's Curve25519 which seems to be
implemented constant-time (assuming ECC mul is using "ecc-mul-g" from which is
protected against cache timing attacks because the other ecc-mul
implementations are using raw table access.)

------
cpach
IMO, encrypted e-mail is a dead end. Latacora has a good blog post about it
that I highly recommend: [https://latacora.micro.blog/2020/02/19/stop-using-
encrypted....](https://latacora.micro.blog/2020/02/19/stop-using-
encrypted.html)

~~~
dr_hooo
Hmm, I don't really see any really convincing points, or workable alternatives
that your linked article provides.

Nevertheless I would like to read more about this claim:

> It [PGP] was designed in the 1990s, and in the 20 years since it became
> popular, cryptography has advanced in ways that PGP has not kept up with.
> So, for example, it recently turned out to be possible for eavesdroppers to
> decrypt messages without a key, simply by tampering with encrypted messages.
> Most technologists who work with PGP don’t understand it at a low enough
> level to see what’s wrong with it.

(I admit I am one of these technologists)

~~~
upofadown
My best guess is that they really meant EFAIL but didn't want to actually
mention it because EFAIL had nothing to do with any weakness in the OpenPGP
standard or the GnuPG implementation. Instead it was a HTML email horror story
where someone figured out how to forward entire decrypted messages using image
links.

So just more pointless anti-PGP innuendo...

~~~
tptacek
That is not in fact a good description of EFail, which was indeed caused by a
failure both of the PGP protocol and of GPG, its reference implementation.

~~~
upofadown
>...a failure both of the PGP protocol ...

No. There were some changes in the actual protocol document that came out of
EFAIL but no actual changes to the protocol other than a depreciation that was
happening anyway.

>...and of GPG, ...

This also seems to be false. GPG didn't have to change anything as the result
of EFAIL...

>...its reference implementation.

Also false. OpenPGP does not have a reference implementation.

~~~
tptacek
There were no changes in TLS after Bleichenbacher '98; instead,
implementations just incorporated increasingly hacky workarounds. The PGP post
upthread details the problems with the MDC, and the compounding implementation
flaw in GPG that released unauthenticated plaintext to callers.

That MDC-era PGP remains the global standard, and that GPG continues to
release unauthenticated plaintext to callers, just calls out further the
impossibly compromised position PGP-based cryptosystems are in. You can try to
do things like Sequoia that modernize PGP, but nobody in the installed base
will be compatible with you, and the most popular and important "driver" of
the protocol (again, GPG) is disinterested in mitigating the flaws of legacy
PGP.

You can choose not to call GPG the PGP reference implementation, and there's
no formal declaration anywhere saying that, but, it obviously is.

~~~
upofadown
It is odd you bring up MDC in the context of EFAIL as the EFAIL researchers
were unable to come up with an exploit that MDC did not detect. Even if you
feel that GPG should of anticipated EFAIL that means that OpenPGP as a
protocol was secure against EFAIL.

It is entirely accurate to say that EFAIL in not applicable to OpenPGP. You
might not like MDC but you have to admit that EFAIL is not an example of any
sort of a weakness in MDC.

~~~
tptacek
I feel like we're not reading the same paper. The EFail paper I'm reading has
a prominent chart showing which implementations it was possible to break the
MDC in, and a section detailing how the MDC can be straightforwardly stripped
off messages.

I note that you didn't respond to the rest of my comment.

~~~
upofadown
Yeah, the paper did not claim that the MDC was in any sense "stripped off
messages". They instead claimed that the mail clients ignored the MDC error.

>I note that you didn't respond to the rest of my comment.

The TLS stuff? We are just quibbling here. You have an irrational hate of
things called PGP. Nothing I can say is going to change that.

Added: You are the one that brought up the MDC stuff but that really is beside
the point. The problem here is with the leakage that HTML emails allow. EFAIL
would still have nothing to do with PGP even if MDC did not exist.

~~~
seecurity
Search the Enigmail forums for people who couldn't open their emails after
GnuPG made MDCs mandatory (as a reaction of Efail). Especially people with old
PGP keys were receiving non-MDC (SE) ciphertexts since ever. Mozilla's
bugzilla (and a bank I heart of) were using non-MDC encryption. Reading the
OpenPGP RFC, this is perfectly fine behaviour.

The Efail paper also describes a way to downgrade MDC ciphertexts to SE
ciphertexts. This was known since 2015, but not addressed in OpenPGP.

So OpenPGP according to RFC 4880 allows SE packets with no MDC, and the MDC
can be stripped away in a standard conforming way (tho with some guessing of
bytes). If that isn't a problem with the OpenPGP standard, I don't know what
is.

Just weeks after Efail, they made SE packets (those with no MDC) deprecated in
the current RFC 4880bis. They were careful to not mention Efail, because _it
wasn 't OpenPGP's fault_. For some, it's never OpenPGP's fault.

~~~
upofadown
Interesting. I was not aware of this particular issue. Is this it?

* [https://dev.gnupg.org/T3981](https://dev.gnupg.org/T3981)

As mentioned in the discussion:

>Actually this is not related to the mentioned CVE because the issue we are
talking about has not been tested by them.

So it appears that the EFAIL people could of prevented MDC from thwarting
their attack if they had used a really old cypher. So, OK I will concede that
EFAIL at least inspired a change in GPG. My original statement that GPG
required no changes as a result of EFAIL is still correct as stated though.

We are still quibbling here. I don't think that S/MIME was deficient in any
way with respect to EFAIL either. So all this discussion about MDC is still
pointless to me.

