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;
