[Bug libc/16522] On sha* password generation, select hash rounds to achieve given computation time based on hash computation speed

["jasa.david at gmail dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=16522

--- Comment #9 from David Jaša <jasa.david at gmail dot com> ---
IMO basing the hash strength on CPU speed is good as long as sensible minimum
is set. If the minimum is raised from current minimum to current default, the
worst case scenario is that security will be the same as status quo while it
will be better on average. This behaviour is good enough IMO for the time
being.

I see another problem here though: when sha512 hashing gets definitely cheap,
keeping the minimum amount of rounds low will create "pockets" of low-spec
password hashes on systems that were using the minimums while on average,
hashes will still be safe (and it will take quite some time to update all
affected systems) so it would be helpful to have an idea what are the slowest
devices where glibc runs these days so that the minimum rounds count can be
tailored to them so that that gap is as small as possible.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-21349-listarch-glibc-bugs=sources.redhat.com@sourceware.org Fri Feb 07 16:36:56 2014
Return-Path: <glibc-bugs-return-21349-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 23951 invoked by alias); 7 Feb 2014 16:36:56 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 23901 invoked by uid 48); 7 Feb 2014 16:36:50 -0000
From: "jasa.david at gmail dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/16522] On sha* password generation, select hash rounds to achieve given computation time based on hash computation speed
Date: Fri, 07 Feb 2014 16:36:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: 2.18
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jasa.david at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-16522-131-pJPFwuz6vU@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-16522-131@http.sourceware.org/bugzilla/>
References: <bug-16522-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-02/txt/msg00326.txt.bz2
Content-length: 371

https://sourceware.org/bugzilla/show_bug.cgi?id=16522

--- Comment #10 from David Jaša <jasa.david at gmail dot com> ---
Addendum to comment 7: the passwors/s numbers are per core so if attacker were
using my own system, her effective work factor would be half of the one in
table.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-21350-listarch-glibc-bugs=sources.redhat.com@sourceware.org Fri Feb 07 16:44:58 2014
Return-Path: <glibc-bugs-return-21350-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 30131 invoked by alias); 7 Feb 2014 16:44:58 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 29796 invoked by uid 48); 7 Feb 2014 16:44:54 -0000
From: "carlos at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/16522] On sha* password generation, select hash rounds to achieve given computation time based on hash computation speed
Date: Fri, 07 Feb 2014 16:44:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: 2.18
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: carlos at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-16522-131-n7wRIjUFno@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-16522-131@http.sourceware.org/bugzilla/>
References: <bug-16522-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-02/txt/msg00327.txt.bz2
Content-length: 2186

https://sourceware.org/bugzilla/show_bug.cgi?id=16522

--- Comment #11 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to David Jaša from comment #9)
> IMO basing the hash strength on CPU speed is good as long as sensible
> minimum is set. If the minimum is raised from current minimum to current
> default, the worst case scenario is that security will be the same as status
> quo while it will be better on average. This behaviour is good enough IMO
> for the time being.

Agreed.

> I see another problem here though: when sha512 hashing gets definitely
> cheap, keeping the minimum amount of rounds low will create "pockets" of
> low-spec password hashes on systems that were using the minimums while on
> average, hashes will still be safe (and it will take quite some time to
> update all affected systems) so it would be helpful to have an idea what are
> the slowest devices where glibc runs these days so that the minimum rounds
> count can be tailored to them so that that gap is as small as possible.

I think the default count will need to increase to meet newer security
requirements. Keeping the count low for these systems does not offer them the
best security. If they need to loosen the security of their systems the need to
do so consciously by changing the compile time constants (with tunnables we
plan to put all of them into a single file which you might edit before building
glibc... at your own risk).

I don't fully agree with Rich's determinism statement. However, I also have no
evidence to back up my claim that a completely deterministic count is useful or
not useful. Other than to say that that the count should be selected at program
startup and remain constant for the life of the program. That way it can be
inspected by a debugger and used to reproduce a similar environment. Either
setup is deterministic in that case, one is just determined by the CPU, and
both can act in some ways as timing oracles (revealing some information about
the system to an attacker). Making things random or constant time removes the
timing oracle.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-21351-listarch-glibc-bugs=sources.redhat.com@sourceware.org Fri Feb 07 17:14:15 2014
Return-Path: <glibc-bugs-return-21351-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 28214 invoked by alias); 7 Feb 2014 17:14:15 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 27729 invoked by uid 55); 7 Feb 2014 17:14:10 -0000
From: "joseph at codesourcery dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/6981] __STDC_IEC_559__ should not be defined unconditionally
Date: Fri, 07 Feb 2014 17:14:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: joseph at codesourcery dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-6981-131-sZdfi8HGPP@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-6981-131@http.sourceware.org/bugzilla/>
References: <bug-6981-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-02/txt/msg00328.txt.bz2
Content-length: 759

http://sourceware.org/bugzilla/show_bug.cgi?idi81

--- Comment #8 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
There would be no reason for F.6 and F.10.11 (in C11) if the intent wasn't
to support evaluation in wider types.  DTS 18661-1 clarifies things
further and provides the previously missing bindings to operations without
wide evaluation (e.g. the new functions fadd and faddl (formatOf addition
of double / long double, rounding once to float) both serve also to
provide bindings for addition of two floats, returning a float without
excess range or precision, even if straight "+" operates in the range and
precision of long double).

--
You are receiving this mail because:
You are on the CC list for the bug.