3 ms·

You don't need to verify it on the target system though?

matthewaveryusa 10y ago
You sign at the source with a private key, and you verify on the target with the public key. The trick is only someone with the private key can create a signature that the public key can verify.
- bigiain 10y ago
  The other problem is many people wont have pre-existing copies of the required private key available. If your attacker is in a position to MitM your download of a signed binary, they're probably also in a position to MitM your retrieval of the public key. SSL/TLS certainly helps there (at least the attacker then also needs to be capable of acquiring root CA signed TLS certs for the download site and any readily available PGP key sites. It wont slow the NSA down much - but it will help against the guy with the WiFi Pineapple in your local Starbucks…)
  - merijnv 10y ago
    > The other problem is many people wont have pre-existing copies of the required private key available. We're talking about software updates, you embed the key INSIDE the software to avoid this problem.
    - bigiain 10y ago
      Ahhh, good catch... Agreed. (Though with my overly-cynical hat on, I now just suspect you've only moved the problem to the previous update's authentication - and recursively back to the initial download. How do you protect against the initial download being MitMed and having an attacker's public key inserted - this is functionally the same as HSTS - if you can MitM the first visit you win...)
      - deno 10y ago
        You need to trust something at some point, be it TLS session and the server you’re talking with, or an SHA csum you verify with a friend (or using PGP’s WoT), and even further the process(es) and person(s) responsible for actually signing the releases. As for “moving the problem,” it is worth it. Because it’s easier to verify the origin of the software once, then for every update. If there’s a new vulnerability in TLS this will only affect new installations. Verifying (& signing) packages offline is much more anti-fragile.
- pricechild 10y ago
  The parent explained they might not trust verification on the target system. This might not necessarily be because the target is assumed malicious, but it may only have e.g. md5sum and not sha1sum available etc. (I'm obviously no expert... the hashing examples are just examples here) I intended to suggest you could download it on a separate system which you do trust and verify it there. Then transfer it to the target system.

You sign at the source with a private key, and you verify on the target with the public key. The trick is only someone with the private key can create a signature that the public key can verify.

bigiain 10y ago
The other problem is many people wont have pre-existing copies of the required private key available. If your attacker is in a position to MitM your download of a signed binary, they're probably also in a position to MitM your retrieval of the public key. SSL/TLS certainly helps there (at least the attacker then also needs to be capable of acquiring root CA signed TLS certs for the download site and any readily available PGP key sites. It wont slow the NSA down much - but it will help against the guy with the WiFi Pineapple in your local Starbucks…)
- merijnv 10y ago
  > The other problem is many people wont have pre-existing copies of the required private key available. We're talking about software updates, you embed the key INSIDE the software to avoid this problem.
  - bigiain 10y ago
    Ahhh, good catch... Agreed. (Though with my overly-cynical hat on, I now just suspect you've only moved the problem to the previous update's authentication - and recursively back to the initial download. How do you protect against the initial download being MitMed and having an attacker's public key inserted - this is functionally the same as HSTS - if you can MitM the first visit you win...)
    - deno 10y ago
      You need to trust something at some point, be it TLS session and the server you’re talking with, or an SHA csum you verify with a friend (or using PGP’s WoT), and even further the process(es) and person(s) responsible for actually signing the releases. As for “moving the problem,” it is worth it. Because it’s easier to verify the origin of the software once, then for every update. If there’s a new vulnerability in TLS this will only affect new installations. Verifying (& signing) packages offline is much more anti-fragile.
pricechild 10y ago
The parent explained they might not trust verification on the target system. This might not necessarily be because the target is assumed malicious, but it may only have e.g. md5sum and not sha1sum available etc. (I'm obviously no expert... the hashing examples are just examples here) I intended to suggest you could download it on a separate system which you do trust and verify it there. Then transfer it to the target system.