Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:100460 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 28907 invoked from network); 8 Sep 2017 06:50:02 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 8 Sep 2017 06:50:02 -0000 Authentication-Results: pb1.pair.com header.from=yohgaki@ohgaki.net; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=yohgaki@ohgaki.net; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain ohgaki.net designates 180.42.98.130 as permitted sender) X-PHP-List-Original-Sender: yohgaki@ohgaki.net X-Host-Fingerprint: 180.42.98.130 ns1.es-i.jp Received: from [180.42.98.130] ([180.42.98.130:36832] helo=es-i.jp) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 38/FB-10715-59D32B95 for ; Fri, 08 Sep 2017 02:50:00 -0400 Received: (qmail 608 invoked by uid 89); 8 Sep 2017 06:49:53 -0000 Received: from unknown (HELO mail-io0-f175.google.com) (yohgaki@ohgaki.net@209.85.223.175) by 0 with ESMTPA; 8 Sep 2017 06:49:53 -0000 Received: by mail-io0-f175.google.com with SMTP id j141so3771498ioj.4 for ; Thu, 07 Sep 2017 23:49:52 -0700 (PDT) X-Gm-Message-State: AHPjjUiMFT0IFzbImgOUqZJSMn3XxhP6bQu2MY2yGi+xY6jJ9iLQFa+R k5IeRHVhEw2kuQ5Mio/FoOyZm+w3gA== X-Google-Smtp-Source: AOwi7QCpCfdw2pk2fedxFS87CQ1EPIxDEHPoGCQz3OhWZysb7+SdoZM4i6fayFmq+HRtZdTTKGzwKhZ1i4+iAGjSpXA= X-Received: by 10.107.170.227 with SMTP id g96mr1968964ioj.311.1504853387215; Thu, 07 Sep 2017 23:49:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.72.5 with HTTP; Thu, 7 Sep 2017 23:49:06 -0700 (PDT) In-Reply-To: References: Date: Fri, 8 Sep 2017 15:49:06 +0900 X-Gmail-Original-Message-ID: Message-ID: To: Andrey Andreev Cc: "internals@lists.php.net" , Nikita Popov Content-Type: multipart/alternative; boundary="001a1142dd30958d940558a7fbd4" Subject: Re: [PHP-DEV] Re: hash_hkdf() signature and return value From: yohgaki@ohgaki.net (Yasuo Ohgaki) --001a1142dd30958d940558a7fbd4 Content-Type: text/plain; charset="UTF-8" Hi Andrey, On Fri, Sep 8, 2017 at 8:14 AM, Andrey Andreev wrote: > Hi, > > On Fri, Sep 8, 2017 at 12:32 AM, Yasuo Ohgaki 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 yohgaki@ohgaki.net --001a1142dd30958d940558a7fbd4--