Say I have 55 files. 5 are data files, 1 of which stores the hashes, 50 are scripts.

I need to build an IDS for the files themselves which constantly opens the dedicated hash file, reads the hashes, then checks the files they were calculated from to assert a match. If it fails. an intrusion has occurred and the SysAdmin is notified.

This is where I start to have issues.

After running an external, local script on the other 54 files, I store their hashes in the 1 dedicated hash file. Now, I need to calculate the hash of this dedicated hash file, as if the hash of itself is already in itself.

I have no idea where I would begin other than a "brute lockdown" method, which is not viable as I need to take as little clock time, CPU Cycles, and disk time as possible.

Bonus points for prediction and storage of encrypted hashes.

Also, Apologies for any confusion, I can't explain very well.

Update: I was asked to explain the problem, and why this solution would solve it, so, here goes.

Problem: Say I have several terabytes of personal information on people from all over the world that is stored securely on a server, and even more securely transmitted to client software as needed. High value information, at that.

The encryption is more than covered - to the point that anyone who was hell-bent on getting this information would make an attempt to modify the scripts that secure, read, and write the data over attempting to undermine the encryption.

This raises the issue of detecting when these script files are modified on the fly, assuming the malicious person can physically access the server.

Most event logs are insecure and untracked, so they could be easily erased. Any network transfers to detect changes would fail, as even the most secure data wouldn't be hard to crack when you have the source in front of you. You can't trust humans - ever, and the server farms aren't owned by me, so physical security is out of the question.

How the solution would fix it: The IDS would run once every 10ms, scanning the files to make sure the hashes match the ones on record. Assuming one update every three months to the scripts and data, the hashes and updates would come pre-packaged, so they couldn't be modified by the program itself outside of the development environment. This would be verified once every system boot, but again, this data could be modified with physical access, however, with routine remote checks running every few minutes, shouldn't be a major issue.

TL;DR: the issue boils down to making an unaccessable, uncrackable source, and data network eliminating all potential problematic variables from RAM dumps, to remote execution, to physical modification.

Apologies for the rambling.

  • Without brute force, you can't (I'm not sure it will be possible with brute force anyway) Jan 4, 2017 at 7:15
  • Thanks for the quick response! Do you have enough evidence to back the claim to post it as an answer? I felt that may be the case, but I don't want to overlook anything, either. Jan 4, 2017 at 7:18
  • The usual way to do this is to calculate the hash of the file without its own hash, then append that hash to the end of the file. To verify, strip the last line of the file then hash the rest. Jan 4, 2017 at 7:30
  • I consider that to be insecure, as that's just a minor annoyance to anyone who wants the data. Jan 4, 2017 at 7:40

1 Answer 1


You can't. If you could, it would defeat the preimage resistance of the hashing function - you would be finding an input which corresponded to a given hash, effectively.

Additionally, if you could, so could an attacker, meaning they could generate a valid hash for any files they modified.

As worded, this question sounds like you've come up with a solution, but it might not be a viable one - it may be better to explain the problem that your solution attempts to solve, and see if anyone can suggest a more viable method.

  • Updated. Does that help any? Jan 4, 2017 at 7:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .