[0xDEAFBEAD]

>Another approach is to host the keys on a HTTPS endpoint on our official domain name and their servers can fetch it programmatically and rely on TLS to verify that it is indeed our endpoint.

That's only as secure as the weakest CA in their trust store though, right? https://en.wikipedia.org/wiki/Certificate_authority#CA_compr...

IMO the best way is to put your key fingerprint on your business card and all your promotional materials. Then you just have to ensure that an adversary doesn't tamper with those :-)

(Of course, use of additional verification for the sake of redundancy is great too)

Spreading your Signal phone number is another approach. There was a recent HN thread discussing the merits of GPG vs Signal:

https://news.ycombinator.com/item?id=38557888

https://news.ycombinator.com/item?id=38558231

https://news.ycombinator.com/item?id=38555803

[lucb1e]

> Spreading your Signal phone number is another approach.

That's... like putting your username on your business card as though that's key material.

If you want to do fingerprint distribution, you should actually publish your Signal key's fingerprint (they call it 'safety number' to keep everyone on their toes). The phone number is your user identifier (like a unique username); the safety number is the key material you're meaning to publish as an alternative to the CA system.

[0xDEAFBEAD]

>If you want to do fingerprint distribution, you should actually publish your Signal key's fingerprint (they call it 'safety number' to keep everyone on their toes).

"Each Signal one-to-one chat has a unique safety number that allows you to verify the security of your messages and calls with specific contacts."

https://support.signal.org/hc/en-us/articles/360007060632-Wh...

I don't see how I could publish my safety number if it's unique to each one-on-one chat?

I've been looking at the Signal website, and I don't actually see a way to distribute a fingerprint...

[lucb1e]

As I said, safety numbers are how they keep everyone on their toes! Can't have it be easy to verify that the Signal servers are honest :) This is why I joke that moxie must be a double agent (I don't think he is, but I find it funny that many of Signal's principles (see also: alt clients; federation; phone numbers; etc.) can be explained that way).

The key material shown in each chat is a concatenation of your fingerprint and their fingerprint, ordered alphabetically so that you are both shown the same thing. By checking two of your chats, you can find out which half is shared (that's yours) and which is unique (that's theirs).

The QR code contains more data, I think your phone number and perhaps a longer/stronger fingerprint (I looked into it once but forgot the details), so that's marginally more secure/foolproof to compare but also even harder to distribute since it'll only ever be valid for one contact

[0xDEAFBEAD]

Thanks, this is valuable information. Is it documented anywhere?

[lucb1e]

What, the source code isn't documentation enough? (jk)

I vaguely remember critique towards PGP coming from Signal's corner of the internet (probably before it was called Signal) for having long-term stable keys and published fingerprints that make it so you want them to be long-term stable for verification purposes. Problem is, I looked for this critique a few months ago and can't find it anymore, so perhaps I'm putting words in their mouth that, instead, came from Signal supporters in a comment thread or so, though I also can't think of any other reason to hide your public key's fingerprint. Regularly swapping out keys protects from temporary key compromise situations, that's simply a fact, but it trades off being able to publish your key somewhere and people being able to use that to not have to trust "the server" (a central key distribution system) in an E2EE application. I have a different opinion than Signal seems to have on which variant is the lesser evil, but I can see why they've made the choice. (Imagine my surprise when finding out that Signal's public keys are long-term stable with indefinite validity.)

So, given that they seemingly don't want people to use their public key fingerprint the way that you can with PGP (printing it on a business card), I am not surprised if there is no user documentation on how to undo the concatenation. I'm not aware of such documentation myself, and it wouldn't be the first time that I have to dive into Signal's source code to find info on already-pushed-to-users functionality.

Let me know if you find any docs, though, because I seem to type out the explanation of how to use signal key fingerprints somewhat regularly (I should store it somewhere in reusable form, yeah) and sending a link with screenshots will be much nicer

[0xDEAFBEAD]

Maybe you can write the O'Reilly book on Signal ;-)

[rhuru]

> That's only as secure as the weakest CA in their trust store though, right?

You are absolutely right. Not only the weakest CA but now you needlessly involve a lot of third (or at least one third party).

It is not something I like but some of our partners demand it.

[halJordan]

No public keys are meant to be public, either yes key will be correct or not. This is why (to my knowledge) package managers like apt still check http endpoints instead of https ones.

[0xDEAFBEAD]

>No public keys are meant to be public, either yes key will be correct or not.

Yeah but how do you know if the key is correct if you're getting it for the first time?

>This is why (to my knowledge) package managers like apt still check http endpoints instead of https ones.

Your distro ships with a public key that lets you verify package signatures. TLS is redundant because you already have that trust anchor which came with the distro. (I would suggest using TLS anyway though, to force an attacker to break 2 layers of security.)

[Borealid]

OpenSSH has built-in support for retrieving a key fingerprint over DNSSec-secured DNS. It's disabled by default.

If you enable it, the first connection to a new host will say "matching host key fingerprint found in DNS" if DNSSec is operational AND the retrieved key matches.

[tptacek]

It's a little baffling that anyone would set this up, as the thing it promises is key integrity backed by government-controlled PKI. The impulse is sound! It's a good thing to want! But you can accomplish the same thing, and get other benefits, without forklifting DNSSEC into your zone configuration, by using SSH's certificate system. SSH certificates aren't X.509; they're much simpler.

[Borealid]

First, the DNSSec keys are TOFU so only the first connection is attack-able by someone in control of DNS zone root keys, and any other connections set off alarm bells.

Second, DNS lets you connect to someone else's host and get their public key without needing to find their (not your) CA.

Third, if you're not entering IP addresses by hand DNS forms some part of your systems trust no matter what you do. You're free to pin a domain's DNSSec KSK if you're very worried about someone in control of the whole Internet using that control to trick your first SSH connections.

[tptacek]

All SSH keys are TOFU! You can't mitigate the state-controlled PKI thing by saying it's TOFU; you get that property even without DNSSEC!

[groestl]

And to mitigate sniffing

[0xDEAFBEAD]

Yes that's a great point. I wish distros would force all mirrors to be TLS. Security should be the default. If users want to use a fast insecure mirror, they can enable that option at their discretion.

[yjftsjthsd-h]

You get security in the current system, just not privacy.

[0xDEAFBEAD]

In this case they're related because of supply chain attacks. If an attacker learns that you're using a small obscure package, they might be able to hack the developer's machine and insert a backdoor or bugdoor.