Re: [kitten] draft-hansen-scram-sha256 and the hash iteration count

Simon Josefsson <> Wed, 25 February 2015 15:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 193871A875E for <>; Wed, 25 Feb 2015 07:06:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.348
X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1QpUFOjMvqI8 for <>; Wed, 25 Feb 2015 07:06:36 -0800 (PST)
Received: from ( [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3BF0B1A8758 for <>; Wed, 25 Feb 2015 07:06:36 -0800 (PST)
Received: from ( []) (authenticated bits=0) by (8.14.4/8.14.4/Debian-4) with ESMTP id t1PF6MLv019546 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 25 Feb 2015 16:06:23 +0100
From: Simon Josefsson <>
To: Tony Hansen <>
References: <> <> <>
OpenPGP: id=54265E8C; url=
Date: Wed, 25 Feb 2015 16:06:21 +0100
In-Reply-To: <> (Tony Hansen's message of "Tue, 24 Feb 2015 11:33:30 -0500")
Message-ID: <>
User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
X-Virus-Scanned: clamav-milter 0.98.5 at
X-Virus-Status: Clean
Archived-At: <>
Cc: "" <>
Subject: Re: [kitten] draft-hansen-scram-sha256 and the hash iteration count
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 25 Feb 2015 15:06:38 -0000

Tony Hansen <> writes:

> So, what to do for SCRAM-SHA-256?
> One way to derive a recommended number might be to use a log scale
> between 2000's and 2010's numbers, extend it out to 2015, then reduce
> the number by some percentage to account for SHA-1 vs SHA-256
> performance. If my math is correct, and using a performance reduction
> of 30%, this gives 4260, which is only a few percent away from my
> original recommendation of 4096 for SHA-2.
> Or we could jump all the way up to 14500, as suggested by Russ.
> Another possibility is to suggest two values: one for mobile use and
> one for non-mobile use.

I think there are at least two different considerations:

1) Language used.  As you quoted, the text now says that servers "SHOULD
announce at least 4096".  Using SHOULD already gives room for using
other values if there is good justification.  To split things into
mobile and non-mobile use-cases (which sounds like a bad idea for
several reasons to me) would require changing the language, as the
server normally doesn't know what type the client is.  Another idea is
to give two values but phrase it in a different way: one MUST minimum
value for protocol conformance (say 4096) and one RECOMMENDED value for
good protection in various deployments (say 14500).

2) How to decide the value.  I don't agree with the focus on performance
-- the reason for using PBKDF2 is to improve security, so the normal
approach to decide security parameters (compare key sizes) is that the
security needs dictate the requirements.  On one extreme, using 10
iteration count would be weak (although I can't cite attacks, maybe
because nobody uses 10 iterations...).  IMHO, the metric should be: how
many iterations raises the cost for an attacker so that it is no longer
a cost-effective way to crack the system?  Of course, different systems
will have different attack cost models, but we should give a ball-park
number applicable for common Internet applications.  I'm with Alexey
that current estimates are probably mostly guesses.  I don't know of a
established way to derive a better value.  However it feels weird for us
to not raise the value when we are revising the specification: surely
all attacks are more cost-effective as time passes by, so the value
should at least be incremented somewhat.