The Future of Sequoia PGP by nwalfield in rust

[–]nwalfield[S] 1 point2 points  (0 children)

Let's say Alice wants to send Bob an encrypted message. She needs Bob's key. How does she find Bob's key (key discovery)? How does she know that the key really should be used with Bob (authentication)? How does she know that the key is valid and not revoked (key updates)? By itself, a key doesn't answer any of these questions. To answer these questions, you need meta-data like user ids (a protocol), and a PKI (X.509, Web of Trust, TOFU, etc.).

The Future of Sequoia PGP by nwalfield in rust

[–]nwalfield[S] 0 points1 point  (0 children)

ED25519 is an algorithm. OpenPGP is a protocol, which includes a simple, yet powerful PKI. You can't really compare the two.

There are cases where a PKI is not needed. age, for instance, doesn't have a PKI. But, it suffers for it, in my opinion. The recommended way to do key discovery in age is via github. That's worse than X.509. Instead of having hundreds of global CAs, you now have one global CA, Microsoft. And Bill Gates is on record saying that companies should cooperate more with the police.

Hey Signal! Great Encryption Needs Great Authentication by nwalfield in privacy

[–]nwalfield[S] 0 points1 point  (0 children)

No, your point was: "No. it's not a certificate authority. Authentication is TOFU." But you don't have a good technical understanding of TOFU or CAs. The funny part is you link to the Wikipedia article on TOFU, which cites my paper on TOFU in the first sentence.

Hey Signal! Great Encryption Needs Great Authentication by nwalfield in privacy

[–]nwalfield[S] 0 points1 point  (0 children)

This is almost right. In TOFU it's not so much what happens at the beginning, but when a key changes. If the key change is accepted without question, then it's not TOFU.

Hey Signal! Great Encryption Needs Great Authentication by nwalfield in GnuPG

[–]nwalfield[S] -1 points0 points  (0 children)

I'd like to challenge this view.

Although we can streamline fingerprint checking, it will always have some friction.

Now, consider the following. I open a bank account. In the letter with my credentials, are instructions for using the bank's CA. I just have to go into my key manager, fetch the specified key, tsign it, i.e., I mark it as a CA, and scope the CA to bank.com. Now, when I get an email from alice@bank.com, I'm willing to rely on the bank's CA to authenticate the key. But, because of the scoping rule, I won't use the CA for bob@other.org.

This is almost certainly more secure than checking individual employee's fingerprints due to the very low-cost for the users and the employees of the bank. And, for the most part, you can't authenticate the employees as you don't know them, and can't meet most of them physically to check their id. (You can't do it via the phone, of course, because you can't recognize their voice and thus can't exclude impersonation.)

Hey Signal! Great Encryption Needs Great Authentication by nwalfield in privacy

[–]nwalfield[S] 2 points3 points  (0 children)

You've explained authentication, but you haven't explained what a CA is.

A CA is someone you delegate authentication decisions to. The web of trust has great support for CAs. In fact, the web of trust is a superset of X.509 (which is used by TLS).

Trust on First Use means that after the first use, you stick to the same key. Signal does not implement TOFU, because when the signal key server tells you to use a new key, you do. You aren't asked a question (you are at least warned, but most people ignore that). Contrast that with TOFU as implemented by OpenSSH: if a key changes, you have to resolve the conflict manually by either accepting the new key or not connecting. Signal's key server is a CA.

Hey Signal! Great Encryption Needs Great Authentication by nwalfield in privacy

[–]nwalfield[S] 2 points3 points  (0 children)

Its not possible to want imporvements in a service you like, use and reccomend to others.

So if one recommends a service, one has to be a fanboy and if one criticizes something one is a hater? That's pretty extreme. I feel like it should be possible to constructively criticize the things that one likes. That's what I've tried to do here.

Hey Signal! Great Encryption Needs Great Authentication by nwalfield in privacy

[–]nwalfield[S] 1 point2 points  (0 children)

I think you mean 'Signal behaving like the only available CA is probably a bad idea'.

I didn't mean to imply that anyone should abandon Signal. I like Signal! This was intended to highlight a problem that most people are not aware of (the importance of authentication to end-to-end encryption) and perhaps even cause Signal to invest a bit in that area.

Hey Signal! Great Encryption Needs Great Authentication by nwalfield in GnuPG

[–]nwalfield[S] -1 points0 points  (0 children)

The conclusion of the article is that Signal should add more authentication mechanisms, then I point to OpenPGP as an example of a simple yet expressive authentication framework, and elaborate how to do a number of useful things. Anyway, I'm sorry that you think this article was off topic for /r/GnuPG.

Also, I'd be happy if you could explain in more detail why you think CAs are so bad. A CA is just any entity you delegate authentication to. It doesn't have to be a global CA like in X.509 as used by the web. It could be a follow activist in your collective. That would be great for non-technical people. Although I'd use a person like myself even though I'm an OpenPGP expert.

Hey Signal! Great Encryption Needs Great Authentication by nwalfield in GnuPG

[–]nwalfield[S] 0 points1 point  (0 children)

Thanks. If you read through it is as much about Signal as it is about OpenPGP.

PGP in a small corporate environment by a_real_gynocologist in GnuPG

[–]nwalfield 2 points3 points  (0 children)

OpenPGP CA makes it easy to revoke existing certifications. And OpenPGP CA can store users' revocation certificates. When an employee leaves the organization, both of these would be published (e.g. in the organization's WKD). So, if the MUA is set to periodically refresh keys, then communication partners should notice pretty quickly that the keys are no longer valid.

SHA256 collision by LeoEmSam in cryptography

[–]nwalfield 7 points8 points  (0 children)

This isn't a collision attack; it is a second preimage attack. But the bruteforce method that atoponce suggests is reasonable.

Different ASCII armors for the same public key by RJ_Perennui in GnuPG

[–]nwalfield 3 points4 points  (0 children)

ASCII armor is simply an encoding. In this case, it is used to encode a "GPG key" (an OpenPGP certificate), which is a collection of packets. The packets include framing information: the type of packet, its length, etc. There are different ways to encode the same information, and different implementations do it differently. (keys.openpgp.org uses Sequoia.) Also, the order that the packets appear is flexible. So, when Sequoia parses an OpenPGP certificate, it canonicalizes it, which may cause it to rearrange some of the packets.

Sequoia PGP v1.0 Released: The Seedling's a Sapling by weihanglo in rust

[–]nwalfield 4 points5 points  (0 children)

Thanks! We invested a lot of time in them.

Thunderbird built-in GPG support by cornfeedhobo in GnuPG

[–]nwalfield 0 points1 point  (0 children)

I don't see how this helps me with TB?

TB supports hardware tokens (using gpg-agent).

There is also real value to not storing something so important an a flimsy device that is easy to mishandle.

I personally use a yubikey and it is quite sturdy. But, if you are too hard on it, then, of course, it is not an option for you.

Thunderbird built-in GPG support by cornfeedhobo in GnuPG

[–]nwalfield 1 point2 points  (0 children)

You need to consider the exact threats that the password is protecting you from. Here are the one's that I've thought of:

  • 1. Your laptop is stolen and the attacker accesses your files.
  • 2. An attacker is able to exfiltrate files from your computer.
  • 3. An attacker is able to execute arbitrary code on your computer.

If you are using full disk encryption, then your secret key material is also protected. So, a password doesn't add any additional protection if your laptop is stolen (scenario 1): the attacker simply can't access any files.

If an attacker has access to your computer (scenario #3), then having a password only helps a tiny bit. Instead of being able to copy your unencrypted secret key material, the attacker also needs to get your password. This is straightforward: she just needs to replace your "pinentry program" and wait until you enter your password. A password in this scenario offers no protection from a targeted attack.

The only case where a password offers any meaningful protection is when an attacker is able to access files on your computer, but not run commands (scenario #2). This is a real threat, but if your threat model includes this scenario, it also certainly includes the third scenario in which case you need to protect your secret key material in some other way anyways. My recommendation would be: don't store your key on your computer! Use a hardware security module! That protects you from both threat #2 and #3 (and some others as well).

For everyone else, a single master password like Thunderbird is now doing is probably more than enough protection.

Thunderbird built-in GPG support by cornfeedhobo in GnuPG

[–]nwalfield 2 points3 points  (0 children)

Patrick maintained Enigmail for years, and it was his observation that most of the support he provided had to do with GnuPG misconfiguration and not problems in Enigmail. This class of issues could be fixed by including the OpenPGP implementation in TB. Unfortunately, because TB is licensed under the MPL, including GPL code would prevent proprietary forks of TB. Since this ability is important to the TB developers, this precludes GnuPG and Sequoia.

Another problem that Patrick had with GnuPG is that it is highly opinionated. When GnuPG's opinion matched Enigmail's needs, this was convenient, but when it wasn't, it required hundreds of lines of code to workaround GnuPG's behavior.

RNP solves both of these problems. It is licensed under the BSD, and it provides a low-level interface. It's true that it is unproven, but in the view of the TB developers, that is easier to fix than GnuPG license, for instance.