[Bitcoin-development] bip44 GPG identities - POC demo

[Bitcoin-development] bip44 GPG identities - POC demo

[Mem Wallet]

[-- Attachment #1: Type: text/plain, Size: 599 bytes --]

If anyone is interested in using a bip44 Wallet to generate
deterministic GPG identities, I have implemented a demonstration in
javascript.

http://memwallet.info/bip44ext/test.html

this allows a user to manage a GPG identity for encryption
and signing with zero bytes of permanent storage. (on tails for example)


Paper is here still:

https://github.com/taelfrinn/bip44extention/blob/master/README.md

One minor correction added which specifies that the smallest S value
should be used, to prevent different ecdsa implementations from creating
non-canonical/identical outputs.

comments welcome

[-- Attachment #2: Type: text/html, Size: 973 bytes --]

Re: [Bitcoin-development] bip44 GPG identities - POC demo

[Pavol Rusnak]

On 07/03/15 16:53, Mem Wallet wrote:
> this allows a user to manage a GPG identity for encryption
> and signing with zero bytes of permanent storage. (on tails for example)

Hi!

As an author of BIP44 I don't think that you should use BIP44 for this
and a new BIP number should be allocated. To me it does not make much
sense to create GPG key hierarchy per Bitcoin account, but rather create
a GPG key hierarchy per device/master seed.

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.

-- 
Best Regards / S pozdravom,

Pavol Rusnak <stick@gk2.sk>

Re: [Bitcoin-development] bip44 GPG identities - POC demo

[Natanael]

[-- Attachment #1: Type: text/plain, Size: 1162 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1697 bytes --]