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

[Michael Pyne]

> 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.
> 
> Àlex Fiestas wrote:
>     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.

CRYPT is even worse :), at least if it's talking about UNIX crypt (which uses iterated DES and has very short bitlength).

There's nothing wrong with PBKDF2 (scrypt even uses it internally), the big difference is that scrypt tries to consume memory in addition to CPU to try to make it harder to bruteforce. It's not perfect at this either though (GPU is still the best way to crack scrypt, as the Litecoin devs found out). I'd leave the choice up to you as I'm not qualified to give professional crypto advice so if it is easier to find good guidance on how to securely use PBKDF2 I'd leave it at that.

I'll look at the new diff but would still want valir or an actual maintainer to give the "Ship It!", the crypto part only happened to catch my eye from kde-core-devel. ;)


- Michael


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


On Feb. 6, 2014, 3:28 p.m., Àlex Fiestas wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115497/
> -----------------------------------------------------------
> 
> (Updated Feb. 6, 2014, 3:28 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/9d2dd267/attachment.htm>