| |||||||||||||
Forward secure sealingForward secure sealingPosted Aug 25, 2012 3:27 UTC (Sat) by dlang (✭ supporter ✭, #313)In reply to: Forward secure sealing by nybble41 Parent article: Forward secure sealing
Ok, the formula you provided will work to generate a symmetric key, Simply using the "verification key" as a seed for a PRNG will do that much (and since the sequence will be unique, walking through the sequence until you find something that matches will work)
However, I was assuming that this was some form of asymmetric key, since that's the norm for signing something. The problem with using a symmetric key is that the person trying to validate the signature is also in a position to forge the signature.
(Log in to post comments)
Forward secure sealing Posted Aug 25, 2012 3:41 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
by the way, this approach would result in pretty unusable validations for a system that's been running a long time.
if you are on key 9834750927 and need to iterate through that key generation routing that many times to get you from the starting validation key to the key needed to validate the file, it's going to take a long time.
Forward secure sealing Posted Aug 25, 2012 4:54 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
You can adapt this for public/private keys as well.
And you can easily walk through the keys. If you do log sealing every minute then key 9834750927 would be some time after 20711.
Given that AES on modern CPU works can produce about 1Gb of data per second, it'll take only a few minutes to walk to that point.
Forward secure sealing Posted Aug 25, 2012 19:00 UTC (Sat) by nybble41 (subscriber, #55106) [Link]
> The problem with using a symmetric key is that the person trying to validate the signature is also in a position to forge the signature.
Yes, but that doesn't matter here, since the person doing the validation is also the person who administers the server; they're _already_ in a position to forge log messages, if they cared to do so.
You are correct that the signing key is basically just the output from a PRNG, but the PRNG does need to have a special property that some PRNGs lack: the computation must only work in the forward direction. Given the internal state of the PRNG, it must not be possible to go back to a previous state and generate a past signing key.
For example, both the following functions will produce a stream of pseudo-random numbers:
F[0] = HASH(seed)
G[n] = HASH(seed + n)
However, only the former PRNG would be suitable, because computing G[n] requires the original seed value, and given the seed you can compute any G[n], past or future.
|
|||||||||||||