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]
