Re: [Bitcoin-development] Proposal to replace BIP0039

2013-11-03 Thread Thomas Voegtlin

Le 03/11/2013 07:41, Timo Hanke a écrit :
 No. You mean the computer would use B for this check? (k,K) could be 
 rigged by Trezor, who computes b as k-a. Timo

I was just asking a question, in order to understand how this device 
works, and what are its requirements.
if you think you can help, please explain.

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal to replace BIP0039

2013-11-03 Thread Timo Hanke
I think the communication would have to go the other way around. Trezor
has to commit to a value First. Like this:

Trezor picks random s and sends S=s*G to computer, keeping s secret.
Computer picks random t and sends t to Trezor.  Trezor makes r := s+t
its internal master private key with corresponding master public key 
R := (s+t)*G. Since R = S+t*G, the computer can verify the master
public key. As you say, the computer can then store R and can later
verify for each derived pubkey that it was indeed derived from R, hence
from his own entropy t.

However, Trezor could not use straight bip32 out of the box. The
chaincode would have to be something like SHA(R). And the seed (that
gets translated to mnemonic) would be r itself, making it 256 bit
instead of only 128 bit.

If the longer seed is bearable then this is a good way to do it.

One question remains: if you only write down the mnemonic how can you be
sure that it is correct and corresponds to the secret in Trezor? You
cannot verify that on paper. You would have to restore it on some
device, eg another empty Trezor, and see if it brings up the same master
pubkey. Right? 

Timo

On Sun, Nov 03, 2013 at 08:03:54AM +0100, Thomas Voegtlin wrote:
 
 Le 03/11/2013 07:41, Timo Hanke a écrit :
 No. You mean the computer would use B for this check? (k,K) could
 be rigged by Trezor, who computes b as k-a. Timo
 
 I was just asking a question, in order to understand how this device
 works, and what are its requirements.
 if you think you can help, please explain.
 
 

-- 
Timo Hanke
PGP 1EFF 69BC 6FB7 8744 14DB  631D 1BB5 D6E3 AB96 7DA8

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal to replace BIP0039

2013-11-03 Thread Thomas Voegtlin

Le 03/11/2013 08:40, Timo Hanke a écrit :
 I think the communication would have to go the other way around. Trezor
 has to commit to a value First. Like this:

 Trezor picks random s and sends S=s*G to computer, keeping s secret.
 Computer picks random t and sends t to Trezor.  Trezor makes r := s+t
 its internal master private key with corresponding master public key
 R := (s+t)*G. Since R = S+t*G, the computer can verify the master
 public key. As you say, the computer can then store R and can later
 verify for each derived pubkey that it was indeed derived from R, hence
 from his own entropy t.

I'm not sure how this differs from what I wrote...

However, if this is how it works, then my question remains:
The computer has no proof to know that pubkeys derived through bip32's 
private derivations are derived from its own entropy...
This verification would only work for public (aka type2) derivations.

.. but maybe Trezor works in a different way? I think an explanation 
from slush would be needed.


 However, Trezor could not use straight bip32 out of the box. The
 chaincode would have to be something like SHA(R). And the seed (that
 gets translated to mnemonic) would be r itself, making it 256 bit
 instead of only 128 bit.

 If the longer seed is bearable then this is a good way to do it.

 One question remains: if you only write down the mnemonic how can you be
 sure that it is correct and corresponds to the secret in Trezor? You
 cannot verify that on paper. You would have to restore it on some
 device, eg another empty Trezor, and see if it brings up the same master
 pubkey. Right?

I guess you have to trust Trezor that it derives R from r



--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development