[AnthonyMouse]

> The problem is that you need to get the authentic public key of the software distributor to verify the signature.

Right. If you already have a secure channel to receive the signing key over, you can just use it to receive the software to begin with.

Meanwhile we do have a CA system that lets you download the software via TLS. It's not perfect, but breaking TLS or compromising a CA are not even close to common methods of delivering malware.

[infokiller]

> Right. If you already have a secure channel to receive the signing key over, you can just use it to receive the software to begin with.

Note that the secure channel sometimes has more limited bandwidth. An example would be reading part of your public key over the phone, which is not practical for the actual software. There are other considerations that make using the secure channel for the software itself impractical. For example, you can have many people publish known public keys on their website, so that other people could verify them with some majority voting.

> Meanwhile we do have a CA system that lets you download the software via TLS. It's not perfect, but breaking TLS or compromising a CA are not even close to common methods of delivering malware.

The main risk is not breaking TLS or CAs, but rather compromising the server that you download the software from, and serving malware instead. Indeed, if the same server is used for serving the public key, you don't gain much, because the attacker can just generate their own key pair, sign the malware, and publish their key. But ideally, the public key would not be published from the same server, making an attack more difficult.

[AnthonyMouse]

> Note that the secure channel sometimes has more limited bandwidth. An example would be reading part of your public key over the phone, which is not practical for the actual software.

In theory, sure. In practice ordinary users are not calling up the software developer and having them read their public key over the phone.

> There are other considerations that make using the secure channel for the software itself impractical. For example, you can have many people publish known public keys on their website, so that other people could verify them with some majority voting.

You could do the same thing with the application binary itself and have them compare hashes.

> But ideally, the public key would not be published from the same server, making an attack more difficult.

You could get the same benefit from publishing only the hash of the software on the separate server. The signature is redundant, and is even worse than the hash because it introduces private key compromise as an attack vector.

The main benefit of signatures is for an app distribution system that needs to distribute multiple apps or updates, so then it can deliver the public key once and reuse it. But now you're talking about the package manager and Linux package managers already do that.

[infokiller]

> You could do the same thing with the application binary itself and have them compare hashes.

This is not scalable to software updates, which happen much more frequently than (long term) key updates. With hashes you would need to publish a new hash for every update, but with public keys you're fine.

> You could get the same benefit from publishing only the hash of the software on the separate server. The signature is redundant, and is in fact worse than the hash because it introduces private key compromise as an attack vector.

Similarly to the issue I mentioned above, this introduces a hassle because the hash will change every time you update the software, which means you will need to update it. In addition, the system serving the hash/key should have some additional safeguards for updating it (because it's somewhat more sensitive), making the update probably more cumbersome. Could you clarify what attack is possible with keys that is not possible with hashes?