Ok, let me wind this up (kind of)... What I was hoping for was some sort of summary about where current implementations of a syslog daemon fall short of providing adequate information to be of forensic value. In the binary data files nsyslogd creates, it recorded, per syslog msg: - mac - time (second granularity) "received" by first nsyslogd - priority - hash count - syslog line # count - file count Hmm, so I never did encryption (it seems) but I think I understand why: 1 bit or byte of trashed encrypted data ruins the rest. Or maybe it was because of export reasons or something else. The aim is not to prevent change, but to detect it and be able to prove that the integrity of the data is in fact intact. Oh, the problem is discovery of the hash seed creates a weakness but unless you start over each time and require a secret input with each startup (operationally troublesome), its just a risk you have to accept. The three counters are kept because once you start off, you need to be absolutely certain of the order the data was received in. Where do you see this falling short of being suitable for forensic evidence ? Something different it did was initialise the hashing by hashing for a second and recording how many times that happened (hash count), so on a P4 3GHz, if someone was to initialise it, brute forcing would still force someone to spend at least 1 second per guess with a P4 3GHz. Darren _______________________________________________ LogAnalysis mailing list LogAnalysisat_private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Fri Dec 06 2002 - 10:43:32 PST