[p2p-hackers] convergent encryption reconsidered

[James A. Donald]

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 majordomo at metzdowd.com