summaryrefslogtreecommitdiff
path: root/9a/13b5578c10dd0be200e48821f8d91c994844e3
blob: f5bcc09e92e7ae3df2b54658770b93e3d6e36486 (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
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <natanael.l@gmail.com>) id 1YUWS9-0006fB-Lf
	for bitcoin-development@lists.sourceforge.net;
	Sun, 08 Mar 2015 08:20:49 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.172 as permitted sender)
	client-ip=74.125.82.172; envelope-from=natanael.l@gmail.com;
	helo=mail-we0-f172.google.com; 
Received: from mail-we0-f172.google.com ([74.125.82.172])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YUWRy-00011w-Ha
	for bitcoin-development@lists.sourceforge.net;
	Sun, 08 Mar 2015 08:20:49 +0000
Received: by wesw62 with SMTP id w62so4876786wes.0
	for <bitcoin-development@lists.sourceforge.net>;
	Sun, 08 Mar 2015 00:20:32 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.181.11.202 with SMTP id ek10mr14125764wid.37.1425802832410; 
	Sun, 08 Mar 2015 00:20:32 -0800 (PST)
Received: by 10.194.28.170 with HTTP; Sun, 8 Mar 2015 00:20:31 -0800 (PST)
Received: by 10.194.28.170 with HTTP; Sun, 8 Mar 2015 00:20:31 -0800 (PST)
In-Reply-To: <54FBA72E.4040308@gk2.sk>
References: <CAKzHBKnh+yzTwXkZXmezRaOkTTnUO4Z1dJnvKjYGnZBKoNQNEQ@mail.gmail.com>
	<54FBA72E.4040308@gk2.sk>
Date: Sun, 8 Mar 2015 09:20:31 +0100
Message-ID: <CAAt2M18eaRTY1mVLRJb7w=jFGiL=edi_7gC5J_9CcKE-3qskEg@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
To: Pavol Rusnak <stick@gk2.sk>
Content-Type: multipart/alternative; boundary=f46d043c0904587f1c0510c29771
X-Spam-Score: -0.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
	(natanael.l[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-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: 1YUWRy-00011w-Ha
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] bip44 GPG identities - POC demo
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: Sun, 08 Mar 2015 08:20:49 -0000

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

Den 8 mar 2015 02:36 skrev "Pavol Rusnak" <stick@gk2.sk>:
>
> On 07/03/15 16:53, Mem Wallet wrote:
[...]
> I am currently in process of implementing a SignIdentity message for
> TREZOR, which will be used for HTTPS/SSH/etc. logins.
>
> See PoC here:
>
https://github.com/trezor/trezor-emu/commit/9f612c286cc7b8268ebaec4a36757e1c19548717
>
> The idea is to derive the BIP32 path from HTTPS/SSH URI (by hashing it
> and use m/46'/a'/b'/c'/d' where a,b,c,d are first 4*32 bits of the hash)
> and use that to derive the private key. This scheme might work for GPG
> keys (just use gpg://user@host.com for the URI) as well.

Reminds me of FIDO's U2F protocol.

http://fidoalliance.org/specifications
https://www.yubico.com/products/yubikey-hardware/fido-u2f-security-key/

It ties into the browser SSL session to make sure only the correct server
can get the correct response for the challenge-response protocol, so that
credentials phishing is blocked and worthless. A unique keypair is
generated for each service for privacy, so that you can't easily be
identified across services from the usage of the device alone (thus safe
for people with multiple pseudonyms).

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

<p dir=3D"ltr"><br>
Den 8 mar 2015 02:36 skrev &quot;Pavol Rusnak&quot; &lt;<a href=3D"mailto:s=
tick@gk2.sk">stick@gk2.sk</a>&gt;:<br>
&gt;<br>
&gt; On 07/03/15 16:53, Mem Wallet wrote:<br>
[...] <br>
&gt; I am currently in process of implementing a SignIdentity message for<b=
r>
&gt; TREZOR, which will be used for HTTPS/SSH/etc. logins.<br>
&gt;<br>
&gt; See PoC here:<br>
&gt; <a href=3D"https://github.com/trezor/trezor-emu/commit/9f612c286cc7b82=
68ebaec4a36757e1c19548717">https://github.com/trezor/trezor-emu/commit/9f61=
2c286cc7b8268ebaec4a36757e1c19548717</a><br>
&gt;<br>
&gt; The idea is to derive the BIP32 path from HTTPS/SSH URI (by hashing it=
<br>
&gt; and use m/46&#39;/a&#39;/b&#39;/c&#39;/d&#39; where a,b,c,d are first =
4*32 bits of the hash)<br>
&gt; and use that to derive the private key. This scheme might work for GPG=
<br>
&gt; keys (just use gpg://<a href=3D"mailto:user@host.com">user@host.com</a=
> for the URI) as well.</p>
<p dir=3D"ltr">Reminds me of FIDO&#39;s U2F protocol. </p>
<p dir=3D"ltr"><a href=3D"http://fidoalliance.org/specifications">http://fi=
doalliance.org/specifications</a><br>
<a href=3D"https://www.yubico.com/products/yubikey-hardware/fido-u2f-securi=
ty-key/">https://www.yubico.com/products/yubikey-hardware/fido-u2f-security=
-key/</a></p>
<p dir=3D"ltr">It ties into the browser SSL session to make sure only the c=
orrect server can get the correct response for the challenge-response proto=
col, so that credentials phishing is blocked and worthless. A unique keypai=
r is generated for each service for privacy, so that you can&#39;t easily b=
e identified across services from the usage of the device alone (thus safe =
for people with multiple pseudonyms). </p>

--f46d043c0904587f1c0510c29771--