Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:100462 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 37295 invoked from network); 8 Sep 2017 08:44:57 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 8 Sep 2017 08:44:57 -0000 Authentication-Results: pb1.pair.com smtp.mail=yohgaki@ohgaki.net; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=yohgaki@ohgaki.net; 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:37018] helo=es-i.jp) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 49/BC-10715-68852B95 for ; Fri, 08 Sep 2017 04:44:56 -0400 Received: (qmail 18220 invoked by uid 89); 8 Sep 2017 08:44:50 -0000 Received: from unknown (HELO mail-io0-f178.google.com) (yohgaki@ohgaki.net@209.85.223.178) by 0 with ESMTPA; 8 Sep 2017 08:44:50 -0000 Received: by mail-io0-f178.google.com with SMTP id y123so4356994iod.0 for ; Fri, 08 Sep 2017 01:44:49 -0700 (PDT) X-Gm-Message-State: AHPjjUjQMSgYeSOnXXhHXxf51ZBVC4gcfbaKXEsuE7RerFS9YdfFO+62 T89yvet6Dglljc473gWRYxJSLRJLag== X-Google-Smtp-Source: AOwi7QBxbQ1dP7CtoGpQ3PnUcutg/nfDo53JvIyA3ONKembuLIzpWWkS9YckyTQdElucSmpQuACGbZ3M3K/9nbHjU4Q= X-Received: by 10.107.149.210 with SMTP id x201mr2068888iod.266.1504860283742; Fri, 08 Sep 2017 01:44:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.72.5 with HTTP; Fri, 8 Sep 2017 01:44:03 -0700 (PDT) In-Reply-To: References: Date: Fri, 8 Sep 2017 17:44:03 +0900 X-Gmail-Original-Message-ID: Message-ID: To: Niklas Keller Cc: Andrey Andreev , "internals@lists.php.net" , Nikita Popov Content-Type: multipart/alternative; boundary="001a1140fe66a646020558a99623" Subject: Re: [PHP-DEV] Re: hash_hkdf() signature and return value From: yohgaki@ohgaki.net (Yasuo Ohgaki) --001a1140fe66a646020558a99623 Content-Type: text/plain; charset="UTF-8" Hi Niklas, On Fri, Sep 8, 2017 at 4:57 PM, Niklas Keller wrote: > 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. >> > > This is ridiculous. Be stunned. It's right in the section about > applications of HKDF: https://tools.ietf.org/html/rfc5869#section-4, in > the middle of the second paragraph. > > Please stop, it's enough. > This is my bad I didn't understand "amplify" well. I mixed up "add" and "amplify" I admit this. However, the reason why I mixed up is Andrey's misunderstanding about HMAC nature. Andrey's words. ------ 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. ------- Following is wrong by HMAC nature. ------- it should NOT be relied upon to produce strong outputs from weak inputs ------- Who would think resulting $hash of following is insecure? $hash = hash_hmac('sha256', $weak_msg, $strong_key); RFC-5689 - https://tools.ietf.org/html/rfc5869#section-4 --------- One significant example is the derivation of cryptographic eys from a source of low entropy, such as a user's password. The extract step in HKDF can concentrate existing entropy but cannot amplify entropy. In the case of password-based KDFs, a main goal is to slow down dictionary attacks using two ingredients: a salt value, and the intentional slowing of the key derivation computation. HKDF naturally accommodates the use of salt; however, a slowing down mechanism is not part of this specification. Applications interested in a password-based KDF should consider whether, for example, [PKCS5] meets their needs better than HKDF. --------- This whole sentence means HKDF cannot be used like PBKDF2. That's all. This is does not support Andrey's statement ------- it should NOT be relied upon to produce strong outputs from weak inputs ------- Instead, he should read this section. 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. In this case, one can skip the extract part and use IKM directly to key HMAC in the expand step. --------- "one can skip the extract part" is "one can omit salt". Obviously, the RFC is prepared for weak keys and it is perfectly OK to use weak keys unlike Andrey statement. If IKM should be strong always, HKDF would NOT have salt at all. However, HKDF has salt. Weak IKM is explicitly allowed by HKDF definition. Andrey, sorry for my confusion, but your claim is wrong by HKDF (HMAC) definition still. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --001a1140fe66a646020558a99623--