phc-discussions - Re: [PHC] Are password trailing 0's a problem?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 7 Mar 2014 17:59:14 -0500
From: Bill Cox <waywardgeek@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Are password trailing 0's a problem?

On Fri, Mar 7, 2014 at 4:58 PM,  <pornin@...et.org> wrote:
>> It seems really frightening to be rolling-my-own when HKDF
>> seems to have become a standard in 2010
>
> Hey, let's not be hasty. HKDF was first published in 2010, and the article
> (which can be seen on http://eprint.iacr.org/2010/264.pdf ) contains this
> sentence, right in the abstract:
>
>    The HMAC-based scheme presented here, named HKDF, is being standardized
> by the IETF.
>
> And a footnote on page 3 further qualifies that assertion as:
>
>    The proposed HKDF scheme is being standardized by the IETF as RFC 5869.
>
> Ok, so let's have a look at RFC 5869: http://tools.ietf.org/html/rfc5869
> And there we see that the RFC has category "INFORMATIONAL", and not at all
> "STANDARDS TRACK" or "PROPOSED STANDARD".
>
> Bottom-line: HKDF is not a standard in the IETF sense (so the assertion in
> the article is a bit misleading). Being published as a RFC is in no way an
> official blessing, asserting quality, or implying that you can get jailed
> for not using it. An "informational" RFC only means that the author could
> write in a coherent enough English some description of a technical element
> that was not immediately detected as flawed (I should know -- I myself
> wrote an informational RFC).

Thanks for that tip.  I'd not noticed the difference before between
informational and standards track on RFCs.

Here's another question: Is it worth worrying so much about looping
over the password in a way that might enable a side-channel timing
attack of some sort?  When we get the password, it comes with a
certain length, and I see no way to avoid reading all these addresses.
 An attacker might be able to detect the password length through a
cache timing attack where he sees how many addresses in sequence were
loaded into the cache, though it's probably at an almost useless
resolution of 64-bytes.