--- Log opened Mon Jul 29 00:00:24 2019
06:42 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-bhjvnsbayvdrcowf] has joined #secp256k1
08:48 < elichai2> We could use the same idea for ANS(or Anti Covert Channel) but to protect the private key by using p2c when you create the xpriv/xpub
08:50 < elichai2> (so you commit to `H(rand)`, the HW commits to xpub, you give it the rand and it calcs `d'=d+H(P||rand)` and return you the new xpub which you can easily verify. and then you discard of the randomness)
08:51 < elichai2> that way if either the host randomness or the HW randomness are valid then the resulting key is gonna use a valid randomness
08:55 < andytoshi> yes, and if you lose either randomness then you lose your keys
08:55 < andytoshi> there also isn't really a benefit since you need to really strongly bias keys to make them weak
08:56 < elichai2> why? If the host randomness is compromised everything should still be fine
08:56 < elichai2> andytoshi: i'm not scared it's biased, i'm scared it's 100% pre-known
08:57 < andytoshi> then you should use a multisig
08:57 < andytoshi> and also you should throw out whatever device you don't trust
08:57 < andytoshi> and just generate your keys with dice rolls or whatever
08:59 < andytoshi> (which, BTW, i would recommend anyway ... maybe generate 12 words with your device and 12 words with dice rolls. unfortunately bip32 makes this unnecessarily difficult)
09:00 < elichai2> The problem with multisig is that it is stateful
09:00 < elichai2> if you just want to carry your HW wallet with you you can't do that
09:01 < elichai2> i'm suggesting a way to add your own randomness/12 words / whatever in a way that is provable into the HW wallet
09:01 < elichai2> I would really like to not need to trust the randomness inside my ledger
09:02 < elichai2> (I still trust it more than my laptop, but I would like to diverse that trust a bit without needing to do multisignatures)
09:02 < andytoshi> ok, then generate (at least) half your words outside of the wallet
09:02 < andytoshi> your proposed solution is complicated (involves extra hashes etc) and fragile (increases the set of things you can lose)
09:03 < elichai2> why does it increases the set of things you can lose? nothing bad will happen if the host loses their randomness
09:03 < elichai2> you just lose that added value
09:03 < elichai2> and generating half of the words outside decreases the HW wallet security by half
09:22 < elichai2> (And about the trust I can argue the same about the nonces, if you don't trust your device to do deterministic nonces you shouldn't use it. BUT people are using it, and so do I because I still trust it more than my laptop, so I think changing the set of trustees from just the wallet to 1 of (wallet, host) is better)
09:28 < andytoshi> if you lose the host randomness you cannot reproduce your keys
09:29 < andytoshi> nonce bias is scary because it is very hard to verify and any bias is deadly and also you can insert undetectable bias and also you need new randomness for every single signature even when using the same keys
09:30 < andytoshi> but conveniently you never need to store or reproduce the nonces after-the-fact, so it's a reasonable solution to insert ephemeral randomness in some verifiable way
09:37 < elichai2> i'm not suggesting that you reproduce your keys every time. I'm suggesting that the HW stores it and you just verify that it creates the xpriv/xpub with it in them(using p2c). that's a one time thing, afterwards you can check once in a while that your addresses are still derived from the same original xpub that you verified
09:39 -!- roconnor [~roconnor@host-184-164-15-238.dyn.295.ca] has joined #secp256k1
09:39 < elichai2> what i'm suggesting has almost the same properties of ASN, you generate it once. you can verify it. you don't need to store it afterwards. and that way you get good randomness for the private keys even if the HW randomness was rigged
09:44 < andytoshi> ofc you need to store your private keys
09:44 < andytoshi> or rather, your seed
09:45 < andytoshi> you absolutely cannot store bitcoins on keys that are not reproducible
09:45 < elichai2> hmmmm
09:45 < elichai2> right. the seed backup
09:45 < elichai2> can you get from a private key to a seed or is this a one way function?
09:46 < andytoshi> it's one way
09:48 < elichai2> arghh, so I guess adding your own mnemonic words and then using some tool to verify that you get to the same resulting xpub is the only way :/
09:49 < andytoshi> yes, that accomplishes the same effect, but in a simpler fashion
09:49 < andytoshi> it is unfortunate that there's no way to publicly verify this
09:49 < elichai2> altough this is only verifiable by reconstructing the keys
09:49 < andytoshi> right
09:49 < andytoshi> which is dangerous, you've gotta thaw them and put them on a computer
09:49 < elichai2> yes
09:50 < elichai2> maybe if we used some 2 way function instead of HMAC
09:50 < andytoshi> that doesn't make any sense
09:50 < elichai2> (altough that changes the security properties)
09:50 < andytoshi> how can you generate indefinitely many keys from a single seed
09:50 < andytoshi> if the function is reversible
09:50 < elichai2> ctr mode?
09:50 < andytoshi> ctr mode does not violate the laws of combinatoris
09:50 < elichai2> no i'm not talking about from the xpriv downwords
09:51 < elichai2> just seed>xpriv
09:51 < andytoshi> wat
09:51 < elichai2> wait
09:51 < elichai2> i confused myself lol
09:51 < elichai2> you're right
09:52 < elichai2> yeah so ctr mode limits you to the size of the ctr, but isn't bip32 also limited to some amount somehow?
09:53 < andytoshi> not really no
09:53 < andytoshi> you can only generate 4bn keys per derivation level, but there's no inherent reason for that limitation, it was just a choice to simplify the protocol
09:59 -!- roconnor [~roconnor@host-184-164-15-238.dyn.295.ca] has quit [Read error: Connection reset by peer]
10:00 -!- roconnor [~roconnor@host-184-164-15-238.dyn.295.ca] has joined #secp256k1
10:28 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection]
10:34 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #secp256k1
11:18 -!- belcher [~belcher@unaffiliated/belcher] has joined #secp256k1
11:21 -!- reallll [~belcher@unaffiliated/belcher] has quit [Ping timeout: 248 seconds]
14:38 -!- fjahr [uid374480@gateway/web/irccloud.com/x-wbzyczhsyyayfsfl] has joined #secp256k1
15:49 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 258 seconds]
15:51 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
16:00 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
16:01 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
19:22 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-bhjvnsbayvdrcowf] has quit [Quit: Connection closed for inactivity]
21:18 -!- roconnor [~roconnor@host-184-164-15-238.dyn.295.ca] has quit [Ping timeout: 246 seconds]
21:53 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-qrzynwjvjlhfuiid] has joined #secp256k1
--- Log closed Tue Jul 30 00:00:25 2019