Ivan Krsti? wrote:
1. take partially known plaintext
2. make a guess, randomly or more intelligently where possible,
   about the unknown parts
3. take the current integrated partial+guessed plaintext, hash
   to obtain convergence key
4. verify whether that key exists in the storage index
5. if yes, you've found the full plaintext. if not, repeat from '2'.

That's a brute force search. If your convergence key, instead of being a simple file hash, is obtained through a deterministic but computationally expensive function such as PBKDF2 (or the OpenBSD bcrypt, etc), then step 3 makes an exhaustive search prohibitive in most cases while not interfering with normal filesystem operation. What am I missing?

Better still, have a limited supply of tickets that enable one to construct the convergence key. Enough tickets for all normal usage, but not enough to perform an exhaustive search.

Assume a small set of ticket issuing computers hold a narrowly shared secret integer k. Assume a widely shared elliptic curve with the generator G.

If h is the hash of the file, the convergence key is h*k*G.

If you give the ticket issuing computers an elliptic point P, they will give you the corresponding elliptic point k*P. If, however, you ask for too many such points, they will stop responding.

Of course, this allows one to be attacked by anyone that holds the narrowly held key.

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to