the use case here is somebody opens a web browser and types/pastes an ID into the top bar -- and it needs to resolve, correctly, without prior knowledge, in roughly the same amount of time that DNS takes today
relays are the only thing among the things you listed that even have a chance of solving this problem
While rpgp is slowly gaining support for this format (the aid users to be able to talk to anyone they want) it will keep emitting the broadest compatible format for a while by default, until the whole ecosystem has upgraded. The aggressive stance from gnupg is really hurting people and removes one of the biggest benefits of pgp, broad interop with compliant implementations.
Each faction has a seemingly legitimate position. My understanding is that there are no cryptographic weaknesses in the existing block cipher mode (SEIP) so there are no downsides to just doing that indefinitely.
Fun fact, the main reason I developed rpgp in the first place was to power the pgp portion pf deltachat, as we ran into the same problem of not having a good library based implementation. And spawning gnupg on a phone was never an option.
I am not sure if this is an actual issue, all auditors that looked at this so far haven’t mentioned this being a problem. But I will have to investigate what the exact state is.
According to `git blame`, this was introduced June 2023, i.e. after your audit in 2019. But maybe it was moved from an older piece of the codebase, I didn't dig too deep.
(Looks like the IncludeSec folks did a decent job in 2019. Hi Eric!)
However, I misread this: I thought the padding was being done on the cleartext signing side, but this is padding of the signature itself. So there's some malleability here, but it isn't susceptible to DO'1985. I'll update my top-level comment.
I am not aware of any outstanding SHA-1 issues that would require a change in the current RFC4880 OpenPGP standard. There was an obscure attack that involved generating two keypairs with colliding SHA-1 signatures and getting a third party to sign one of them but you can just use a different hash (say SHA256). The SHA-1 used in the MDC portion of the authenticated encryption mode doesn't and is very unlikely to ever represent any security weakness (the hash used there doesn't require any particular cryptographic properties). SHA-1 is used for the key fingerprint, but the use of a hash with collision resistance is not required in general for key fingerprints. An attacker could in theory create two different keys with the same fingerprint, but then they would just own two keys that would be hard for to distinguish from one another. You don't sign the fingerprints, you sign the actual public key. In general, it would be a bad idea to specify that the hash used for a key fingerprint required collision resistance as that would mean that the fingerprint would have to be something like an unusable 256 bits long to prevent birthday attacks.
There are higher level implementations that use the dates on signatures to straight out reject sha1 material, but that gives only a limited protection.
Yep. We've got it working with OpenPGP Card devices (Yubikeys, Nitorkeys, etc.). The signing part was actually pretty easy and the decryption required a bit more work but the maintainer was super responsive (https://github.com/rpgp/rpgp/pull/315).
How does it interface with the cards? IIRC the rust pcsc library used by Sequoia needed C libraries. I've been doing some NFC stuff too and was looking for a pure-rust solution if there was one.
