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.

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;

On 5/29/2018 1:57 AM, Adam Wilson via Digitalmars-d wrote:
> 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.

One of the pillars of crypto is that eventually a problem will be found with every algorithm, it's just a matter of time.  So, having just one available means that eventually the library will be horribly broken.  The corollary here is that having a fallback is pretty essential.

On 05/29/2018 11:29 AM, Brad Roberts wrote:
> 
> On 5/29/2018 1:57 AM, Adam Wilson via Digitalmars-d wrote:
>> 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.
> 
> One of the pillars of crypto is that eventually a problem will be found with every algorithm, it's just a matter of time.  So, having just one available means that eventually the library will be horribly broken. The corollary here is that having a fallback is pretty essential.

Sure. For example, TLS 1.3 supports AES, Camellia, ARIA, and ChaCha20-Poly1305 for symmetric ciphers. However, when you look at the best-practice recommendations, AES is the clear winner. And when you look at what actually gets used, it's AES. AES is the Gold Standard and it would take a fundamental breakthrough in cryptanalysis for that to change.

But what happens to TLS1.3 if there is a fundamental breakthrough?
- ARIA uses an AES derived substitution-permutation network.
- Camellia uses the same S-box that AES does. (It was an AES contender)
- Poly1305 for ChaCha20 directly uses AES in it's PRF.
Which algorithm do you switch to? Anything that breaks AES can also be used against these other algorithms. In this case, ChaCha20 is probably the best answer, but only if you apply a different MAC to it.

It's a good thing that a fundamental breakthrough in cryptanalysis is unlikely in the foreseeable future. Of course, that's what we told ourselves before 3DES and Differential Cryptanalysis.

I don't disagree with you. But the overwhelming cacophony of choice presents it's own issues. (See: The Paradox of Choice) SecureD v2 could easily support these ciphers, and I don't really have a problem adding them for the purposes of compatibility. But the default is going to be AES for the forseeable future. The design premise of SecureD is to make the the safe defaults easy and everything else hard.

In cases where there are known weaknesses SecureD does intend to support multiple algorithms, but usually only two, for example SHA2 potentially suffers from the same weaknesses as SHA1, and as a result SecureD v2 will be getting SHA3 support whenever OpenSSL 1.1.1 drops. But it's not going to add things like Whirlpool or Skein.

Or RSA versus ECC. I am considering adding Curve25519 support to v2, but with NSA/NIST deprecating ECC altogether (as it is less resistant to quantum computing than RSA, see: https://en.wikipedia.org/wiki/Elliptic-curve_cryptography#Quantum_computing_attacks) it may be better to wait-and-see what comes of the work being done on quantum-resistant public-key cryptography. The new Supersingular Isogeny Diffie-Hellman (SIDH) looks like a strong contender, but nothing implements it, and it's way too new to put any trust in it yet.

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