On Sun, Mar 30, 2008 at 05:13:07PM -0400, Ivan Krsti?? wrote:

> 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?

PBKDFS2 is excellent for turning interactively typed pass-phrases into
keys. It is not entirely clear that it is a good fit for a filesystem.
Updating any single file is now a computationally intensive process, the
performance impact may be unacceptable. With PBKDF2 and the iteration
count set to the for now popular "1000", a 64K byte file will now trigger
~~2 million sha1 compression function computations (if I remember the
sha1 block size correctly as 512 bits or 64 bytes).

A crude cost estimate on typical hardware (openssl speed):

    Doing sha1 for 3s on 8192 size blocks: 57316 sha1's in 3.00s

Extrapolating from this, on 64K sized files, we get ~1200 HMAC operations
per second. If we iterate that 1000 times, 1.2 key derivations per
second. The throughput to disk is CPU bound at ~64KB/s, which is rather


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

Reply via email to