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.