Re: portable WoT IDs recoverable with a random password, implemented in pyFreenet

Florent Daigniere writes:

> On Thu, 2016-12-22 at 00:31 +0100, Arne Babenhauserheide wrote:
>> Hi,
>> 
>> I just finished the basic implementation of a longterm plan I had:
>> portable WoT IDs, recoverable with a random password.
>> 
>> → https://github.com/ArneBab/lib-pyFreenet-staging/commit/7a847a0e3db5
>> 0948ae2b65ff8171401a0cd0cd9b
>> 
>> Basic approach:
>> 
>> - Upload the private key to KSK@<common prefix>-<14 letter password>
>> --recovery
>> - Upload metadata to USK@<public key>/<14 letter password>--<type of
>> metadata>/-1
>> - recovery: download KSK, invert private key, retrieve metadata from
>> USK, re-create WoT identity
>> 
>> It would be great if you could doublecheck whether I missed anything
>> which would spill your private key. The current password has an
>> entropy
>> of 75 bits — is that enough?
>
> Enough for what?

For the usecase I explained: preventing attackers from finding private
keys via brute force attacks.

> https://www.keylength.com/en/3/

That site is great! I searched for something like this quite a bit…

Following the ECRYPT II recommendations, I should go for at least 160
bits, since I cannot use a salt.

However I’m not sure about this, because I do not have a good enough
grip on the cost for attacking KSK keys in Freenet. That’s why I ask.

> You are naive if you think that you can ask users to give you 75 bits
> they can remember but others can't guess.

Did you really think that I ask the user? I generate a random
password. How would I be able to give an entropy estimate otherwise?

>>  Is it somehow possible to decrypt parts of
>> the store at random in the hope of hitting a random uploaded private
>> key
>> (a variant of the birthday attack against the password which would
>> avoid
>> having to query the network for each check)?
>> 
>
> Of course it is. Your scheme is completely broken; at the very least the
> "passphrase" should be salted, hashed and iterated... and yes, that
> means getting the user to remember the salt too.

The passphrase must be as strong as would be needed for passphrase plus salt.

For hashing and iterating: Is that of practical utility when I’m
sticking the password into a KSK in the end? Isn’t the cost of attacking
the KSK much higher than the cost of hashing and iterating?

(this is my core question here: what’s the cost of attacking a randomly
generated KSK?)

Best wishes,
Arne
_______________________________________________
Devl mailing list
[email protected]
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl