Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 15 Mar 2018 21:23:40 +0100
From: Solar Designer <>
Subject: Re: keyed hash vs. encryption (was: Real world password policies)


On Thu, Mar 15, 2018 at 09:08:13PM +0100, Solar Designer wrote:
> Now in another thread, Arnold argues in favor of changing the SHOULD to
> SHALL, and you haven't objected yet:
> So I feel I have to: please either leave it at SHOULD, or please allow
> the hash encryption approach as an option as well (primary option even?)

Also, assuming Arnold's quoting is correct (I didn't verify), the
wording "an additional iteration of a key derivation function" is
unnecessarily too specific.  For example, a password hash function could
be designed to readily accept an extra secret input just for this
purpose, but that wording, if upgraded to a SHALL, would rule out
straightforward use of that feature, instead requiring "an additional
iteration", whatever that means (could be tricky for some memory-hard
hashes - is that an extra invocation of the whole algorithm, which would
result in a suboptimal total AT cost for the total running time, because
the extra invocation would have to start from zero memory usage?)


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.