Identity

Date: Thu 2022-10-06

Permalink: https://www.dominic-ricottone.com/posts/2022/10/identity/


I’ve been thinking about adding identity verification by way of digital signatures to my web chat. This has lead to a bit of a deep dive into OpenPGP infrastructure and security strategy.

A dip into this pond quickly informs a reader that the Web of Trust is flawed fundamentally. The arguments against it center around a few points:

1 End users don’t hesitate to throw away their PGP keys. (Because who actually knows enough about GnuPG configuration to migrate their setup between hosts? Everyone just uses the distro defaults…) And because keys are such cheap things, end users don’t take proper steps to protect them. Altogether, they fail to be trustworthy in the longer term. 2 End users blindly import a key when a gist tells them to. 3 End users prefer to verify their identity by password authentication. So all commercial and/or ambitious projects eventually outgrow PGP in terms of features and functionality. 4 The infrastructure itself is vulnerable, a la certificate poisoning.

And on further consideration, there’s always a bit of noise on project mail lists when someone’s signing key needs to be revoked. A toolchain that requires so much maintenance is not a very good toolchain.

But further consideration leads to the question: if not PGP, then what?

I remember not too long ago seeing a number of GitHub issues requesting use of signify for releases. I didn’t think highly of it at the time. (Just another BSD trying to force it’s philosophy on mere mortals.) But in light of the above, maybe a simpler toolchain is what we need.

There’s currently a public discussion in the age community about whether authentication should be supported. This conversation has highlighted how federated identity is very difficult.

If you encrypt and then sign, an attacker can strip your signature, replace it with their own, and make it look like they encrypted the file even if they don’t actually know the contents.

If you sign and then encrypt, the recipient can decrypt the file, keep your signature, and encrypt it to a different recipient, making it look like you intended to send the file to them.

Adding to all the consternation is the fact that I am trying to use signatures in a chat application that is public, i.e. multiple recipients.


In the end, I have begun to press ahead with implementing digital signatures. Signing happens last, and does not imply ownership over the content of the signed message. Rather, it ensures that this instance of the message came from a certain sender.

At this stage I don’t think it’s a good idea to put real-world private keys into the application, so I am just using ephemeral RSA keys and the PKCS #1 scheme for signatures (specifically RSASSA-PKCS1-v1_5).

I am interested in the idea of GPG integration though, so I’m likely to start looking at a companion client implementation for use on the terminal.


Previous article: WireGuard

Next article: HTML and XML


Articles from the internet that I've been reading

  • Does A Software Engineer Have Scorpion Nature?

    I. A scorpion wants to sell some software but cannot code, so it asks a frog to write the application. The frog hesitates, afraid that the scorpion might start running Scrum, but the scorpion promises not to, pointing out that they would both be out of wor…

    via Ludicity

    April 8, 2024

  • My Maintenance Policy

    A short document describing how I maintain open source projects. It talks about how I prefer issues to PRs, how I work in batches, and how I'm trigger-happy with bans. It's all about setting expectations.

    via Filippo Valsorda

    April 6, 2024

  • I created a monster

    I guess it’s not a surprise, but I just don’t enjoy writing very much. I do, however, recognize its importance, so I always want to try. And sometimes, there is just this weird set of circumstances that kicks everything back into motion. _Djot One feeling that…

    via blogfehler!

    April 5, 2024

Generated by openring