Logs can be modified in real time by being intercepted during writes to the buffer before the new hash is applied. Because of this, only the logs up to the intrusion can be preserved, and even then if the old message/hash/key/etc is still in memory, the old messages can be modified.
The only truly secure way to record messages up to the point of break-in is a one-way remote log. Any new messages after break-in is subject to falsification.
The fancy cryptologic syslogd is fallible as I mentioned previously, so why depend on it? And really if you really want to cover your tracks you can just cause random disk corruption over the whole disk (and just happen to damage the journal in the process). Things will start failing rapidly, fsck will later show itself fixing the disk corruption, and it will be assumed to be a hardware error and the incident ignored.
Security half-measures do not mean you are secure. If it can be hacked, it will be hacked, and then what was the point of sacrificing your whole system's init system?
(Also you could just replace syslogd with a journaled syslogd, rather than replacing your entire init system... but I guess that's off-topic?)
The only truly secure way to record messages up to the point of break-in is a one-way remote log. Any new messages after break-in is subject to falsification.