--- Day changed Wed Oct 12 2016 04:33 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #secp256k1 05:06 -!- benma [~benma@80-219-201-154.dclient.hispeed.ch] has joined #secp256k1 05:28 -!- benma [~benma@80-219-201-154.dclient.hispeed.ch] has quit [Remote host closed the connection] 05:29 -!- benma [~benma@80-219-201-154.dclient.hispeed.ch] has joined #secp256k1 05:29 < benma> query sipa 05:29 < benma> typo, sorry :P 05:30 < sipa> sipa: No such nick/channel 05:54 < nsh-> Once upon a midnight query, while sipa pondered, weak and weary, 05:54 < nsh-> Over the very quaint and curious codebase of bitcoin core- 05:54 < nsh-> While I nodded, nearly napping, suddenly there came a tapping, 05:54 < nsh-> As of some one gently rapping, rapping at my privmsg door. 05:54 < nsh-> “’Tis some benma,” he muttered, “tapping at my privmsg door— 05:54 < nsh-> No such nick/channel more.” 05:54 < nsh-> s/I/he/ 05:59 < sipa> LOL 06:05 < nsh-> :) 06:15 < sipa> ah, distinctly i remember, there was a utxo set member, and each separate bitcoin number threw its host upon the floor. eagerly i wished the morrow, vainly i had sought to borrow from my ebooks surcease of sorrow, sorrow for the mtgox ore 06:16 < benma> nsh-: :') this is awesome 06:16 < nsh-> ehehe 06:16 < nsh-> sipa++ 06:18 < sipa> for the rare and radiant coins lost long before... shameless here for ever more 06:47 -!- instagibbs [~instagibb@pool-100-15-114-3.washdc.fios.verizon.net] has quit [Ping timeout: 248 seconds] 08:22 -!- waxwing [~waxwing@93-33-110-54.ip44.fastwebnet.it] has joined #secp256k1 09:09 -!- bsm117532 [~mcelrath@38.121.165.30] has joined #secp256k1 09:11 < bsm117532> libsecp256k1 doesn't seem to use mlock() to prevent private keys from hitting swap. Is there a good reason why not? Would this be a desirable feature? 09:13 < andytoshi> bsm117532: for cross-system compatibility i believe, i'd be in favor of a PR that did this (with appropriate ifdef guarding) 09:16 < bsm117532> I'm not sure what the cross-compatibility issues would be. But cool, I'll put that on my radar for future work... 09:52 -!- benma [~benma@80-219-201-154.dclient.hispeed.ch] has quit [Remote host closed the connection] 09:53 < sipa> bsm117532: one argument, but not necessarily a good one, is that libsecp256k1 never stores keys... it only receives pointers to private keys, and soketines makes very short lived temporary copies/derived values 09:53 < sipa> mlock() is actually surprisingly hard to use well 09:54 < sipa> if your private data is soread out over many pages, you need to mlock large numbers of pages, potentially running into process limits 09:55 < bsm117532> sipa: Yes...the thought occurred to me that the design decision was intentional -- passing responsibility to the caller. 09:55 < bsm117532> At the moment I'm using this in conjunction with python-bitcoinlib (which uses openssl)...I might end up rewriting python-bitcoinlib to use libsecp256k1, and modifying the python module to do the mlocking... 09:56 < bsm117532> Have the bitcoin core test cases in python (from which python-bitcoinlib is derived) been rewritten to use libsecp256k1 or do they use openssl? 09:57 < sipa> for bitcoin core there is a PR to introduce an mlock oage manager 09:57 < sipa> basically a simple private malloc implementation that uses locked pages... which has the advantage that it can put all data to be protected together in the same oage(s) 09:58 < bsm117532> nice 10:03 < bsm117532> BTW sipa, I had some conversations with Christopher Allen at Scaling Bitcoin. I shared some of the things we're doing with Shamir's Secret Sharing that I've discussed with you before too. He reiterated that you and some of the other crypto folks are really down on secret sharing, preferring e.g. on-chain Schnorr signatures. 10:03 < bsm117532> AFAICT the reason people are down on secret sharing has to do with how and where the secrets are generated, and shares created. 10:04 < bsm117532> AFAICT there's nothing wrong with the underlying crypto, but I'll ask again...are there any fundamental crypto problems with secret sharing, or in using commitments in the prime field 4p+1 where p=the secp256k1 prime? 10:05 < gmaxwell> secret sharing is almost always pretextual snake oil security when considered against actual threatmodels that exist in the wild. 10:06 < bsm117532> Ok, can you elaborate? Consider for example using secret sharing to share a master private key among some family members and my estate lawyer, for use in the event of my death... 10:07 < gmaxwell> independantly, it's very easy to also make 'shamir secret sharing' that isn't-- which does somethign stupid that breaks information theoretic security... and _most_ implementations floating around that I encounter do so. 10:08 < sipa> bsm117532: the problem with shamir srcret sharing is that youneed to bring all secrets to the same device at some point 10:08 < bsm117532> I haven't found any implementation that I thought actually worked or was useful, FWIW, I wrote my own. 10:08 < sipa> if the only reason to do so is to eventually create a signature, doing so has no advantages over using a threshold signature scheme in the first place 10:10 < bsm117532> sipa: it emulates a threshold signature scheme, but keeps private the signers. (Christopher Allen mentioned you like Schnorr in this context -- and seems essentially equivalent to me) 10:10 < bsm117532> The secrets come together only at initial creation though, and when the secret is used (e.g. to sign). 10:10 < sipa> maybe you're talking about something that isn't exactly SSS 10:11 < sipa> ah, yes, my problem is with needing to bring all secrets together to sign 10:11 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Read error: Connection reset by peer] 10:11 < bsm117532> I'm adding Feldman's verifiable commitments. 10:11 < bsm117532> sipa: Why is that a problem though? 10:12 < bsm117532> It's what you want to do in the first place 10:12 < sipa> it means you need to trust the device on which they're brought together 10:12 < sipa> you don't need that for threshold signatures 10:12 < gmaxwell> bsm117532: so imagine in your case, you do this splitting thing, then you die.. then it's time to recover your keys and your keys are then handed over to your sister to move your funds. But then it turns out that she was evil (or infected with malware), and she just sweeps the funds to addresses she uniquely controlled. Your N of M really turned into a 1 of M when you want to use it. 10:14 < bsm117532> This is true if the secret being shared is a bare private key. But what if it's a pre-signed transaction instead? 10:14 < gmaxwell> So in all cases at a minimum you have a single point of failure at redemption, at a minimum. And the belief that the coins could only be spent according to the consent of N of M is pretextual. 10:15 < sipa> bsm117532: ah, yes, if the secret is by definition only use once, it's less of a problem 10:15 < gmaxwell> bsm117532: that would be more sensible, at least ignoring the verifyability problems... and the problems with potential transaction compatiblity. 10:15 < bsm117532> I agree, if you reconstruct a bare private key, there's no getting around that you have to trust the combiner. 10:16 < bsm117532> I'm creating a chain of transactions that are pre-signed, so I set the policy and delete intermediate keys, then share the pre-signed transaction. Of course, at the end of that chain there has to be a bare private key that I have to do something with. 10:16 < gmaxwell> as an aside, you can do that kind of threshold sweep using no secret sharing. 10:17 < bsm117532> How? 10:17 < gmaxwell> make a txn that spends your funds, plus a 0 value output paid to n of m of the other participants. 10:18 < bsm117532> What do you do with the 0 value output? (also, zero value outputs are allowed?) 10:19 < gmaxwell> You spend it. yes, the bitcoin system supports zero valued outputs (though 1e-8 btc would also work). 10:19 < bsm117532> gmaxwell: regarding verifiability problems: I'm also using commitments to the secret in 4p+1, so my implementation knows that the secret was reconstructed correctly or not. 10:20 < bsm117532> gmaxwell: I'm missing the point with your 0 value output. What's it for? 10:20 < gmaxwell> bsm117532: over a transaction rather than a secret? 10:21 < bsm117532> gmaxwell: the pre-signed transaction is the secret, divided into chunks mod p. 10:21 < gmaxwell> To prevent the transaction from being valid without the consent of the n of m. 10:22 < gmaxwell> bsm117532: And so if the dealer gives people consistent shares of jibberish, they still verify, but unseal to junk. So what did the verifyability buy? 10:23 < bsm117532> The dealer is the person who created the pre-signed transaction. It's not in his interest to do that. 10:23 < bsm117532> malware not withstanding... 10:24 < bsm117532> It's a denial of service attack, but can't take control of funds. 10:26 < bsm117532> gmaxwell: I see, you're using SIGHASH_ALL, creating a txn with one signature and another output that must be signed by others, distributing a partially-signed transaction? This works but results in larger transactions, and exposes my policy in public (unless...Schnorr). Using secret sharing I can keep off-chain the things that don't belong there and are none of anyone's business. 10:27 < gmaxwell> only in the unusual case that you die, under this discussion. 10:27 < gmaxwell> If you're expecting the shared redemption to be common, you're back to the fact that its security at recovery time is snake oil-- you're exposed to malware or dishonesty on the part of the single party recovering they key. 10:28 < gmaxwell> Right, so your assumption is that the dealer is flawless. Then why use the exotic novel crypto secret sharing over a transaction, and simply have him AES encrypt the transaction and secret share its key with far simpler and more conventional software (over, say GF8) or without secret sharing at all, by encrypting under the H() of all satisifying thresholds? 10:30 < bsm117532> That would be equivalent, I think. One of the reasons I went down this road is because one of the things being secret shared IS secp256k1 private keys. 10:37 < gmaxwell> It's just all a lot of snake oil, IMO. The overwhelmingly most common security risk that we would hope to protect from using multifactor security is security against that... which secret sharing doesn't provide (excepting the case where it's sharing a transaction). And plain encryption without secret sharing (e.g. using combinations for threshold) can do either of these things just fine. 10:38 < gmaxwell> which is worth mentioning because of the extremely high frequency of defective secret sharing code. 10:39 < bsm117532> Well I'm going to write or fix or use said code...so bad coding is no excuse. 10:40 < bsm117532> I see your arguments with sharing private keys. But when sharing transactions I agree they're equivalent. I'm not seeing any snake oil though... 10:47 < gmaxwell> The snake oil is that when people hear descriptions of secret sharing, they expect it will make them secure against dishonest participants, and against malware... which is pretty much never does. It would, in the case that a transaction were shared, though that gains limitations like it only works for specific fixed inputs. (which is fine for some cases, not fine for others) 10:52 < bsm117532> I see. I agree then. :-) 10:53 < bsm117532> Thanks for your thoughts sipa, gmaxwell! 11:03 < andytoshi> thanks everyone for being thorough and friendly, i've bookmarked https://botbot.me/freenode/secp256k1/2016-10-12/?msg=74679153&page=1 for the next time this conversation comes up 11:05 < bsm117532> Thanks andytoshi! 11:06 < bsm117532> gmaxwell: One reason to prefer secret sharing over your proposal: I can re-share secrets, adding to or removing from the participant set, without reconstructing the secret. Using AES would require reconstructing the secret and re-encrypting. 11:07 -!- instagibbs [~instagibb@pool-100-15-114-3.washdc.fios.verizon.net] has joined #secp256k1 11:58 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-tztvnmvmpbncvhfz] has quit [Read error: Connection reset by peer] 11:59 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-esevveyphvvmyxqo] has joined #secp256k1 13:21 -!- waxwing [~waxwing@93-33-110-54.ip44.fastwebnet.it] has quit [Read error: Connection reset by peer] 13:21 -!- waxwing [~waxwing@93-33-110-54.ip44.fastwebnet.it] has joined #secp256k1 14:19 -!- Netsplit *.net <-> *.split quits: nsh- 14:20 -!- waxwing [~waxwing@93-33-110-54.ip44.fastwebnet.it] has quit [Ping timeout: 265 seconds] 14:21 -!- nsh [~lol@wikipedia/nsh] has joined #secp256k1 14:21 -!- waxwing_ [~waxwing@93-33-110-54.ip44.fastwebnet.it] has joined #secp256k1 14:23 -!- Netsplit *.net <-> *.split quits: waxwing_ 14:24 -!- Netsplit *.net <-> *.split quits: jl2012 14:28 -!- Netsplit over, joins: waxwing_ 15:49 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-esevveyphvvmyxqo] has joined #secp256k1 16:00 -!- Netsplit *.net <-> *.split quits: jl2012 16:15 -!- Netsplit over, joins: jl2012 17:21 -!- waxwing_ [~waxwing@93-33-110-54.ip44.fastwebnet.it] has quit [Read error: Connection reset by peer] 17:21 -!- waxwing_ [~waxwing@93-33-110-54.ip44.fastwebnet.it] has joined #secp256k1 18:07 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-pfbxshzuuxpwumnt] has quit [Quit: Connection closed for inactivity] 18:59 -!- waxwing_ [~waxwing@93-33-110-54.ip44.fastwebnet.it] has quit [Ping timeout: 258 seconds] 22:52 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-yihxqmktnqkklyio] has joined #secp256k1