summaryrefslogtreecommitdiff
path: root/7e/7d43febbef03adcb8b08a07fda22949ed0fe84
blob: 5ccd63f9f425412e0a4c0acb3bbdf5da4d173621 (plain)
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
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1V6f97-0006cE-7c
	for bitcoin-development@lists.sourceforge.net;
	Tue, 06 Aug 2013 11:09:45 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.50 as permitted sender)
	client-ip=209.85.219.50; envelope-from=mh.in.england@gmail.com;
	helo=mail-oa0-f50.google.com; 
Received: from mail-oa0-f50.google.com ([209.85.219.50])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1V6f96-00064K-FT
	for bitcoin-development@lists.sourceforge.net;
	Tue, 06 Aug 2013 11:09:45 +0000
Received: by mail-oa0-f50.google.com with SMTP id i4so427008oah.37
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 06 Aug 2013 04:09:39 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.43.226 with SMTP id z2mr534399oel.76.1375787379080; Tue,
	06 Aug 2013 04:09:39 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.84.231 with HTTP; Tue, 6 Aug 2013 04:09:38 -0700 (PDT)
In-Reply-To: <CAAS2fgTPFHGQVs8qUj+8NyRQ3Ym=ws=_+FuWWvyYra5r-PZsdQ@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>
	<CAAS2fgTPFHGQVs8qUj+8NyRQ3Ym=ws=_+FuWWvyYra5r-PZsdQ@mail.gmail.com>
Date: Tue, 6 Aug 2013 13:09:38 +0200
X-Google-Sender-Auth: 2eHhejn_gMsGw4hwjJh5ptI9TTc
Message-ID: <CANEZrP3XQC+R49+PV9TdYsz+XgWQaTShm2gB4zRqk1sgCgt5UA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=001a11333dce0444f704e34576ac
X-Spam-Score: -0.5 (/)
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
	(mh.in.england[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	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: 1V6f96-00064K-FT
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: Tue, 06 Aug 2013 11:09:45 -0000

--001a11333dce0444f704e34576ac
Content-Type: text/plain; charset=UTF-8

> 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.
>

I believe post-QC schemes based on Regev's LWE assumption are getting
competitive with more traditional schemes. A paper from 2010 says they were
able to get to around the same as large RSA key sizes (2048 bits), which is
much worse than ECC but not entirely infeasible. Especially given that
barring some breakthrough, by the time QC is a real problem we'll have
gigabit wifi and 32 core devices with a terabyte of storage embedded in our
hands :)

--001a11333dce0444f704e34576ac
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
They have poor space/bandwidth usage properties, which is one reason<br>
why Bitcoin doesn&#39;t use them today, but as far as I know the same is<br=
>
so for all post-QC schemes.<br></blockquote><div><br></div><div>I believe p=
ost-QC schemes based on Regev&#39;s LWE assumption are getting competitive =
with more traditional schemes. A paper from 2010 says they were able to get=
 to around the same as large RSA key sizes (2048 bits), which is much worse=
 than ECC but not entirely infeasible. Especially given that barring some b=
reakthrough, by the time QC is a real problem we&#39;ll have gigabit wifi a=
nd 32 core devices with a terabyte of storage embedded in our hands :)</div=
>
</div></div></div>

--001a11333dce0444f704e34576ac--