--- Day changed Sun Sep 06 2015 05:58 -!- jtimon [~quassel@159.30.134.37.dynamic.jazztel.es] has joined #secp256k1 07:34 < andytoshi> i'm a bit late to the game on #303 (remove unused assignment) but fyi there is an analagous unused assignment in the 32-bit field impl 07:35 < andytoshi> there is also an unused assignment on src/ecmult_gen_impl.h:148 which concerns me a bit, it's `bits = 0` and the intention of this statement is to zero out sensitive data 07:35 < andytoshi> but it's really obviously an unused assignment and i bet all compilers optimize it out 07:38 < sipa> best effort... 07:56 < andytoshi> would replacing it with a memset make it less likely to be optimized out? 07:59 < sipa> i guess, yes 08:00 < sipa> but even then 08:23 < fkhan> just curiosu, will the pubkey util methods (verify/decompress mainly) make a return in a later change? if not no worries, i remember it was done to simplify the api 08:32 < sipa> fkhan: no, they are no longer needed 08:32 < sipa> if parse succeeds, the pubkey is valid 08:32 < fkhan> yes ok, i see 08:32 < sipa> if you want to decompress, parse and reserialize with compress=0 08:35 < fkhan> ok understood, i hadn't read the header comments, but i'm wondering if there's any need for util methods in the interface wrappers, for now i've removed them 08:35 < fkhan> since the motivation was to provide a safe pass through wrapper, basically 08:46 < sipa> there iz no need to verify a pubkey object, because there is no way to create one 08:46 < sipa> compression and decompression are now done 'before' entering the library, so to speak 08:46 < sipa> rather than during 08:47 < sipa> you can always of course add higher level functions that do validation/decompression if there is a need for that, implemented using api calls 08:52 < fkhan> hmm yes, i might out of curiosity look at that a bit later 08:52 < fkhan> i'm having a bit of trouble cleaning up my branch currently, it seems 08:53 < fkhan> but fully understood on those higher level functions as a feature of the wrapper if desired 09:03 < fkhan> much appreciated on those clarifications 12:46 -!- jtimon [~quassel@159.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 256 seconds] 13:48 -!- jtimon [~quassel@159.30.134.37.dynamic.jazztel.es] has joined #secp256k1 15:04 < gmaxwell> andytoshi: we need to replace those zeroizations things with an actual zeroize function, that uses memset_s where available. and makybe some hack borrowed from elsewhere otherwise. 15:06 < sipa> implement memset in asm :) 15:08 < gmaxwell> Or even just memset and a pragma warn that your compiler doesn't have memset_s. 15:36 < sipa> i wonder, if you put a asm ("" ::: "mem") after a memset, shouldn't it precent that from erasing it? 15:37 < sipa> the asm, from gcc's point of view, is allowed to read any memory, so all memory changes before that point should be executed 15:38 < sipa> *prevent 15:38 < gmaxwell> Thats a bet that the asm is a total blackbox to the optimizer. 15:38 < sipa> i believe it is 15:38 < gmaxwell> yea, perhaps today. But is there a commitment to keep it that way? 15:39 < gmaxwell> in any case, it would be harmless to do... 15:39 < sipa> well is there a commitment that gcc won't switch to a log-structured RAm, that asynchronously changes the real ram? :) 15:39 < sipa> s/ram/virtual memory/ 15:42 < sipa> oh, it would need to be asm volatile ("":::"mem) 15:43 < sipa> without volatile, the compiler is allowed to remove the code if it doesn't use the output 16:27 < gmaxwell> sipa: you mean transactional memory support? :) 16:45 < sipa> basically :) 18:48 < TD-Linux> the linux kernel has actual memory barrier macros btw 18:48 < TD-Linux> depending on what you want, they might only be kernel mode though 18:49 < gmaxwell> well we want something we can't actually have. 18:49 < TD-Linux> e.g. do you want to wait for the entire cache to hit DRAM? 18:49 < gmaxwell> There is no way in C, even with memset_s to not have secret data leaks. 18:49 < gmaxwell> secret data will randomly, and in practice get splatted onto the stack. 18:49 < gmaxwell> and copied into unused padding space in structs, and passed all around. 18:50 < TD-Linux> right, that doesn't seem that surprising, you can't keep anything secret in your process 19:04 -!- btcdrak_ [uid52049@gateway/web/irccloud.com/x-akbnzzatotaupgci] has joined #secp256k1 19:08 -!- luke-jr_ [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 19:12 -!- Netsplit *.net <-> *.split quits: btcdrak, Luke-Jr 19:15 -!- btcdrak_ is now known as btcdrak 19:29 -!- gmaxwell_ [greg@mf4-xiph.osuosl.org] has joined #secp256k1 19:30 -!- gmaxwell_ [greg@mf4-xiph.osuosl.org] has quit [Changing host] 19:30 -!- gmaxwell_ [greg@wikimedia/KatWalsh/x-0001] has joined #secp256k1 19:31 -!- gmaxwell [greg@wikimedia/KatWalsh/x-0001] has quit [Ping timeout: 272 seconds] 19:36 -!- gmaxwell_ is now known as gmaxwell 20:05 -!- TD-Linux [~Thomas@about/essy/indecisive/TD-Linux] has quit [Ping timeout: 265 seconds] 20:13 -!- TD-Linux [~Thomas@about/essy/indecisive/TD-Linux] has joined #secp256k1 22:04 -!- TD-Linux [~Thomas@about/essy/indecisive/TD-Linux] has quit [K-Lined] 22:04 -!- TD-Linux [~Thomas@about/essy/indecisive/TD-Linux] has joined #secp256k1 22:18 -!- btcdrak [uid52049@gateway/web/irccloud.com/x-akbnzzatotaupgci] has quit [] 22:18 -!- btcdrak [uid52049@gateway/web/irccloud.com/x-nylyzwzzwdmiabsy] has joined #secp256k1 23:02 -!- luke-jr_ is now known as Luke-Jr