Hi Andrey,

On Fri, Sep 8, 2017 at 8:14 AM, Andrey Andreev <n...@devilix.net> wrote:

> Hi,
>
> On Fri, Sep 8, 2017 at 12:32 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> >
> > The reason why latter is a lot more secure is related to Andrey's
> > misunderstanding.
> > He said "when ikm is cryptographically strong, salt wouldn't add no more
> > entropy.
> > so salt does not matter". (not exact sentence)
> > What he said partially true, but wrong in a sense of key security.
> >
>
> I have never said that. You are aware enough of your own English
> fluency, and should know not to perephrase other people's words, as
> you are completely twisting their meaning.
>


My words:
-------
He said "when ikm is cryptographically strong, salt wouldn't add no more
entropy. so salt does not matter". (not exact sentence)
-------

This is your exact words.
------
And this doesn't stop at passwords. Please note that this paragraph
explicitly states this:

   The extract step in HKDF can concentrate existing entropy but
cannot amplify entropy.

Which means that it is NOT designed to do key stretching, or in other
words it should NOT be relied upon to produce strong outputs from weak
inputs - the exact scenario for which you wanted to make salts
non-optional.
-------

Although you are referring other sentences from somewhere, it is obvious
this is your thought as well.

Note for others:  "The extract step in HKDF can concentrate existing entropy
 but cannot amplify entropy." is not came from the RFC. If a RFC states
this I would be stunned. Please read on you'll see the evidence.



> >
> > Other misunderstanding should be noted is what HKDF for. It's for general
> > purpose KDF as the RFC described in HKDF application section. Andrey said
> > "I'm cherry picking sentence", but the section should be what the HKDF
> for.
> > The section even describes obscure usage, HKDF for CSPRNG. This usage
> > is not even key derivation.
> >
>
> You ARE cherry-picking, and ignoring all evidence that contradicts you:
>

HKDF is general purpose KDF by its design, obviously.
The RFC has "Application of HKDF" section that states

RFC 5680 - https://tools.ietf.org/html/rfc5869#section-4
---------
 HKDF is intended for use in a wide variety of KDF applications.
---------

"Wide variety of KDF applications" even includes non KDF operation like
CSPRNG. Your  statement makes no sense.



> > This one I'm not sure misunderstanding or not, but probably it is.
> > HKDF is designed for any ikm and works with appropriate usage. Very
> > weak ikm like user entered password can be handled relatively safely.
> >
> > $safe_key = hash_hkdf("sha256", 'mypassword', 0, '',
> > $csprng_generated_random_key);
> > // $csprng_generated_random_key should be kept secret because ikm is too
> > weak
> >
> > Without salt, it's disaster. Please note that salt is the last optional
> > parameter currently.
> >
> > $dangerous_key = hash_hkdf("sha256", 'mypassword'); // Disaster!
> >
> > With this usage, attackers can build pre hashed dictionary. Even when
> they
> > don't have
> > dictionary, usual brute force attack is very effective. One may think
> > additional hashing
> > would mitigate risk. i.e.
> >
> > $dangerous_key = hash_hkdf("sha256", hash("sha256", 'mypassword')); //
> > Disaster!
> >
> > This does not help much when algorithm is known to attackers. Brute force
> > attack is
> > effective still. Adding secret salt(key) helps with this usage also.
> >
>
> IKM must always be strong; this is explicitly stated in the RFC, as I
> already pointed out here: https://externals.io/message/98639#98874
> And the reasons why were already explained in very simple terms here:
> https://externals.io/message/98250#98272
>
> Enough already.
>


Weak key is allowed by the RFC.
These are sentences from the RFC.

RFC 5689 - https://tools.ietf.org/html/rfc5869#section-3.3
--------
In some applications, the input key material IKM may already be
present as a cryptographically strong key (for example, the premaster
secret in TLS RSA cipher suites would be a pseudorandom string,
except for the first two octets).  In this case, one can skip the
extract part and use IKM directly to key HMAC in the expand step.
---------
Note: expand step is HKDF-Expand(PRK, info, L) -> OKM, which is supposed
to expand length of resulting hash.

Obviously, your statement is wrong.

If I'm reading it correctly, salt may be omitted only when input key is
already strong.
i.e. This means weak key and strong salt results in strong PRK where PRK =
HMAC-Hash(salt, IKM)

However, "may be omitted" does not mean users should omit salt even with
strong IKM, because the RFC strongly recommends salt for significantly
better key security with other sentence.

Sorry Andrey, but I have to say you don't read the RFC at all or don't
understand it at all. My apology for strong words, but I was polite enough
until now even with your nonsense and offensive replies.

Regards,

P.S. I thought,  HMAC produces strong hash with strong key even for
extremely weak message, is common sense, but apparently not. Note for
others: HKDF is made by HMAC.

--
Yasuo Ohgaki
yohg...@ohgaki.net

Reply via email to