what's the point of cryptographically signing a file, instead

File: images.jpg (3KB, 98x94px)

3KB, 98x94px

>not signing the hash

The reason digital signing is used is because it's not vulnerable to tampering, i.e. man in the middle attacks. A hash transmitted in plaintext can be changed on the fly and the end user would not know - digitally signed files are decrypted from a public key (encryption is done using a different private key), so if the file was tampered the recieving host would know immediately.

>>57781631

thanks

if an attacker can temper with the hash in transit, he can also spoof the public signing key in transit (generated from his evil private key)

>>57781879
>>>57781631
>thanks
>if an attacker can temper with the hash in transit, he can also spoof the public signing key in transit (generated from his evil private key)
False. Then it would not match the public key of the sender.

That is possible, but keep in mind that most encrypted communications that use SSL/TLS (such as HTTPS) use public keys that have already been preinstalled on your own machine, pretty much negating that risk. This includes certificates that you might download from the web - most of them have also been signed by a parent CA (certificate authority) that your computer also trusts.

File: 1477630014510.jpg (447KB, 1277x1920px) Image search: [Google]

447KB, 1277x1920px

Let's say i want to share a file with person X. I upload it to my web server together with its signature and my public key.

Evil hax0r r00ts my server, infects the file, creates his own signature and public key (from his private key).

User X downloads the evil file, sig, and key.

how is the above any more secure than evil hax0r r00ting my server and generating an evil checksum? not trolling, really want to know the advantage of using sig/key to insure integrity of a file vs just a vanilla checksum.

>>57782022
That wouldn't work as long as the user X has your legit public key. The hacker could create a file in his name, but the recieving host would know it is a tampered file as it can not be decrypted from your public key.

If you're that paranoid about security then you should be signing files on a secure, non-public facing computer, then uploading them to your webserver which does NOT contain any keys.

A checksum would not work, because while they are relatively secure - easy to get one from a file but virtually impossible to make a different file with the same sum - they do not have any verifiable data on their own. If you want your files to be un-tamperable AND verifiable from any host that does not know anything about you - over a publically visible connection - asymmetric cryptography has to be applied somewhere.

>>57782300

so user X must obtain my legit public key not from the potentially r00ted server, but by some other way?

>>57782668
Getting the key from your sever is still helpful.
Whenever you release a new version of your files, the hash will be different, so there's no way for the user to know if the new version is genuine or not. But if you sign the files with a key, then the attacker would have to replace the key on the site, which is VERY suspicious.

But yes, getting the key from somewhere is is still preferable.

>>57781502
this.
If you provide a hash, a malicious middleman could replace the content and the hash.

Providing a signature of the content / signing the hash allows the receiver to verify that YOU provided the original content / sent content wth hash x.

>>57781487
you would have to securely provide a hash for every file you want to sign, which is harder than securely providing a single public key to use for all your files

>>57784058
>you would have to securely provide a hash for every file you want to sign, which is harder than securely providing a single public key to use for all your files
If you're signing things with a key, you still need to provide a signature for each file.