1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1V6EUW-00025a-Kh
for bitcoin-development@lists.sourceforge.net;
Mon, 05 Aug 2013 06:42:04 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.170 as permitted sender)
client-ip=209.85.217.170; envelope-from=gmaxwell@gmail.com;
helo=mail-lb0-f170.google.com;
Received: from mail-lb0-f170.google.com ([209.85.217.170])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1V6EUV-00004t-Rj
for bitcoin-development@lists.sourceforge.net;
Mon, 05 Aug 2013 06:42:04 +0000
Received: by mail-lb0-f170.google.com with SMTP id r10so1767347lbi.29
for <bitcoin-development@lists.sourceforge.net>;
Sun, 04 Aug 2013 23:41:57 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.181.65 with SMTP id du1mr7877970lac.76.1375684917100;
Sun, 04 Aug 2013 23:41:57 -0700 (PDT)
Received: by 10.112.160.104 with HTTP; Sun, 4 Aug 2013 23:41:57 -0700 (PDT)
In-Reply-To: <CAMGNxUuhpOF+fOpHxQ7ZrV2=tGTEhfF3LiA=g87HZW=0QkNzYA@mail.gmail.com>
References: <CAKaEYh+G-cEif43UG1NhZ-zwJwos1-tsW-ZTMtWrHm+t3GCtzQ@mail.gmail.com>
<51FE9834.7090007@gmail.com>
<CAMGNxUuhpOF+fOpHxQ7ZrV2=tGTEhfF3LiA=g87HZW=0QkNzYA@mail.gmail.com>
Date: Sun, 4 Aug 2013 23:41:57 -0700
Message-ID: <CAAS2fgTPFHGQVs8qUj+8NyRQ3Ym=ws=_+FuWWvyYra5r-PZsdQ@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Peter Vessenes <peter@coinlab.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1V6EUV-00004t-Rj
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Preparing for the Cryptopocalypse
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 05 Aug 2013 06:42:04 -0000
On Sun, Aug 4, 2013 at 8:30 PM, Peter Vessenes <peter@coinlab.com> wrote:
> I studied with Jeffrey Hoffstein at Brown, one of the creators of NTRU. He
> told me recently NTRU, which is lattice based, is one of the few (only?)
> NIST-recommended QC-resistant algorithms.
Lamport signatures (and merkle tree variants that allow reuse) are
simpler, faster, trivially implemented, and intuitively secure under
both classical and quantum computation (plus unlikely some proposed QC
strong techniques they're patent clear). They happen to be the only
digital signature scheme that you really can successfully explain to
grandma (even for values of grandma which are not cryptographers).
They have poor space/bandwidth usage properties, which is one reason
why Bitcoin doesn't use them today, but as far as I know the same is
so for all post-QC schemes.
> Though I question the validity of the claim that ECC is so much more secure than RSA (with appropriate keysizes).
The problems are intimately related, but under the best understanding
ECC (with suitable parameters) ends up being the maximally hard case
of that problem class. I do sometimes worry about breakthroughs that
give index-calculus level performance for general elliptic curves,
this still wouldn't leave it any weaker than RSA but ECC is typically
used with smaller keys.
|
