--- Log opened Mon May 03 00:00:44 2021
01:44 -!- nsh [~lol@wikipedia/nsh] has quit [Quit: ZNC - http://znc.in]
01:44 -!- ensign [~ensign@integer.musalbas.com] has quit [Quit: ZNC - http://znc.in]
02:06 < elichai2> Anyone knows of side-channel resistant implementations of BIP39?(or opinions on why it doesn't matter :) )
02:39 < gmaxwell> BIP39 is kinda lulzy and chances are sidechannels aren't your biggest problem if you're making handling private keys encoded as words?
02:40 < gmaxwell> the string to seed direction is just hashing and should be reasonably well behaved sidechannel wise (or at least as much as you can get without special hardware).
02:40 < gmaxwell> the randomness to string direction ought to be made constant time, but would be kind of obnoxious to do so.
02:41 < gmaxwell> though at least attackers can't generally stimulate you to generate a new secret seed on demand while the measure your sidechannels.
02:49 < gmaxwell> to make it constant time someone would need to \0 pad the words out to constant length and do a cmov sweep through them. Fortunately the longest word is 8 bytes, so they could be 0 extended to 64 bits, and you only have to do about 187 64-bit cmovs per bit of input. :P
03:28 -!- ensign [~ensign@5.135.157.17] has joined #secp256k1
03:31 -!- nsh [~lol@wikipedia/nsh] has joined #secp256k1
04:37 < elichai2> yeah, you need to do some cmovs, constant equality which isn't easy because lengths are different(as you said pad with \0), and some implementations use hashmaps or indexing in arrays using "secret" values (to translate index to word/string)
04:38 < elichai2> all these are "side-channel" though, so what bigger problems are you referring to?
04:42 < gmaxwell> the fact that it's commonly used as a brainwallet (though the spec discourages, the design is setup to accomidate, e.g. checkvalue errors are warnings), that it doesn't encode any important metadata (like what kind of derrivation scheme does it go with),  and just that generally manually handling private keys is pretty risky.
04:43 < elichai2> hmm that's fair, but if the wallet generates the seed including a checksum, and you just save it then I think it's generally kind of fine? (although it still doesn't encode the derivation etc which is problematic)
04:45 < elichai2> trying to decide if I want to try and write a bip39 library that tries to be constant time, as the one's I looked at are all horrible (even randomness->words is either not constant time or uses indexing-an-array-by-secrets)
05:18 < gmaxwell> the problem isn't so much saving the checksum it's that its not mandatory on the recieve side.  Like anything else for security the metric of quality isn't really if you can use it safely but how hard it is to use unsafely.  It's at least somewhat popular due to the hardware wallets, so it would probably be good for better implementations to exist.
05:19 < gmaxwell> One problem is that there are many different word lists, and I bet they don't all have a maximum word length of 8 bytes... so it might be kinda of a pita to make a constant time implementation that works with other word lists.
05:29 < elichai2> well almost all implementations include their own wordlists (according to the ones in bip39) so I can ship my own list and manually(or at initialization time) pad them
05:30 < gmaxwell> Right but people use different lists to accomidate different langauges.
06:17 < real_or_random> gmaxwell: > "I would have done it long ago but find it mind numbing to try to get stuff working on a system I can't log into and only get info from logs. :P"
06:18 < real_or_random> gmaxwell: When I worked on the Cirrus CI stuff, I was seriously considering adding an option for a reverse shell.
06:19 < real_or_random> I still think that's a valuable idea but I haven't ever seen anything like this in any project.
06:20 < gmaxwell> I think travis forbid you from doing it.
06:20 < gmaxwell> in the good old days of classic CI with jenkins and whatnot, that was just the norm-- shell into the ci sever, run the commands manually, then paste your shell history into the jenkins config webpage. :P
06:24 < sipa> real_or_random: at least now it's just a docker image which we control ourselves, and a shell script running in it, mostly
06:25 < sipa> so .cirrus.yml and its semantics isn't something you can easily replicate, everything below it should be
06:25 < sipa> (so far i've just been trial-and-erroring though...)
06:46 < real_or_random> indeed
09:02 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 252 seconds]
09:08 -!- queip [~queip@unaffiliated/rezurus] has joined #secp256k1
09:48 -!- roconnor [~roconnor@host-45-58-195-183.dyn.295.ca] has joined #secp256k1
09:54 -!- jonatack [~jon@88.127.52.83] has quit [Ping timeout: 252 seconds]
09:56 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has joined #secp256k1
12:32 < sipa> real_or_random: it seems cirrus is really starved for macOS resources... those CI tasks run, but really slowly
12:32 < sipa> i think we can consider reducing how many we have
12:53 -!- Netsplit *.net <-> *.split quits: belcher, ariard
12:55 -!- Netsplit over, joins: belcher, ariard
13:54 < gmaxwell> maybe make some jobs only run against Master?
13:54 < gmaxwell> even if something gets missed it'll get caught after it's merged.
17:06 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 252 seconds]
17:19 -!- belcher [~belcher@unaffiliated/belcher] has joined #secp256k1
--- Log closed Tue May 04 00:00:45 2021