|
|
|
|
|
by infokiller
2186 days ago
|
|
> 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? |
|