Tim Ruffing [ARCHIVE] on Nostr: 📅 Original date posted:2020-03-22 📝 Original message:On Sat, 2020-03-21 at ...
📅 Original date posted:2020-03-22
📝 Original message:On Sat, 2020-03-21 at 12:59 -0400, Russell O'Connor wrote:
> Public keys are deterministic and can be spot checked. In fact,
> AFAIU if hardened HD key derivations are not used, then spot checking
> is very easy.
>
> While spot checking isn't ideal, my original concern with the
> synthetic none standard proposal was that it is inherently non-
> deterministic and cannot ever be spot checked. This is why anti-
> covert signing protocols are so important if we are going to use
> synthetic nonces.
If spot checking means checking a few instances, then I think this is a
pretty weak defense. What if the device starts to behave differently
after a year?
On Sat, 2020-03-21 at 21:29 +0100, Marko Bencun wrote:
> Practically speaking, most hardware wallets allow you to import your
> own BIP39 seed, so you can work around key generation attacks today,
> with a one time inconvenience at the start. However, with the signing
> nonce attacks, a user today has no protection.
>
How do you know that the device really uses your seed? This can only be
done by comparing the public keys output by the HW with a second
computation. Even if you use only non-hardened derivation, you need to
check the master (root) public key and that means you need compute the
master root public key once from the seed. You can't do this manually
on a sheet of paper after you rolled a few dice to generate your seed.
So you need to store the seed on a second device (if only for a short
time). And I think this defeats the purpose of a HW wallet.
And even if assume that spot checking and importing the seed works, the
problem is not solved. We still need a clearly specified full protocol
that we can analyze.
Best,
Tim
Published at
2023-06-07 18:23:12Event JSON
{
"id": "3ffaf538e1fc60f97b2956a4bc421c2d7771a718a151f5a0230bbe211abcb248",
"pubkey": "c6d7a400897460d9a2c07bbad58731b6d04267edd75af42af45f471b04581ec2",
"created_at": 1686162192,
"kind": 1,
"tags": [
[
"e",
"dc57ed046dd17bfbde2b48ae5c93b4197f33cb78e8d235e283ed60bfa1fc7219",
"",
"root"
],
[
"e",
"6d71e8def180bdfe0863e6b448170b8a7cc6b9dc1e6dac4440bfe64061e9b6ec",
"",
"reply"
],
[
"p",
"6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d"
]
],
"content": "📅 Original date posted:2020-03-22\n📝 Original message:On Sat, 2020-03-21 at 12:59 -0400, Russell O'Connor wrote:\n\u003e Public keys are deterministic and can be spot checked. In fact,\n\u003e AFAIU if hardened HD key derivations are not used, then spot checking\n\u003e is very easy.\n\u003e \n\u003e While spot checking isn't ideal, my original concern with the\n\u003e synthetic none standard proposal was that it is inherently non-\n\u003e deterministic and cannot ever be spot checked. This is why anti-\n\u003e covert signing protocols are so important if we are going to use\n\u003e synthetic nonces.\n\nIf spot checking means checking a few instances, then I think this is a\npretty weak defense. What if the device starts to behave differently\nafter a year?\n\nOn Sat, 2020-03-21 at 21:29 +0100, Marko Bencun wrote:\n\u003e Practically speaking, most hardware wallets allow you to import your\n\u003e own BIP39 seed, so you can work around key generation attacks today,\n\u003e with a one time inconvenience at the start. However, with the signing\n\u003e nonce attacks, a user today has no protection.\n\u003e \n\nHow do you know that the device really uses your seed? This can only be\ndone by comparing the public keys output by the HW with a second\ncomputation. Even if you use only non-hardened derivation, you need to\ncheck the master (root) public key and that means you need compute the\nmaster root public key once from the seed. You can't do this manually\non a sheet of paper after you rolled a few dice to generate your seed.\nSo you need to store the seed on a second device (if only for a short\ntime). And I think this defeats the purpose of a HW wallet.\n\nAnd even if assume that spot checking and importing the seed works, the\nproblem is not solved. We still need a clearly specified full protocol\nthat we can analyze. \n\nBest,\nTim",
"sig": "2f0a61b73117b679766fb2a668b49c737af594e79962a1a830fc21c27645c4fd42d2094b5b8f61abdfe4f9496c3d461466d2810ac9754669e9d600246468c457"
}