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

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

[jasa.david at gmail dot com]

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

            Bug ID: 16522
           Summary: On sha* password generation, select hash rounds to
                    achieve given computation time based on hash
                    computation speed
           Product: glibc
           Version: 2.18
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: jasa.david at gmail dot com
                CC: drepper.fsp at gmail dot com

When glibc encodes a password using sha256 or sha512 method and no indication
of desired rounds is given (e.g. in login.defs or libuser.conf), the rounds
count is set to 5000:
https://sourceware.org/git/?p=glibc.git;a=blob;f=crypt/sha256-crypt.c#l86
https://sourceware.org/git/?p=glibc.git;a=blob;f=crypt/sha512-crypt.c#l86
This behaviour is getting suboptimal in light of recent rise hash-crunching on
GPUs and dedicated chips (driven by cryptocurrencies mining but usable for
password cracking as well). IMO glibc should employ similar approach to
cryptsetup's: choose password hash computation time as long as possible without
causing user inconvenience or DoS potential. For example, cryptsetup/LUKS uses
1 s:
# cryptsetup --help
...
Default PBKDF2 iteration time for LUKS: 1000 (ms)

Which yields this theoretical and practical iteration count for on my 2010
machine:
# cryptsetup benchmark
...
PBKDF2-sha256     204161 iterations per second
PBKDF2-sha512     134570 iterations per second
# cryptsetup luksDump /dev/sda2 | grep -B1 Iterations
Key Slot 0: ENABLED
    Iterations:             160803
--
Key Slot 1: ENABLED
    Iterations:             154588

In other words cryptsetup/LUKS with default settings gives about 30x better
protection to user password than glibc with default settings. While glibc must
take into account DoS scenarios that do not apply to cryptsetup (such as
attacker trying to log in over as many ssh connections as possible), these
considerations should result in shorter computation time (my guess: 500 ms
instead of 1000) instead of choosing fixed rounds count that actually provides
constantly decreasing security level.

The most conservative approach wrt compatibility would be to take time to run
password verification on 5% of slowest devices where glibc is deployed and use
this (or a value within an order of magnitude), this way glibc behaviour on
slow machines won't change while fast machines will get much better protection.


The problem was spotted on glibc 2.18 (Fedora 20) but quick look to source code
(above in the report) shows that git HEAD is still affected.

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

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

[bressers at redhat dot com]

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

Josh Bressers <bressers at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bressers at redhat dot com

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

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

[carlos at redhat dot com]

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

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #1 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to David Jaša from comment #0)
> In other words cryptsetup/LUKS with default settings gives about 30x better
> protection to user password than glibc with default settings. While glibc
> must take into account DoS scenarios that do not apply to cryptsetup (such
> as attacker trying to log in over as many ssh connections as possible),
> these considerations should result in shorter computation time (my guess:
> 500 ms instead of 1000) instead of choosing fixed rounds count that actually
> provides constantly decreasing security level.

Agreed. Do you have a patch to make this work?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-21042-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Feb 04 02:45:44 2014
Return-Path: <glibc-bugs-return-21042-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 28917 invoked by alias); 4 Feb 2014 02:45:39 -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 28872 invoked by uid 48); 4 Feb 2014 02:45:34 -0000
From: "alvarezp at alvarezp dot ods.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug network/16421] IN6_IS_ADDR_UNSPECIFIED can use undefined s6_addr32
Date: Tue, 04 Feb 2014 02:45:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: network
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: alvarezp at alvarezp dot ods.org
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: cc
Message-ID: <bug-16421-131-Xw8z5EYXM5@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-16421-131@http.sourceware.org/bugzilla/>
References: <bug-16421-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/msg00019.txt.bz2
Content-length: 1305

https://sourceware.org/bugzilla/show_bug.cgi?id\x16421

Octavio Alvarez <alvarezp at alvarezp dot ods.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alvarezp at alvarezp dot ods.org

--- Comment #4 from Octavio Alvarez <alvarezp at alvarezp dot ods.org> ---
Knowing:

1. Although POSIX only requires s6_addr it doesn't prohibit s6_addr32.

But considering:

1. glibc already contains alternate implementations independent of s6_addr32 or
other s6_addrNN,

2. it is useful to have _POSIX_C_SOURCE *not* to define s6_addrNN macros as
that actually aids in making sure the programs are portable,

3. s6_addr32, although a very good attempt and already used by Linux and BSD,
POSIX may take that name in the future,

I sent a patch to the ML at:

https://sourceware.org/ml/libc-alpha/2014-01/msg00471.html

... a commit based on the patch presented by Sebastien Vincent on April 2013.

Currently we #undef the offending macros and redefine them again with the fixed
#ifdef condition in a custom header. We are able to make the program compile
within the defines of _POSIX_C_SOURCE.

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

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

[bugdal at aerifal dot cx]

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

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugdal at aerifal dot cx

--- Comment #2 from Rich Felker <bugdal at aerifal dot cx> ---
I'm a bit concerned about this proposal. What happens when your hashes are
shared between multiple machines (e.g. a very fast server and multiple thin
clients) or when you're setting up a VE image for cpu-limited hosting or a
system image to run on a lower-end machine using a higher-end one? I think it's
flawed to assume that the machine on which hashes will later be validated is as
capable as the machine on which the original hashes are generated. Whether this
is an acceptable flaw (i.e. whether the benefit is worth dealing with the side
effects of this flaw) is a matter for discussion.

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

[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]

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

--- Comment #3 from David Jaša <jasa.david at gmail dot com> ---
(In reply to Carlos O'Donell from comment #1)
> ...
> Agreed. Do you have a patch to make this work?

I prefer to leave code writing to people who can actually do it. :)

(In reply to Rich Felker from comment #2)
> I'm a bit concerned about this proposal. What happens when your hashes are
> shared between multiple machines (e.g. a very fast server and multiple thin
> clients) 

Very fast serve means these days a lot of cores, doesn't it? If so, then the
performance gap is still big, but manageable. I'd still prefer "reasonably
secure by default even if it causes noticeable nuisance on worst 10 % of
devices" over "it works everywhere b

> or when you're setting up a VE image for cpu-limited hosting or a
> system image to run on a lower-end machine using a higher-end one? 

Aren't you using ssh keys for such use cases anyway? What is their complexity
(time to verify login)?

> I think
> it's flawed to assume that the machine on which hashes will later be
> validated is as capable as the machine on which the original hashes are
> generated. Whether this is an acceptable flaw (i.e. whether the benefit is
> worth dealing with the side effects of this flaw) is a matter for discussion.

Consider partial disk encryption: on my system, cryptsetup uses PBKDF2 with
155-160k iterations to achieve 1s verification time. When I set maximum rounds
count for crypt/sha512 of 10M, the verification takes 16 s, yielding 650k
rounds to achieve 1 s running time, so 5k rounds should take 5/650 = 1/130 =
0.007 s. If the crypt/sha512 to pbkdf2 running time ratio is constant and users
choose the same password for disk encryption and user account verification, the
latter forms an avenue for side-channel attack to the former, reducing its
effective strenght by 2^7 bits...

IMO good target would be to have bearable performance on Raspberry Pi.
Cryptsetup FAQ [1] states:
> Note: Passphrase iteration is determined by cryptsetup depending on CPU
> power. On a slow device, this may be lower than you want. I recently
> benchmarked this on a Raspberry Pi and it came out at about 1/15 of the
> iteration count for a typical PC. If security is paramount, you may want to
> increase the time spent in iteration, at the cost of a slower unlock later.

So e.g. choosing 0.3 s target time on recent computer (= 195k rounds on my
system) would result in 4.5 s verification time on Raspberry Pi. Slow but
bearable and _way_ more secure than default 5k.

[1] http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#2._Setup

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-21063-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Feb 04 15:34:02 2014
Return-Path: <glibc-bugs-return-21063-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 11892 invoked by alias); 4 Feb 2014 15:34:01 -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 11838 invoked by uid 48); 4 Feb 2014 15:33:57 -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: Tue, 04 Feb 2014 15:34: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-QsfssfA7JY@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/msg00040.txt.bz2
Content-length: 588

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

--- Comment #4 from David Jaša <jasa.david at gmail dot com> ---
(In reply to David Jaša from comment #3)
> ...
> 
> Very fast serve means these days a lot of cores, doesn't it? If so, then the
> performance gap is still big, but manageable. I'd still prefer "reasonably
> secure by default even if it causes noticeable nuisance on worst 10 % of
> devices" over "it works everywhere b

... but it's easily breakable by casual attackers.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-21064-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Feb 04 15:51:50 2014
Return-Path: <glibc-bugs-return-21064-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 23018 invoked by alias); 4 Feb 2014 15:51:50 -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 22988 invoked by uid 48); 4 Feb 2014 15:51:46 -0000
From: "stli at linux dot vnet.ibm.com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug math/16447] erfc (0x6.a8p+4) ldbl-128 throws underflow exception
Date: Tue, 04 Feb 2014 15:51:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: math
X-Bugzilla-Version: 2.19
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: stli at linux dot vnet.ibm.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: cc
Message-ID: <bug-16447-131-wDgMme1lgv@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-16447-131@http.sourceware.org/bugzilla/>
References: <bug-16447-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/msg00041.txt.bz2
Content-length: 1489

https://sourceware.org/bugzilla/show_bug.cgi?id\x16447

Stefan Liebler <stli at linux dot vnet.ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |stli at linux dot vnet.ibm.com

--- Comment #1 from Stefan Liebler <stli at linux dot vnet.ibm.com> ---
on S/390:
erfcl(0x6.a8p+4) = 0x1.05adad9ddfbecb52f2ca948fe461p-16371
=> FE_INEXACT is set, FE_UNDERFLOW is set,
   result is normalized and errno is unchanged

in
__erfcl in ../sysdeps/ieee754/ldbl-128/s_erfl.c:919: __ieee754_expl (-z * z -
0.5625)
__ieee754_expl in ../sysdeps/ieee754/ldbl-128/e_expl.c:
in line 146: feholdexcept saves the floating-point-control-register with the
INEXACT-Flag.
in line 197: fesetenv restores INEXACT-Flag, but was also set between line 146
and 197.
in line 199: the multiplication x22 * ex2_u.d raises the underflow-exception
    with x22 = 0x1.5177b...p-20 and ex2_u.d = 0x1.4877a...p-16365.
    The result of the multiplication is a denormalized floating point
        => underflow.
    After adding ex2_u.d the result is normalized again.

Thus, the result of the calls to __ieee754_expl is normalized,
but the UNDERFLOW-Flag is set.
How to handle this case?
Do we need an extra check after line 199?

The testcase passes if the UNDERFLOW-Flag is cleared after line 199.

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

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

[bugdal at aerifal dot cx]

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

--- Comment #5 from Rich Felker <bugdal at aerifal dot cx> ---
I see we're working with very different versions of "bearable". To me, 0.3s is
hardly "bearable" and 4.5s is utterly atrocious. And this is all assuming
there's only a single password being validated at a time and that you don't
care about 0.3 to 4.5 seconds of 100% cpu load interfering with whatever else
is running on the system.

Yes, for ssh login, most people should be using public key authentication, not
passwords. But password hashes are used for lots of other purposes too other
than unix account login. In cases where password hashes are being used, their
strength really needs to be tuned to the application, which is highly dependent
on things like number of users, expected cpu load, etc. and not just a function
of the raw cpu speed. So I'm skeptical of attempts to automate choosing a
strength parameter based on the latter...

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

[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]

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

--- Comment #6 from David Jaša <jasa.david at gmail dot com> ---
> I see we're working with very different versions of "bearable".

I'm assuming that:
  * password verification is fairly infrequent event:
    * local users log in (unlock screen) only every now and then
    * web app users log in once through web form and since then, their
      browser uses cookies to persist session
  * password verification takes place in context of other delays such as:
    * password typing (local login)
    * network latency (web app)
That makes me confident that delay that is noticeable but not really long is
OK. That should be around 0.5 s.

> But password hashes are used for lots of other purposes too other than
> unix account login.

What are the other purposes? Password hashes should be by definition as slow as
possible without annoying their users. Where their hard brute-force reversal
property is not important, they should be replaced by plain fast hashes...

> In cases where password hashes are being used, their strength really needs
> to be tuned to the application,

for that case, application can always override rounds=%i parameter to a value
that would suit it (ms=%i parameter similar to cryptsetup would make more sense
though).

The point is that standard procedures are long-lived while computers (and
dedicated devices) are getting more powerful over time so the results generated
by unchanged procedure should somehow generate stronger results at later time.
Basing number of rounds on arbitrary time seems thus quite good choice as even
barely-noticeable 0.1 s yields stronger result to the default round count.
Would RFEs to base rounds on running time and using that as a default method be
less controversial with you?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-21123-listarch-glibc-bugs=sources.redhat.com@sourceware.org Thu Feb 06 16:19:50 2014
Return-Path: <glibc-bugs-return-21123-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 8631 invoked by alias); 6 Feb 2014 16:19:50 -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 8180 invoked by uid 55); 6 Feb 2014 16:19:46 -0000
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug network/16529] netinet/in.h breaks -pedantic
Date: Thu, 06 Feb 2014 16:19:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: network
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: cvs-commit at gcc dot gnu.org
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-16529-131-zHpxmpMew2@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-16529-131@http.sourceware.org/bugzilla/>
References: <bug-16529-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/msg00100.txt.bz2
Content-length: 1958

http://sourceware.org/bugzilla/show_bug.cgi?id\x16529

--- Comment #5 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  3bfff2edbef578746211ba231f3942efffd38f86 (commit)
      from  ee7cc3853761fc00b6bbcdc09b3d8a56695dd7a6 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h;fff2edbef578746211ba231f3942efffd38f86

commit 3bfff2edbef578746211ba231f3942efffd38f86
Author: Carlos O'Donell <carlos@redhat.com>
Date:   Thu Feb 6 11:12:48 2014 -0500

    BZ #16529: Fix pedantic warning with netinet/in.h.

    When compiling with pedantic the following warning is seen:

    gcc -Wall -pedantic -O0 -o test test.c
    In file included from test.c:3:0:
    /path/inet/netinet/in.h:111:21: warning: comma at end of \
    enumerator list [-Wpedantic]
         IPPROTO_MH = 135,      /* IPv6 mobility header.  */
                         ^

    It is valid C99 to have a trailing comma after the last item in
    an enumeration. However it is not valid C90. If possible glibc
    attempts to keep all headers C90 + long long without requiring
    C99 features. In this case it's easy to fix the headers and it
    removes the warning seem with -pedantic.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog         |    5 +++++
 NEWS              |    2 +-
 inet/netinet/in.h |    2 +-
 3 files changed, 7 insertions(+), 2 deletions(-)

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

[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]

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

--- Comment #7 from David Jaša <jasa.david at gmail dot com> ---
Increase to number of rounds to number makes this extra work for user and
attacker:

rounds   user time    user work factor   p/s         attacker work factor
5000     << 0.1 s     1                  ~190        1
625000   ~ 1 s        125                ~3          ~ 60
5000000  ~ 8 s        1000               0.16-0.19   ~ 1000-1200

the question is how would this fare with GPU or FPGA/ASIC-equipped attacker
(that seems quite likely). [1] suggests that sha512 is less friendly to GPUs or
HW chips to sha256 and HW development will focus for some time on sha256 as
that is what cryptocurrency mining requires so pretty much any increase in
rounds should be safe short- and medium-term but given the inertia inherent in
such low-level base system things, it seems a good time to look for
alternatives to both parameters of current schemes and the schemes themselves.

[1]
http://www.openwall.com/presentations/Passwords12-The-Future-Of-Hashing/Passwords12-The-Future-Of-Hashing.pdf

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-21127-listarch-glibc-bugs=sources.redhat.com@sourceware.org Thu Feb 06 17:30:49 2014
Return-Path: <glibc-bugs-return-21127-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 31390 invoked by alias); 6 Feb 2014 17:30:49 -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 31346 invoked by uid 48); 6 Feb 2014 17:30:45 -0000
From: "bugdal at aerifal dot cx" <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: Thu, 06 Feb 2014 17:30: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: bugdal at aerifal dot cx
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-xgwkalIXFp@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: 7bit
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-02/txt/msg00104.txt.bz2
Content-length: 678

https://sourceware.org/bugzilla/show_bug.cgi?id\x16522

--- Comment #8 from Rich Felker <bugdal at aerifal dot cx> ---
No, what I'm objecting to is entirely making the behavior of this function
dependent on the cpu speed on which it runs. I consider that bad practice
(non-determinism) and also an invalid assumption (that the cpu the hash is
generated on will have any relation to the cpu it's later verified on). Tuning
this via run time rather than raw cpu speed would be even worse, since an
attacker could artificially load the cpu to increase run time and thereby
control the rounds parameter.

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

[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]

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.

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

[fweimer at redhat dot com]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com
              Flags|                            |security-

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

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

[rsawhill+sw at redhat dot com]

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

Ryan Sawhill Aroha <rsawhill+sw at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rsawhill+sw at redhat dot com

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