1. There isn't really any reason to not at least *allow* PBKDF2-SHA512 as one of the available KDFs.
How many iterations do you suggest if we were to add this as one of the KDFs?
2. It would be easier for embedded and mobile devices if Scrypt wasn't mandatory.
3. The Scrypt with parameters 10,1,1 might as well be replaced with PBKDF2-SHA512.
Very well, I'll see if I can rework it to use PBKDF2-SHA512 for the
preH and postH sorry, I meant for H.
Alternate bloom filter proposal:
filter = 0 # 32 bit integer
valid_passwords = [user_password, fake_password] # Can be any number of passwords. To preserve plausible deniability of all users, the spec should mandate a randomly generated fake password if the user doesn't want one
for password in valid_passwords:
hash = strongH(password, "") # strongH is the user-selected KDF. Fixed/no salt used. See below.
for i in range(0,11):
filter |= 1 << (hash[i] & 0x1F) # Sets a random bit in the filter to 1
It's acceptable to use strongH without a salt here, because we're only revealing 10 or fewer bits of the password hash. We're not revealing enough information about the password to do any damage. This means the bloom filter is a function of *both* passwords (one of which may be random), so it still adds useful entropy to the salt.
This means doing the strong hash multiple times and not being able to outsource it. I think it's fine to use something like a double SHA256 here. It's not going to leak anything useful anyway.