| |||||||||||||
Forward secure sealingForward secure sealingPosted Aug 25, 2012 1:48 UTC (Sat) by Cyberax (✭ supporter ✭, #52523)In reply to: Forward secure sealing by dlang Parent article: Forward secure sealing
You can't recreate everything, as your key is time-dependent. It'll be obvious that timestamps inside the faked blocks and the key-derived timestamps are different.
(Log in to post comments)
Forward secure sealing Posted Aug 25, 2012 2:01 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
only if you have a way of knowing
A) which of the keys was used to sign this block
and
B) which key should have been in use at that time
If such technology exists, I'm very interested in learning about it. But I would have expected that technology like this would be in use for things much more significant than just logs.
Forward secure sealing Posted Aug 25, 2012 2:12 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
>A) which of the keys was used to sign this block
? You know this, otherwise signature can not be validated.
> B) which key should have been in use at that time
Suppose that you have the initial key (key_0) constructed on 24 Aug 2012, 00:00 UTC. You encode the key update interval (say, 10 minutes) in this key and start using it. Every 10 minutes you then generate the next key and use it for signing.
Each signed block is numbered, without gaps.
If it turns out that your current system time is ahead of the key's time (because you've resumed your computer from a long sleep) then you insert a special "skip-time" block, signed by your existing (and now obsolete) key and the time-derived key. I.e. that block in essence authenticates a legitimate gap in the log history.
Again, I'm making it up as I go along :) So I might be incorrect.
Forward secure sealing Posted Aug 25, 2012 3:22 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
are you sure? it could be that you know that it's signed by A valid key, but not know which one. I really don't know how this sort of "many signing keys, one verification key" setup works. I'm interested to learn.
I am assuming that this is an asymmetric key, and so knowing the validation key does not let you know the signing key. If that's not the case, all you would need to do is to seed a PRNG and use the output as your symmetric key along with a generation number. That wouldn't be nearly as good as as if this is an asymmetric key.
your 'skip time' log entry does you no good if you don't have logs from all time (what happens when you delete the 'skip time' log entry), you would have to chrun thorugh however many key generation cycles you need to get you to the valid key (and hope that time never goes backwards on your box) as was noted by someone else on this thread.
we can speculate and design what we think is a valid algorithm here, but we don't know if that's what's being implemented in this case.
|
|||||||||||||