5 ms·

Where I work we often have to exchange keys with partners. Key fingerprint is often used as a mechanism to make sure the partner really has OUR public key. We e

by rhuru 3y ago

Where I work we often have to exchange keys with partners. Key fingerprint is often used as a mechanism to make sure the partner really has OUR public key. We email the key first and then another known employee is expected to verify the fingerprint on phone. 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.

0xDEAFBEAD 3y ago
>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_compromise 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=38557888 https://news.ycombinator.com/item?id=38558231 https://news.ycombinator.com/item?id=38558231 https://news.ycombinator.com/item?id=38555803 https://news.ycombinator.com/item?id=38555803
- halJordan 3y ago
  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 3y ago
    >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.)
    - groestl 3y ago
      And to mitigate sniffing
      - 0xDEAFBEAD 3y ago
        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 3y ago
        You get security in the current system, just not privacy.
        0xDEAFBEAD 3y ago
        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.
        yjftsjthsd-h 3y ago
        I suspect you could extend that line of logic to always combine privacy and security. Which, granted is not exactly wrong, but that's just security through obscurity and you really shouldn't rely on it. (Of course, if it's free then you should strongly consider taking the obscurity, and privacy is a compelling argument all on its own. I just think blurring the line here is iffy.)
        0xDEAFBEAD 3y ago
        I'd argue that privacy and security are unavoidably related. Is keeping your password secret about privacy, security, or "security through obscurity"? Depends which term you want to use :-) IMO the concept of "security by obscurity" is overused. Ultimately what matters is the cost for an attacker. If you're trying to design a secure system, your system will be stronger if you put it out there for people to criticize instead of keeping the details secret. This argument doesn't really apply to encrypting the packages you use. Security solely through obscurity isn't ideal, but what really matters is the cost/benefit ratio. It's way easier to encrypt your package downloads than it is to read all the source code changes on every package update. (Does anyone even do that?) I agree with this article: https://danielmiessler.com/p/security-by-obscurity/ https://danielmiessler.com/p/security-by-obscurity/
- lucb1e 3y ago
  > 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.
  - deleted 3y ago
    [deleted]
  - 0xDEAFBEAD 3y ago
    >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-What-is-a-safety-number-and-why-do-I-see-that-it-changed- 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 3y ago
      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
- rhuru 3y ago
  > 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.
lucb1e 3y ago
Upon reading that first sentence, I immediately checked your username to see if you're my colleague. We do that as well and, while I think it sensible, I also feel like it's relatively out there compared to most businesses (even for banks and the like). Now I'm curious, are you willing to disclose what line of work you do? For me, it's security consultancy (code reviews, penetration tests, network scanning... occasionally physical security tests or other related things, but those three are the bread-and-butter), so new employees get to verify everyone's fingerprint on chat. I've been trying to get people to use key signing for PGP (email) and about half the people get it, but now that Thunderbird dropped support for the Enigmail plugin, it also stopped supporting the web of trust and you just have to go through and verify everyone manually no matter how many signatures a key has from people that you've already verified. They managed to make the PGP experience even worse, which is honestly something that should grant an award

by rhuru 3y ago

0xDEAFBEAD 3y ago

>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_compromise 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=38557888 https://news.ycombinator.com/item?id=38558231 https://news.ycombinator.com/item?id=38558231 https://news.ycombinator.com/item?id=38555803 https://news.ycombinator.com/item?id=38555803

halJordan 3y ago
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 3y ago
  >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.)
  - groestl 3y ago
    And to mitigate sniffing
    - 0xDEAFBEAD 3y ago
      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 3y ago
        You get security in the current system, just not privacy.
        0xDEAFBEAD 3y ago
        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.
        yjftsjthsd-h 3y ago
        I suspect you could extend that line of logic to always combine privacy and security. Which, granted is not exactly wrong, but that's just security through obscurity and you really shouldn't rely on it. (Of course, if it's free then you should strongly consider taking the obscurity, and privacy is a compelling argument all on its own. I just think blurring the line here is iffy.)
        0xDEAFBEAD 3y ago
        I'd argue that privacy and security are unavoidably related. Is keeping your password secret about privacy, security, or "security through obscurity"? Depends which term you want to use :-) IMO the concept of "security by obscurity" is overused. Ultimately what matters is the cost for an attacker. If you're trying to design a secure system, your system will be stronger if you put it out there for people to criticize instead of keeping the details secret. This argument doesn't really apply to encrypting the packages you use. Security solely through obscurity isn't ideal, but what really matters is the cost/benefit ratio. It's way easier to encrypt your package downloads than it is to read all the source code changes on every package update. (Does anyone even do that?) I agree with this article: https://danielmiessler.com/p/security-by-obscurity/ https://danielmiessler.com/p/security-by-obscurity/
lucb1e 3y ago
> 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.
- deleted 3y ago
  [deleted]
- 0xDEAFBEAD 3y ago
  >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-What-is-a-safety-number-and-why-do-I-see-that-it-changed- 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 3y ago
    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
rhuru 3y ago
> 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.

lucb1e 3y ago

Upon reading that first sentence, I immediately checked your username to see if you're my colleague. We do that as well and, while I think it sensible, I also feel like it's relatively out there compared to most businesses (even for banks and the like). Now I'm curious, are you willing to disclose what line of work you do? For me, it's security consultancy (code reviews, penetration tests, network scanning... occasionally physical security tests or other related things, but those three are the bread-and-butter), so new employees get to verify everyone's fingerprint on chat. I've been trying to get people to use key signing for PGP (email) and about half the people get it, but now that Thunderbird dropped support for the Enigmail plugin, it also stopped supporting the web of trust and you just have to go through and verify everyone manually no matter how many signatures a key has from people that you've already verified. They managed to make the PGP experience even worse, which is honestly something that should grant an award