Re: [Cfrg] [MASSMAIL]Re: Big-key cryptography

"Grigory Marshalko" <marshalko_gb@tc26.ru> Wed, 16 December 2015 19:44 UTC

Return-Path: <marshalko_gb@tc26.ru>
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 AF8091A8958 for <cfrg@ietfa.amsl.com>; Wed, 16 Dec 2015 11:44:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.759
X-Spam-Level: ****
X-Spam-Status: No, score=4.759 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 xLPFsZgMBwgp for <cfrg@ietfa.amsl.com>; Wed, 16 Dec 2015 11:44:32 -0800 (PST)
Received: from mail.tc26.ru (mail.tc26.ru [188.40.163.82]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1961A8957 for <cfrg@irtf.org>; Wed, 16 Dec 2015 11:44:32 -0800 (PST)
Received: from mail.tc26.ru (localhost [127.0.0.1]) by mail.tc26.ru (Postfix) with ESMTPSA id 767F130017D; Wed, 16 Dec 2015 22:44:30 +0300 (MSK)
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.tc26.ru 767F130017D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tc26.ru; s=mx; t=1450295071; bh=NYiRuoXbjENObVZQ2Z4DySY+avvxEytbrczc8pYe8hc=; h=Date:From:Subject:To:In-Reply-To:References:From; b=SU2I48VVbB51OJp+/Dq1ewSu7x6P5pMC3hCXEuldwXzp1utl4uGGWU7W7WxKkwLlu 8wrD2Y9W5pwKz8nDyOx8vS4CG3uPu9PYgeWjCNwB4ASo/xgpk4rOjR59ge35pKUaQ5 996WbXnzVn6jSCs7btHNyXZZaVF/5qAumwiD4nzM=
Mime-Version: 1.0
Date: Wed, 16 Dec 2015 19:44:30 +0000
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-ID: <077535aac6cb8e3173b4a2758f018aa2@mail.tc26.ru>
X-Mailer: RainLoop/1.9.3.365
From: Grigory Marshalko <marshalko_gb@tc26.ru>
To: Hanno Böck <hanno@hboeck.de>, cfrg@irtf.org
In-Reply-To: <20151215135922.2c182052@pc1>
References: <20151215135922.2c182052@pc1> <566C3791.2050705@azet.org> <5669F8AF.2000008@azet.org> <bcbd3d10ecc43f8bd1e302f095a2ade0@mail.tc26.ru> <803c5559d8b8b2d6853c066ee906355c@mail.tc26.ru> <51b7ad9ad4199cff7e1538ded64193c3@mail.tc26.ru>
X-KLMS-Rule-ID: 1
X-KLMS-Message-Action: clean
X-KLMS-AntiSpam-Lua-Profiles: 88358 [Dec 16 2015]
X-KLMS-AntiSpam-Version: 5.5.6
X-KLMS-AntiSpam-Envelope-From: marshalko_gb@tc26.ru
X-KLMS-AntiSpam-Rate: 0
X-KLMS-AntiSpam-Status: not_detected
X-KLMS-AntiSpam-Method: none
X-KLMS-AntiSpam-Moebius-Timestamps: 3873949, 3873978, 3873677
X-KLMS-AntiSpam-Info: LuaCore: 393 393 c2c6794cec399221a2b2ea37c1235b8c69404071, eprint.iacr.org:7.1.1; tc26.ru:7.1.1; 127.0.0.200:7.1.3; www.irtf.org:7.1.1; mail.tc26.ru:7.1.1; d41d8cd98f00b204e9800998ecf8427e.com:7.1.1; 127.0.0.199:7.1.2; hboeck.de:7.1.1, Auth:dkim=none
X-KLMS-AntiSpam-Interceptor-Info: scan successful
X-KLMS-AntiPhishing: Clean, 2015/12/16 14:04:47
X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.721, bases: 2015/12/16 14:19:00 #6751863
X-KLMS-AntiVirus-Status: Clean, skipped
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/CD0EXt63WvPTqX2mKDNMmy_Gztk>
Subject: Re: [Cfrg] [MASSMAIL]Re: 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: Wed, 16 Dec 2015 19:44:33 -0000

This is not always true. See, for example, McGrew article http://eprint.iacr.org/2012/623/ This is obvously the case of no reseeding in block cipher-based RBGs.
Regards,
Grigory Marshalko,
expert,
Technical committee for standardisation "Cryptography and security mechanisms" (ТC 26)
www.tc26.ru
15 декабря 2015 г., 15:59, "Hanno Böck" <hanno@hboeck.de> написал:
> 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
> 
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg