5 ms·

Possible variant on this scheme to make it harder to estimate the amount of time required: Don't use a fixed number of hash iterations. Instead, use a bitcoin-i

by earlz 13y ago

Possible variant on this scheme to make it harder to estimate the amount of time required: Don't use a fixed number of hash iterations. Instead, use a bitcoin-ish scheme like: "the key to this file is given by hashing 'xxxx' until the hash's bottom 8 bits are 0"

simias 13y ago
The problem here is that the amount of work needed to generate the key is not known beforehand either. I think a better approach (that would also not leak bits of the key) would be to say "hash until the hash of the hash is xxx". So basically you hash until you get xxx and then take the previous iteration's result as a key.
- zeckalpha 13y ago
  Given a sequence of N hashes, you could select any hash A as the initial hash, any hash B as the key, and the successor of B (C) as the key to the key. After choosing B and C, choose an A whose distance to B and C is proportional to the amount of work you wish to require.
  - simias 13y ago
    Your "given a sequence of N hashes" is a bit of a deus ex machina here :)
    - zeckalpha 13y ago
      Create it using 50% of your lifetime. Or create one for your children.
tlrobinson 13y ago
I don't see how this would work. What key is the encryptor supposed to use to encrypt?
tetha 13y ago
This should still be fairly parallelizeable, shouldn't it? You go ahead and take a number of crackers. Each cracker starts with a random hash and randomizes it for a fixed number of times, or until the bottom 8 bits of the hash are 0. Once it is done hashing, it goes to a central database and stores it's hash sequence. After that, it picks another hash which is not contained in a hash sequence and repeats the process. Finally, you'd probably have one node just doing the boring hash iteration while checking if it can skip according to the generated hash sequences from the database. I haven't done any math how much of an improvement this would be, but I would suspect a pretty decent improvement given enough nodes.

by earlz 13y ago

simias 13y ago

The problem here is that the amount of work needed to generate the key is not known beforehand either. I think a better approach (that would also not leak bits of the key) would be to say "hash until the hash of the hash is xxx". So basically you hash until you get xxx and then take the previous iteration's result as a key.

zeckalpha 13y ago
Given a sequence of N hashes, you could select any hash A as the initial hash, any hash B as the key, and the successor of B (C) as the key to the key. After choosing B and C, choose an A whose distance to B and C is proportional to the amount of work you wish to require.
- simias 13y ago
  Your "given a sequence of N hashes" is a bit of a deus ex machina here :)
  - zeckalpha 13y ago
    Create it using 50% of your lifetime. Or create one for your children.

tlrobinson 13y ago

I don't see how this would work. What key is the encryptor supposed to use to encrypt?

tetha 13y ago

This should still be fairly parallelizeable, shouldn't it? You go ahead and take a number of crackers. Each cracker starts with a random hash and randomizes it for a fixed number of times, or until the bottom 8 bits of the hash are 0. Once it is done hashing, it goes to a central database and stores it's hash sequence. After that, it picks another hash which is not contained in a hash sequence and repeats the process. Finally, you'd probably have one node just doing the boring hash iteration while checking if it can skip according to the generated hash sequences from the database. I haven't done any math how much of an improvement this would be, but I would suspect a pretty decent improvement given enough nodes.