Review Request 115497: Replace SHA with PBKDF2-SHA512+Salt

[Àlex Fiestas]

> On Feb. 5, 2014, 7:18 p.m., Michael Pyne wrote:
> > kwalletd/backend/kwalletbackend.cc, line 130
> > <https://git.reviewboard.kde.org/r/115497/diff/1/?file=242022#file242022line130>
> >
> >     The salt here seems to be based off of the user's login-name, which can change (for instance, someday my KDE git user account will change away from "kde-svn"... I've just been lazy so far ;).
> >     
> >     Beyond that the salt should really be random bytes otherwise you could still build rainbow tables of the top-100 most popular user names, for instance.
> >     
> >     Using random bytes would complicate this since you'd have to actually store the salt and re-load it to re-derive the right key, but it's the right way to do it.
> >     
> >     In any event it's probably more important to ensure that there's no data loss if the user tries to open their wallet under a different UNIX login, even if we have to use a plain constant string as the salt.

I decided to use the username because this hash will be produced from a pam module as well, accessing users data from there is kind of messy and we will have to generate and then chown that salt so I decided to go with a shortcut for the time being.

Will implement proper salt in a future patch if that's ok for you.


> On Feb. 5, 2014, 7:18 p.m., Michael Pyne wrote:
> > kwalletd/backend/kwalletbackend.cc, line 129
> > <https://git.reviewboard.kde.org/r/115497/diff/1/?file=242022#file242022line129>
> >
> >     libgcrypt supports the "scrypt" key derivation function since 1.6.0, and we require 1.6.1.
> >     
> >     Since scrypt is superior in almost all respects to PBKDF2 I'd recommend using it instead since we're improving KDFs here anyways. More info at http://www.tarsnap.com/scrypt.html
> >     
> >     There are "side channel" attacks possible with scrypt by its design that don't occur with PBKDF2, but there shouldn't be malicious code running on the user's system at the same time as they're opening the wallet anyways (if that's the case we have bigger problems).
> >     
> >     The "bcrypt" algorithm is apparently even better for this particular use case, but it doesn't appear to be available in libgcrypt.

The reason why I went with PBKDF2 instead of SCRYPT is because the later seems less established than the first, lacking a lot of user based feedback like for example a recommended amount of iterations.

So, to what should I change it to? CRYPT with 200 iterations?

200 on my workstation take around 500ms.


- Àlex


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115497/#review49065
-----------------------------------------------------------


On Feb. 5, 2014, 3:10 p.m., Àlex Fiestas wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115497/
> -----------------------------------------------------------
> 
> (Updated Feb. 5, 2014, 3:10 p.m.)
> 
> 
> Review request for KDE Runtime, Teo Mrnjavac and Valentin Rusu.
> 
> 
> Repository: kde-runtime
> 
> 
> Description
> -------
> 
> Uses the MINOR_VERSION (which until now it was 0) to upgrade the hash from SHA to PBKDF2-SHA512+salt.
> I would have loved to completely replace it once the wallet is ported to the new hashing but because
> of kwalletd code that is not possible without a bigger rewrite.
> 
> There are 2 reasons for this patch:
> 1-We avoid using our own implementation of SHA
> 2-We use a modern hashing technique
> 
> I'm cooking more patches to use the system user password to open the wallet, we want that password to be
> hashed using PBKDF2_SHA512 for security reasons.
> 
> 
> Diffs
> -----
> 
>   CMakeLists.txt 275a6c7 
>   cmake/modules/FindLibGcrypt.cmake PRE-CREATION 
>   kwalletd/backend/CMakeLists.txt 5a5837c 
>   kwalletd/backend/backendpersisthandler.cpp bdef6ca 
>   kwalletd/backend/kwalletbackend.h 83ebf7f 
>   kwalletd/backend/kwalletbackend.cc e4d461c 
> 
> Diff: https://git.reviewboard.kde.org/r/115497/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Àlex Fiestas
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20140206/b156d95c/attachment.htm>