📅 Original date posted:2013-11-03
📝 Original message: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
Thomas Voegtlin [ARCHIVE] /
npub10f…7ej47
2023-06-07 15:08:33
in reply to nevent1q…t7cw
Author Public Key
npub10f96gqrsu4qpygfgvuvzce47aavjvql703egfde0l2hua8dzpszs67ej47Published at
2023-06-07 15:08:33Event JSON
{
"id": "f2d98c49a23f1c7224168db8fa9a5f8ed5fd755c2b6fb21f6e80bd39f76099ff",
"pubkey": "7a4ba40070e54012212867182c66beef592603fe7c7284b72ffaafce9da20c05",
"created_at": 1686150513,
"kind": 1,
"tags": [
[
"e",
"29113580fa19bfa912e033228b5744547f424bd6ae7dcc6dbdef306e0b87998e",
"",
"root"
],
[
"e",
"ebbab7f340b7c7cb1e91d23ae0c1c369d9f292c6c99d8f05003643c5750147a1",
"",
"reply"
],
[
"p",
"6b41dfcce682764d40c00fd6580a99614b6bbe8a8332085dea07afbc47ba9e8f"
]
],
"content": "📅 Original date posted:2013-11-03\n📝 Original message:Le 03/11/2013 08:40, Timo Hanke a écrit :\n\u003e I think the communication would have to go the other way around. Trezor\n\u003e has to commit to a value First. Like this:\n\u003e\n\u003e Trezor picks random s and sends S=s*G to computer, keeping s secret.\n\u003e Computer picks random t and sends t to Trezor. Trezor makes r := s+t\n\u003e its internal master private key with corresponding master public key\n\u003e R := (s+t)*G. Since R = S+t*G, the computer can verify the master\n\u003e public key. As you say, the computer can then store R and can later\n\u003e verify for each derived pubkey that it was indeed derived from R, hence\n\u003e from his own entropy t.\n\nI'm not sure how this differs from what I wrote...\n\nHowever, if this is how it works, then my question remains:\nThe computer has no proof to know that pubkeys derived through bip32's \nprivate derivations are derived from its own entropy...\nThis verification would only work for public (aka type2) derivations.\n\n.. but maybe Trezor works in a different way? I think an explanation \nfrom slush would be needed.\n\n\n\u003e However, Trezor could not use straight bip32 out of the box. The\n\u003e chaincode would have to be something like SHA(R). And the seed (that\n\u003e gets translated to mnemonic) would be r itself, making it 256 bit\n\u003e instead of only 128 bit.\n\u003e\n\u003e If the longer seed is bearable then this is a good way to do it.\n\u003e\n\u003e One question remains: if you only write down the mnemonic how can you be\n\u003e sure that it is correct and corresponds to the secret in Trezor? You\n\u003e cannot verify that on paper. You would have to restore it on some\n\u003e device, eg another empty Trezor, and see if it brings up the same master\n\u003e pubkey. Right?\n\u003e\nI guess you have to trust Trezor that it derives R from r",
"sig": "3e07d80911ee562c225c388fa6e16c8b22712376ea549f02715f2a5715c75c1b762fb1a892990e6e2e3418b5933734b401b39156f6d05bd0c935e85f364996bc"
}