Michael Bell wrote:
BTW we tested signed logs already and they are only really usable if you
have an accelerator for the crypto operations.
what about - (collected) hashing? and then signing those hashs?
like: hash last ten entries - then sign ones
hash last ten minutes - then sign ones
or: hash and sign all logentries for one operation
since sometimes there is a lot logging during one operation
would mean to keep the log-msg a bit longer in memory to be able to hash
and sign them afterwards this should reduce the ammount auf real
haevy-crypto operations and therefore the workload of the cpu
another idea is to - just hash and send those hashes to a second place
(another machine for example) this usaly works like: take the new data
and the last hash and generate a new hash... this would also work with
the first option: and you just sign every x hashs... but you hash every
log entry, so manipulations should be detectable (if someone tries to
change the logs later on - the hashes would mismatch)
an atacker must then be very fast and have total control about the
software, so the signing would be also not safe anymore...
an atacker can only manipulate log entries between the last signed hash
till the next signing, he has to change logentries and recalculate the
'accumulating' hashes to get consistent... i think this should be quite
difficult... you have to manipulate nearly in realtime - this would also
break the normal signing aproach
greetings
dalini
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
OpenCA-Devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/openca-devel
