IETF Logo Mail Archive

Re: [Cfrg] Big-key cryptography

Hanno Böck <hanno@hboeck.de> Tue, 15 December 2015 12:59 UTC

Return-Path: <hanno@hboeck.de>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A351A8894 for <cfrg@ietfa.amsl.com>; Tue, 15 Dec 2015 04:59:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHGsA_X0eAJV for <cfrg@ietfa.amsl.com>; Tue, 15 Dec 2015 04:59:08 -0800 (PST)
Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B10711A8892 for <cfrg@irtf.org>; Tue, 15 Dec 2015 04:59:05 -0800 (PST)
Received: from pc1 (0x3ec67ae7.inet.dsl.telianet.dk [::ffff:62.198.122.231]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Tue, 15 Dec 2015 13:59:03 +0100 id 00000000000000B7.0000000056700E97.00001424
Date: Tue, 15 Dec 2015 13:59:22 +0100
From: Hanno Böck <hanno@hboeck.de>
To: cfrg@irtf.org
Message-ID: <20151215135922.2c182052@pc1>
In-Reply-To: <51b7ad9ad4199cff7e1538ded64193c3@mail.tc26.ru>
References: <566C3791.2050705@azet.org> <5669F8AF.2000008@azet.org> <bcbd3d10ecc43f8bd1e302f095a2ade0@mail.tc26.ru> <803c5559d8b8b2d6853c066ee906355c@mail.tc26.ru> <51b7ad9ad4199cff7e1538ded64193c3@mail.tc26.ru>
X-Mailer: Claws Mail 3.13.0 (GTK+ 2.24.29; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-5156-1450184343-0001-2"
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/BoTO2NoWaOfHO8PH5ZOcxOeenxc>
Subject: Re: [Cfrg] Big-key cryptography
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Dec 2015 12:59:10 -0000

On Sat, 12 Dec 2015 18:20:35 +0000
"Grigory Marshalko" <marshalko_gb@tc26.ru> wrote:

> I mean that when we speak about key generation we should always
> control the amount of entropy. So the bigger the key the more entropy
> we need. That is the main problem in this approach - how to generate
> the initial key/state (By pool I mean entropy pool like in Fortuna
> RBG).

This is just wrong.

If you have once initialized your RNG with a proper seed (128 bits is
enough, 256 is already pretty much overkill) you have all the entropy
you need for the rest of your live as long as your PRNG is reasonably
properly designed.

The idea of having to re-seed your RNG is very pervasive, but it's
outright nonsense. There is no need to do something like this. If there
would be that would implicitly mean the function you're using for your
PRNG is broken.

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: BBB51E42

v2.23.0 | Report a Bug | By Email