IETF Logo Mail Archive

Re: [Cfrg] Big-key cryptography

"Grigory Marshalko" <marshalko_gb@tc26.ru> Fri, 11 December 2015 07:57 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 82A1B1ACC80 for <cfrg@ietfa.amsl.com>; Thu, 10 Dec 2015 23:57:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.159
X-Spam-Level: **
X-Spam-Status: No, score=2.159 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, 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 2a1c9c3_7MCd for <cfrg@ietfa.amsl.com>; Thu, 10 Dec 2015 23:57:08 -0800 (PST)
Received: from mail.tc26.ru (mail.tc26.ru [188.40.163.82]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0061ACC7F for <cfrg@irtf.org>; Thu, 10 Dec 2015 23:57:08 -0800 (PST)
Received: from mail.tc26.ru (localhost [127.0.0.1]) by mail.tc26.ru (Postfix) with ESMTPSA id 5E581300414; Fri, 11 Dec 2015 10:57:06 +0300 (MSK)
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.tc26.ru 5E581300414
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tc26.ru; s=mx; t=1449820627; bh=XOWhksfdKtuJzJlUKNHtzYoxw1SrQNS/k/dJc3kdx20=; h=Date:From:Subject:To:Cc:In-Reply-To:References:From; b=RVrJyii2f8DE1htd8vCmI7O6ki981OR5VrqS+HUQNlyqkZjCzkZCosm2SkrVcpqbn vcLOWNgtV4ykAYFLonyTwcKwo2I2625d0BW1InBo2FmiQyIqBX8VguK1+O2wPSTlRQ cG0MUhBqF/fehdcS6phueZszZprWpBGvLlIyoT/k=
Mime-Version: 1.0
Date: Fri, 11 Dec 2015 07:57:06 +0000
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-ID: <803c5559d8b8b2d6853c066ee906355c@mail.tc26.ru>
X-Mailer: RainLoop/1.9.3.365
From: Grigory Marshalko <marshalko_gb@tc26.ru>
To: Aaron Zauner <azet@azet.org>
In-Reply-To: <5669F8AF.2000008@azet.org>
References: <5669F8AF.2000008@azet.org> <bcbd3d10ecc43f8bd1e302f095a2ade0@mail.tc26.ru>
X-KLMS-Rule-ID: 1
X-KLMS-Message-Action: clean
X-KLMS-AntiSpam-Lua-Profiles: 88105 [Dec 11 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: 3864726, 3864752, 3864737
X-KLMS-AntiSpam-Info: LuaCore: 378 378 1e7ea7963800114ee93165eacd681fad09c7a7a4, 127.0.0.200:7.1.3; mail.tc26.ru:7.1.1; d41d8cd98f00b204e9800998ecf8427e.com:7.1.1; 127.0.0.199:7.1.2; tc26.ru:7.1.1, Auth:dkim=none
X-KLMS-AntiSpam-Interceptor-Info: scan successful
X-KLMS-AntiPhishing: Clean, 2015/12/07 15:50:10
X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.721, bases: 2015/12/11 00:19:00 #6720540
X-KLMS-AntiVirus-Status: Clean, skipped
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/yI8HQDGlpTRbf_6uIZ7_Yxu_LI0>
Cc: cfrg@irtf.org
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: Fri, 11 Dec 2015 07:57:09 -0000

I've read :) 
I mean that regardless the specific application of this idea it may be a problem of creating initial key/state/pool large enough. That's the point. But theoretically the whole approach is clear and could used in different mechanisms. That's ok.


Regards,
Grigory Marshalko,
expert,
Technical committee for standardisation "Cryptography and security mechanisms" (ТC 26)
www.tc26.ru
11 декабря 2015 г., 01:12, "Aaron Zauner" <azet@azet.org> написал:
> Grigory Marshalko wrote:
> 
>> This approach seems to have a lot of drawbacks in real life, since
>> secure generation, distribution and storage of keys are usually the main
>> problems, and for big keys they could grow exponentially.
> 
> Please re-read the proposal.
> 
> Aaron

v2.23.0 | Report a Bug | By Email