Here's the scenario I'm trying to solve:

In my application, users provide files to other users.

I want to provide a way of verifying that files have not been tampered with.

I wonder if this means some sort of third party, independent online data store of file signatures can be referenced to ensure all is OK.

I don't know much about this, what's a good way to do it?


6 Answers 6


The concept you're looking for is known as a digital signature or message authentication code (MAC).

A relatively simple way to achieve this that “only” needs a collision resistant cryptographic hash function as ingredients is provided by keyed-hash message authentication codes (HMACs). However, it has the disadvantage of any symmetric cryptography that in order for two parties to verify their signatures, they first have to exchange the secret key via a trusted communication channel. If a trusted central party exists, a protocol like Kerberos might be used for this.

In the scenario you describe, where there are many parties involved, it seems more appropriate to use asymmetric cryptography. This way, it will be sufficient for each party involved to distribute its public key that can then be used by any other party to verify signatures made by it. How this distribution works is still not trivial. If your system already has a trusted central party, it could act as a key-server where each party can retrieve public keys of other parties over a secured connection like TLS. A more decentralized way would be to use a web of trust.

If you want to use signatures based on asymmetric cryptography, avoid re-inventing the wheel and use tried and trusted software like the GNU Privacy Guard (GnuPG) that can already do this. (See the section “Making and Verifying Signatures” in the manual.) It also has a support library called GPGME that is intended to be used by third-party applications that want to use GnuPG internally.

  • If you have a trusted root authority, it's not required that the public keys be distributed from a central source or that they be delivered securely. The fact that the trusted root CA has signed the certificate is generally enough for the cert to be validated (ignoring revocation concerns.) The certificate can be delivered with the payload or retrieved directly from the sender.
    – JimmyJames
    Aug 17, 2016 at 17:30
  • @JimmyJames Yes, that's true. You'd also want a revocation process in this case, though. GPG provides both.
    – 5gon12eder
    Aug 21, 2016 at 15:28

I wonder if this means some sort of third party, independent online data store of file signatures can be referenced to ensure all is OK.

And how does anybody know whether the collection of file signatures has been tampered with?

That is the problem that is supposed to be solved by a Certificate Authority (CA). There are a small number of companies who are widely trusted, and whose public signature keys are widely known. You pay one of them to wrap your public signature key and details of your identity in a digital certificate, and then you disseminate that to your end users.


Your end users can use the CA's well known public key to verify the information in your certificate, and then they can use the public key contained within the certificate to verify the files that you sent them.

It all works wonderfully well provided that the CA does an adequate job of verifying that you really are who you say you are when you ask them for a new certificate. (I.e., You woudn't want them to issue a new certificate in your name to some random hacker who is pretending to be you.)


Public a sha256 hash of each file. The receiving end must pass the file through the same has function the see if they match. If they don't match, the file is not the original file.

  • 2
    Un-keyed hashes can only help detect accidental modifications. If an attacker can spoof the file that is sent to you, it can likely also spoof the hash. If you publish a hash of the real document and I publish one of a tampered version. How can a third party reliably tell them apart? The hash does not encode any information about the party that produced it. There is also a number of other unsolved problems like how exactly does the receiver look up the hash value.
    – 5gon12eder
    Aug 7, 2016 at 23:46
  • @5gon12eder the hash must be published in the official site of the files. Aug 7, 2016 at 23:48
  • @TulainsCórdova This is subject to MITM attacks. You would need to secure access to the hash to make it secure.
    – JimmyJames
    Aug 17, 2016 at 18:12

You could use RSA: encrypt with the sending users private key, decrypt with the sending users public key. What would be best really depends on your specific use-case, which I don't think we have enough information about to give an informed opinion.

  • While there is a digital signing algorithm based on RSA, it doesn't work like this. In fact, (textbook) RSA is homomorphic so a ciphertext is malleable and cannot be used as a proof of authenticity. Also, you would normally not use RSA for encrypting a whole document but employ a hybrid scheme. This leaves you open to further attacks if not done properly. I'm not saying that these problems cannot be solved but if they weren't obvious to you, this might be a convincing reason not to invent your own cryptography.
    – 5gon12eder
    Aug 11, 2016 at 23:35

In your scenario there is a vague point. Does a user send the same file directly to others or users download a file from a common place and you want to see whether local copies are changed?

What others have suggested works perfectly but increases complexity. A simple and common way to check the files is to calculate the checksum (md5) of the file and then compare it to each local copy.

But this means you have some sort of app that can perform this check.


Put the public keys of the digital signatures of the files on to a blockchain. With the hash of each file next to it, as a reference.

Not the answer you're looking for? Browse other questions tagged or ask your own question.