@pete @ajtowns one thing to look into is that GPG supports ed25519 as a signature scheme which better lends themselves to multiparty/threshold,

@orionwl @ajtowns Yup. secp256k1 too, so any scheme that can do single-key-multisig for Bitcoin can also do it for pgp.

@pete @ajtowns in any case, i don't want to make this decision; i have limited knowledge here anyway

anyone coming up with a working implementation of the proposal will have a say in what algorithms and tools to use 😀

@orionwl @pete hmm. PGP is kind of all about working for email - so the ambiguous text parsing is a bit baked in, in a sense. Stop making me think about reinventing pgp. :(

@ajtowns @pete i am not going to get into a discussion about whether web of trust works

practically i think having people use a custom, bitcoin-specific verification tool is going to make it even harder to get people to verify the releases, yet another thing they have to learn

@ajtowns @orionwl Web-of-trust works for it's intended audience: people who are taking the time to actually verify something rather than just relying on their web browsers.

Re: multisig, just sticking a few different signatures on releases manually is fine. Anyone verifying this stuff to that level is verifying it manually anyway. And PGP *does* allow for multiple signatures on one file, even in things like git commits.

@ajtowns @orionwl BTW, re: "taking the time", I've consulted on the requirements for high-value storage. It's annoying, time consuming, work to do properly. Stuff like buying sealed laptops at in person stores randomly to verify install disks.

If you are doing it properly, verifying some web-of-trust is the least of your issues.

There are companies with wallets worth hundreds of millions of dollars. I've had clients with plans for billions (I seem to have dissuaded most of them...).

@pete huh? I thought Web of trust was basically widely recognised as a failure at this point. "X signed Y's key" is hard to assign meaning to if you don't both trust X and know their signing policy, misty people's signing policies are terrible unless they're cryptographers, and the tooling for verification is horrible? How is someone new to bitcoin supposed to use the web of trust to validate a release key?

@ajtowns Yeah, current implementations suck. It's still *far* better than the alternatives of blindly trusting certificate authorities, or just hoping that the first key you downloaded was right.

Again, none of this is relevant to the actual target market for PGP signatures: experts willing to put in the time to do things properly and think through the basis for their trust.

@pete uh, if you're only putting release signatures on for cryptography experts, what's everyone else meant to do to avoid running malware? Of we encouraged distros too ship bitcoin that would be one thing, but we discourage that...

@ajtowns You haven't proposed an alternative. Throwing out some niche BIP is _not_ an alternative.

Fact is, in the real world the people who don't validate this stuff by hand are going to end up having web browser certs as the root of trust, and/or auto-update tools.

@pete bip322 is relatively easy to adapt for both multiple signers and automated validation of updates, at least for Bitcoin's use case. I think doing either with gpg is essentially a research problem.

@ajtowns By the time you implement that, you could have just slapped multiple PGP sigs on one file and told your auto-update tool what to do. And that's easier to verify by hand by the experts who are double-checking things.

Note that you *literally* can concatenate the ascii-encoded sigs, and they'll verify just fine with GnuPG. We've actually done this before for a public announcement; I've done it on git commits.

@pete yes, that was precisely one of the failure modes for apt. If you're doing a single key or assuming you're dealing with people who know when to say "that's sus" vs "that's just the mailing list screwing up text encoding", gpg is fine, but sounds like were moving outside those boundaries.

@pete to be clear: i don't mean to criticise gpg; I'd tried doing some of this stuff with the original pgp - gpg is the most beautiful thing ever in existence

@pete @orionwl manually verifying things doesn't scale, that's why apt and the like verify signatures automatically. You have to trust/verify you got the initial installation right and haven't been compromised since, but automation makes staying up to date easier. Automating gpg is pretty painful, and we have or own signing tools that we have to maintain anyway. but *shrug* - I've done the adding gpg stuff with apt already, don't need to climb that mountain again.

@ajtowns @pete i definitly, fully, agree with regard to autmating gnupg

fwiw last time i asked about that someone suggested a rust crate that looks pretty good (it is an actual implementation of PGP, not a shell stub), i still need to look into it in detail though: https://lib.rs/crates/pgp

@ajtowns @orionwl ...apt uses PGP behind the scenes...

Anyway, "doesn't scale" is irrelevant. The actual use-case of PGP is for the experts to verify that high value use-cases are correct. Including that the automated systems are correct.

Don't get fooled by propaganda from academic cryptographers who have every reason to shit on an inherently fuzzy, human, problem that their math credentials can't solve.

@ajtowns @orionwl In particular, it is _very_ likely that at least some of those academics are literally being paid off by the likes of the NSA to discourage the use of secure, decentralized, tech.

We know from the Snowden leaks that GnuPGP was one of the things they had severe problems compromising reliably. Equally, the PGP _mindset_ is one that makes for systems that are hard to compromise.

@pete @orionwl yes, I designed that code. And despite using the special front-end for parsing, there's been security bugs as a result.

@ajtowns @orionwl I know. That's why efforts got put into writing new PGP libraries. Efforts that should have been done literally a decade ago... But of course get held back, because people inexplicably push weird niche stuff that's obviously worse.

@ajtowns @orionwl Believe me, I'd love to replace OpenPGP with a standard with sane serialization, ditches old crypto, etc.

But if I were to do that, I'd actually make a _replacement_. That means thinking about how to get to the same place re: WoT and key distribution. And that's a _much_ harder problem to solve than the crypto itself.

@ajtowns @orionwl You know what was _the_ biggest advance in web certificate security?

It wasn't new crypto. It was a stupidly simple merkle mountain range called certificate transparency. It revolutionized the human/political side of the certificate business, by adding some pretty basic auditing. It has literally lead to scammers and bad actors going bankrupt.

_That's_ the kind of thing what a PGP replacement needs to focus on. Not what signature scheme it happens to use.

@pete @orionwl what do you think is valuable about the wot? Turning an identity (name, email, etc) into a downloadable key, subkeys/revocations/expiry, having a decentralised structure rather than a CA? The automatic trust stuff was always a failure imo. Having all the info be public also seems a bit fail-ish (also webs should be in the shadows just on principle)

@ajtowns @orionwl What "automatic trust stuff" specifically? You mean GPG's trust db?

How do you propose to allow third parties to verify anything without WoT data being public?

Conversely, why do you think the fact that someone like myself - a very well known figure - might think, say, the Qubes signing key is real needs to be kept private?

@ajtowns @orionwl Re: the value of WoT, it's obvious: having something other than certificate authorities.

You see this _immediaty_ if you ever try to work out the procedures for securely doing something of high value: you just have to have some other way of verifying signatures, because CAs are worse than a central point of failure. They're literally hundreds of points of failure.

@pete the strong set is 55k single points of failure for pgp's automatic trust calculations. Or there's zero middlemen if you're directly checking fingerprints and doing kyc in person. Or there's stuff in between. Which are you talking about? It's not obvious to me.

@pete Having everything public means you can identify who went to every keysigning party. Why would that be desirable any more than having every coffee purchase on the blockchain? Doesn't mean every attestation should be private either though.

@ajtowns The industry goes to conferences and gives talks. Who knows who, where we've been, and who we talk too is very public. And you can always delay when you sign. Or choose not too.

Again, what's the alternative for high security? Be realistic.

@ajtowns "@pete the strong set is 55k single points of failure for pgp's automatic trust calculations."

Huh? That's not how GPG works. You don't just blindly trust multiple levels deep.

"Or there's zero middlemen if you're directly checking fingerprints and doing kyc in person."

...which is _incredibly_ limiting. Even someone like me who has gone to countless conferences doesn't have a direct links with tons of people. But after one or two steps, it's not so hard.

@ajtowns ...and remember, you absolutely can change how GPG works re: marginal trust and the like. You get to decide how you want to verify keys. It's not hard.

@pete I wish we were having this conversation irl because it's hard to get my level of skepticism across without exaggerated facial expressions. Changing marginal levels of trust in gpg correctly isn't hard? (I mean I could argue that choosing never trust anyone is correct and easy, but...)

@ajtowns It's very easy to do a better job than the alternative - the CA system - with GPGs trust database and some thought. Hell, just the fact that it's _not_ a common and standardized way of doing things is by itself a huge improvement for expert usage, because targeting an attack is hard and it'll have a low payoff usually.

Not to mention, the obvious thing to do ends up combining both: downloading a .sig file from an https connection.

@pete @orionwl man finding a reference for that is harder than I expected. Maybe https://lists.debian.org/debian-devel-announce/2003/01/msg00009.html and http://web.archive.org/web/20020205024526/http://people.debian.org/~ajt/apt-check-sigs ... Maybe "proof of concepted" is more descriptive than "designed" 😅

@ajtowns @orionwl 1024bit DSA FTW.

@pete @orionwl it was upgrading to all new sha1 hashes too