SecureD Futures (v2.0)

Adam Wilson flyboynw at gmail.com
Tue May 29 08:57:54 UTC 2018


On 05/28/2018 04:02 PM, sarn wrote:
> On Monday, 28 May 2018 at 07:52:43 UTC, Adam Wilson wrote:
>> I understand that.
> 
> Sorry, not for nothing, but you obviously don't.  For starters, if you 
> were familiar with the key derivation tools available 24hrs ago, you 
> wouldn't have come up with PBKDF2 on PBKDF2.  I suggest slowing down a 
> little, and asking people on a crypto forum if you're still not sure.  
> If you explain your problem from the start, they might even have some 
> better ideas.
> 
> When that RFC (correctly) recommends using a salt, it's talking about 
> HKDF-Extract, which is a tool for taking a large amount of mostly-random 
> data and turning it into an appropriate KDK. That's not the problem you 
> have here.  The problem you have is generating keys for different 
> purposes from a KDK.  That's a problem HKDF-Expand addresses, and it 
> doesn't use a salt.
> 
>> Let me ask the question a different way. What is the reason NOT to use 
>> 2 different salts for the MAC and KEY generation steps?
> 
> You might choose to not use extra salts for the same reason you've 
> already chosen to not encrypt three times, or add extra HMACs for each 
> individual block of ciphertext: it's not solving any problems.

Ok, but I am not harming anything either. I asked specifically what 
would be reasons not to do something, you replied with "it's not solving 
any problems". In a technical sense you are correct. I am not solving 
any problems. However. I am not creating any either. Adding a salt to an 
HKDF does not hurt anything. Ever.

As to the PBKDF2 comment. I'll concede that I am not perfect. Which is 
why I asked for input and I obviously "slowed down" enough to bother to 
ask. And when my mistake was pointed out I corrected it without further 
comment. We make all make mistakes sometimes, and cryptography is much 
harder than most to get right. So when we aren't sure we ask. And my 
statement was posed as a question. I was inviting feedback.

One of the pillars of SecureD is that ONLY safe, well-known, algorithms 
are presented. If reasonable we will only present one algorithm for a 
specific purpose. If there is a good reason to add more than one 
algorithm, we will.

For example, I am well aware of the BCrypt/SCrypt family as well as 
Argon2. At this point Argon2 appears to be the heir-apparent. Sadly, 
Argon2 is so new that neither Botan or OpenSSL implement it. So that one 
is ruled out for practical purposes, at least for now. I would also like 
to point out the OpenSSL will never implement BCrypt, but does implement 
SCrypt, and an Argon2 implementation is an open question due to it's use 
of threads.

It turns out the key-stretching field is very active right now, and 
precisely what will become the de-facto standard is impossible to say. I 
don't feel comfortable trying to pick a winner to implement. For the 
moment, PBKDF2 is stable, broadly implemented, and most importantly, 
well-understood. SecureD v2 will default to 1,000,000 iterations which 
yields roughly 650ms on an Intel 8700K. As older hardware is unlikely to 
be as fast, times of over one second could be seen in production while 
still providing some buffer against the future. That said the default 
PBKDF2 method will be tune-able.

I have long hoped for a reasonable replacement for PBKDF2, and with all 
the recent activity it is likely that something will shake out. But the 
attacks against Argon2 coming out so soon after it's release do not bode 
well for it in the future. And SCrypt requiring 16MB of RAM to achieve 
BCrypt's security makes it challenging to recommend for use on servers, 
especially in today's cloud environments where memory costs money. I 
know PBKDF2 is the conservative choice, but SecureD is all about 
conservative. For the moment, there aren't any great options, so 
conservative wins by default.

SCrypt Memory Math:
Assuming a 4GB VM in the cloud and we are willing to dedicate 1GB to 
SCrypt per second at BCrypt equivalent security.
1024/16=64
That's 64 connections per second, that is ... not great. And dedicating 
1/4 of your systems RAM just for password hashing is being very 
generous. You're not going to see that in production because it is 
terribly expensive.

As PBKDF2 and SCrypt are the only key-stretching algorithms available in 
both OpenSSL and Botan, and I cannot recommend SCrypt for cloud/server 
scenarios. PBKDF2 it is.

To be perfectly honest, key-stretching is a mitigation. Weak passwords 
will be easily guessed no matter what algorithm is used. The real fix is 
to force better passwords.

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;


More information about the Digitalmars-d mailing list