đź“… Original date posted:2020-03-24
đź“ť Original message:Hi Tim,
Hm, so what vectors is this supposed to mitigate? Leaking through the
> generated public keys? Anything else?
The main thing it’s protecting against is the stealing of your funds by
malicious hardware & software. There are some side benefits as well though.
- What are you trying to achieve? You seem to describe how you get
> from the setup to the goal in four steps but I don't understand what
> the setup is or what the goal is. (What's a storage solution?)
“Storage solution” is however you’re storing bitcoins today. Could be 12
words on some paper plus a computer running electrum. Could be a Ledger +
computer. Point is this technique works regardless of how you’re storing
your bitcoin.
- "all SW being compromised" do you mean "SW and HW compromised"? Note
> that SW and HW are parties in Pieter's writeup, not just abbreviations
> for software and hardware.
Yeah — if you split the SW party into two, “generator” and “validator” some
interesting and useful security properties emerge.
- Where are the two stages? You mention four steps.
“Generator” and “validator”. The generator creates and passes on receiving
addresses and withdrawal transactions (while remaining offline). The
validator double checks everything the generator did..
It works best if the validator is written entirely independently of the
generator.
- Where do you run the external software? On a second SW? Is this the
> second stage?
Yes
- Do you use unhardened derivation?
It’s an open ended solution — it would work with a (presumably
non-trivial/random) unhardened derivation just fine.
- What's a k commitment?
It is one of the proposed solutions presented (collected?) by Peter in this
thread. As I understand it k is used to generate R in the signature. By
committing to some k value the hardware wallet can’t “sneak out” your
private key(s) in the R value.
Best,
Dustin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200324/db2f881c/attachment.html>;
Dustin Dettmer [ARCHIVE] /
npub1x5…kqsqu
2023-06-07 18:23:14
in reply to nevent1q…hun6
Author Public Key
npub1x54n25utwk7dzwzvk2v0aknptez5gxdwcyrxx2wgc0lnhgvwu72qmkqsquPublished at
2023-06-07 18:23:14Event JSON
{
"id": "c8f3cba17c2ece99ba974e9ea8c210e34b69c3ab3b4981068f5b48ff8ee832cc",
"pubkey": "352b35538b75bcd1384cb298feda615e454419aec1066329c8c3ff3ba18ee794",
"created_at": 1686162194,
"kind": 1,
"tags": [
[
"e",
"dc57ed046dd17bfbde2b48ae5c93b4197f33cb78e8d235e283ed60bfa1fc7219",
"",
"root"
],
[
"e",
"2e01368e199be14c8d6fad4cc006ccb7ca35ef99e0a17b26d297d8a8e1d29245",
"",
"reply"
],
[
"p",
"c6d7a400897460d9a2c07bbad58731b6d04267edd75af42af45f471b04581ec2"
]
],
"content": "📅 Original date posted:2020-03-24\n📝 Original message:Hi Tim,\n\nHm, so what vectors is this supposed to mitigate? Leaking through the\n\u003e generated public keys? Anything else?\n\n\nThe main thing it’s protecting against is the stealing of your funds by\nmalicious hardware \u0026 software. There are some side benefits as well though.\n\n - What are you trying to achieve? You seem to describe how you get\n\u003e from the setup to the goal in four steps but I don't understand what\n\u003e the setup is or what the goal is. (What's a storage solution?)\n\n\n“Storage solution” is however you’re storing bitcoins today. Could be 12\nwords on some paper plus a computer running electrum. Could be a Ledger +\ncomputer. Point is this technique works regardless of how you’re storing\nyour bitcoin.\n\n - \"all SW being compromised\" do you mean \"SW and HW compromised\"? Note\n\u003e that SW and HW are parties in Pieter's writeup, not just abbreviations\n\u003e for software and hardware.\n\n\nYeah — if you split the SW party into two, “generator” and “validator” some\ninteresting and useful security properties emerge.\n\n - Where are the two stages? You mention four steps.\n\n\n“Generator” and “validator”. The generator creates and passes on receiving\naddresses and withdrawal transactions (while remaining offline). The\nvalidator double checks everything the generator did..\n\nIt works best if the validator is written entirely independently of the\ngenerator.\n\n - Where do you run the external software? On a second SW? Is this the\n\u003e second stage?\n\n\nYes\n\n - Do you use unhardened derivation?\n\n\nIt’s an open ended solution — it would work with a (presumably\nnon-trivial/random) unhardened derivation just fine.\n\n - What's a k commitment?\n\n\nIt is one of the proposed solutions presented (collected?) by Peter in this\nthread. As I understand it k is used to generate R in the signature. By\ncommitting to some k value the hardware wallet can’t “sneak out” your\nprivate key(s) in the R value.\n\nBest,\nDustin\n\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200324/db2f881c/attachment.html\u003e",
"sig": "53328c14390779144650756873df930b08b1489b3c69bc09bed6f272690cb8cb165dbe680f714bc7dbd31f028cac9f8be197c76a730737c7ddd5ee724f8cc3ba"
}