--- Day changed Sun Oct 21 2018
02:10 < stevenroose> andytoshi: yeah the trezor does. So every action is either protected with a pin, passphrase or both or with a "OK/Cancel" dialog and all of those dialogs are responses to the host
02:11 < stevenroose> So -> ChangePin <- ButtonRequest -> ButtonAck <- PinRequest(current) -> PinAck(pin) <- PinRequest(new1) -> PinAck(pin) <- PinRequest(new2) -> PinAck(pin) <- Success
02:12 < stevenroose> With a SignTx there will be PinRequests or PassphraseRequests in an order that is not documented on purpose, so you need to be able to handle all random intermediary interactoins
12:27 < andytoshi> :/
12:28 < andytoshi> i've given up on trezor for much less ridiculous things than that. glad i didn't try to keep going
21:39 < stevenroose> I kinda trust their company more than Ledger. Not sure why, mostly just gut feeling. They seem to have a lot more skin in the game with the pool. Plus they're not American. Eastern European governments wouldn't even know *how* to install a backdoor on the device if they would want to :D Compared with a US company..
21:40 < stevenroose> Btw, does rust-bitcoin have a BIP32 impl? With key derivation and xpub nodes etc?
21:41 < stevenroose> Aha, https://docs.rs/bitcoin/0.14.2/bitcoin/util/bip32/index.html Sorry for the bother.
21:47 < andytoshi> ledger is not american
22:01 < stevenroose> Oh they're French
22:01 < stevenroose> Didn't know :|
22:01 < stevenroose> Btw, https://gist.github.com/stevenroose/ba680c0d735293fdf3d43f58c087e06a pretty happy with the result, only minor nit is that the user sees those two generics of which one is internal. But I don't think it's possible to hide it.
22:02 < gmaxwell> stevenroose: these devices are all made in china, fwiw.
22:03 < stevenroose> So basically every response is unknown so matches to see if interaction is required. For most flows, the interaction should be quite clear so a path can be asserted
22:03 < stevenroose> gmaxwell: true..
22:03 < stevenroose> gmaxwell: https://www.reddit.com/r/TREZOR/comments/7h9bpc/where_trezor_is_actually_made/dqp8am8/
22:04 < andytoshi> stevenroose: have you heard of session types? they would be a good fit here, though they're super unergonomic in rust
22:05 < andytoshi> also, nothing in your link cites the origin of their ICs
22:08 < gmaxwell> The way existing hardware wallets all work they are very easy to nearly invisibly backdoor.
22:09 < gmaxwell> Personally, I wouldn't use one at all due to this. too attractive a target.
22:09 < gmaxwell> they could easily use a different design that would make it much harder to meaningfully backdoor them, but so far none do.
22:10 < andytoshi> iirc you would recommend having an offline decade+-old laptop and use that as a hw wallet?
22:10 < gmaxwell> yes. Though I'd probably still choose a newish laptop over a hardware wallet, generally.
22:11 < gmaxwell> If your goal is some massive cointheft you get a lot more theft per dollar backdooring HW wallets than laptops... esp since hardware wallets are simple enough that its realistic to clone the whole product, not so for a laptop.
22:12 < stevenroose> But a backdoores HW could only leak when confiscated, right? I mean as long as you know what your software is doing with the device.
22:12 < andytoshi> stevenroose: no :)
22:12 < gmaxwell> :( not at all.
22:12 < gmaxwell> A backdoored hardware wallet can leak your keys via the signatures.
22:12 < stevenroose> In the nonces?
22:13 < gmaxwell> Yes.
22:13 < stevenroose> Damn
22:13 < gmaxwell> Now: in multisig, thats another matter, I'd be much more willing to use one in a multisig.
22:14 < gmaxwell> stevenroose: nonce can be selected not only to leak, but to leak using public key encryption so only the attacker can decode the leak...
22:15 < stevenroose> gmaxwell: yeah I envisioned it as soon as I realized the nonces :D
22:15 < stevenroose> What about that RFC6979 with deterministic nonces?
22:16 < gmaxwell> You can't tell if its using 6979 on any particular signature.
22:16 < stevenroose> Or allowing the software providing nonces to the device fwiw.
22:16 < andytoshi> there is no way to for a hw wallet to prove that it is using 6979, and also the proof itself could sidechannel data (though the proof won't ever hit the blockchain so this is a bit of a barrier)
22:17 < andytoshi> stevenroose: you're close ... if the host provides the nonce entirely, then it can learn the device's secret key
22:17 < gmaxwell> If the host software provides nonces to the device outright then the host software can just recover the secret key.
22:17 < gmaxwell> There is a countermeasure but it's more complicated than that, and AFAIK no hardware wallet implements it.
22:17 < stevenroose> Grrr :D The nonce is commited with the public nonce R, right?
22:17 < gmaxwell> Though I've been bugging HWW makers about this problem since.. well, before any of them existed.
22:17 < stevenroose> So if I generate the nonce in parallel (RFC), can't I check the public nonce part?
22:18 < gmaxwell> stevenroose: you can't generate an RFC6979 nonce without knowing the secret key.
22:18 < stevenroose> Oh yeah ofc it's not just the message hash
22:18 < stevenroose> Stupid
22:18 < stevenroose> me
22:19 < andytoshi> stevenroose: the solution is essentially to sign-to-contract some host-provided data (which should be random and high-entropy)
22:19 < gmaxwell> If you do know the secret key, you can check... and the device just needs to use RFC6979 the first dozen times you use it, then switch to evil nonces... or use 6979 unless it sees a payment to and address with a certian pattern, or makes change with more than a certian value...
22:20 < gmaxwell> RFC6979 is more about making it easy to audit for honest mistakes, not preventing backdoors.
22:20 < andytoshi> i helped someone take apart signatures from an opendime that s/he had extracted the secret key from, and i was unable to reproduce the nonces deterministically
22:20 < andytoshi> that doesn't mean they weren't deterministic ... but i tried very hard to find evidence that they were. they weren't using 6979 in any obvious ways
22:23 < gmaxwell> In any case, as andytoshi was saying, you can do a protocol where the host helps randomize the nonce... and that kills the sidechannel.  But it requires another round trip with the device and varrious complication.
22:23 < gmaxwell> like if the device doesn't have enough memory, you might need to stream the transaction through twice...
22:23 < gmaxwell> (once to generate the nonces to be randomized, again to actually sign)
22:26 < gmaxwell> The fix is that the device commit to its nonce, then the host gives the device a random tweak to adjust the nonces with in a provable way...   so nonce is k,  R=kG.  Send the host H(kg).  host responds with a random value m.  now sign with k' = k+m.  Host computes H(R-mG) and check it matches the commitment send before telling the device m.
22:26 < gmaxwell> or similar.
22:28 < andytoshi> the device still wants to hash the tx into its nonce, no? so it still needs the transaction twice?
22:28 < andytoshi> now it needs it before precommitting
22:29 < stevenroose> andytoshi: bumped into this: https://github.com/rust-bitcoin/rust-bitcoin/pull/181
22:29 < gmaxwell> if the device has enough memory to store 64 bytes per signature, I think you can avoid sending the transaction twice.
22:29 < andytoshi> that sounds true
22:30 < andytoshi> stevenroose: yeah, we could do that .. it's sorta blocked (but not really) on refactoring the `network` module
22:30 < gmaxwell> andytoshi: previously I'd described the device doing k' = k + H(kG||m)  (e.g. sign to contract) but I think that thats really just a fiat-shamiry transform of the simpler protcol I described above.
22:30 < gmaxwell> You can't use an actual FST to avoid the round trip without leaving a 1-to-few bit channel, in any case.
22:31 < andytoshi> agreed, the protocol you described is just as secure (s2c does this weird thing where it's -both- FS and interactive)
22:32 < andytoshi> i usually describe this in terms of s2c, even though it's less efficient, because i can portray s2c as a user-visible feature, and if they ever give me that, then i can overload it as a sigh-channel-eliminator
22:32 < gmaxwell> Fair enough, indeed.  The FST version is somewhat more robust against doing it wrong.
22:33 < andytoshi> and because i can explain s2c in handwavey terms "you make the nonce commit to some message" "and if the message is random then it becomes a commitment to randomness, which "obviously" can't sidechannel data out"
22:33 < andytoshi> which is purely a marketing trick, but i think it helps
22:34 < andytoshi> my goal with ledger was to just write the code for it and PR it, but i haven't found the time to figure out their sdk :/
23:06 < stevenroose> andytoshi: it's not worth considering showing like a part of the private key in Debug, right? can only be subject to a lot of debate about usefullness vs risk
23:14 < andytoshi> agreed
23:57 < ariard> aaaaah github seems down can't review rust-lightning right now :(