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

Arne Babenhauserheide <arne_bab-S0/[email protected]> Fri, 23 Dec 2016 17:47:18 +0100
Newsgroups	gmane.network.freenet.devel
Message-ID	<[email protected]>
Arne Babenhauserheide writes:

> Florent Daigniere writes:
>
>> On Thu, 2016-12-22 at 11:22 +0100, Arne Babenhauserheide wrote:
>>> > >  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?)
>>
>> The answer is in src/freenet/keys/ClientKSK.java
>>
>> It's designed to be fast, not secure... so unless you iterate it, I
>> think that it is madness.
>
> I think I see how to address that (described in the next paragraph). But
> for the sake of sharing better practices than what I used, this is what
> I got wrong:
>
> - The decryption keys of WoT IDs have to be considered public knowledge,
>   so anything uploaded to USK@…/ can be attacked offline by trying to
>   decrypt locally stored chunks.
> - KSK does actually hash and iterate, but it is designed to be fast,
>   therefore the keys must be very long to avoid rainbow-table attacks,
>   and whatever is used in a KSK in large quantities must be iterated to
>   increase the cost of offline attacks on whatever the node has in
>   store. A salt could avoid that.
>
>
> I think the following improved design should address the issues:
>
> - The recovery secret will be of the format <creation year>/<part1>/<part2>
>   with part1 having about 45 bits and part2 having about 100 bits of entropy.
> - Recovery works in four steps:
>   - Retrieve KSK@<prefix><part1>--wotid. This contains <name>@<WoT ID>
>   - Use pbkdf2_sha256 from passlib[1] with <part2> as key and the 
>     <WoT ID> as salt to generate a secret with sufficient iterations to
>     make en-masse local storage decryption attacks infeasible. This
>     gives <salted-secret> 
>   - Retrieve KSK@<prefix><salted-secret>--insertkey. Use it as <insertkey>
>   - (Re-)create the WoT ID using <name> and <insertkey>.
>
> Example recovery secret:
>
>     2016/c1n8-83cE/aRUk*DDWL+4Sps_1LgM
>
>
> Do you see remaining problems with the scheme?

Asked differently: Does the concept look robust now? If yes, I’d like to
go for the implemntation.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

_______________________________________________
Devl mailing list
[email protected]
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
signature.asc (application/pgp-signature, 800 B)