--- Day changed Thu Oct 08 2015
01:22 -!- CodeShark_ [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #secp256k1
01:23 -!- CodeShark_ [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Client Quit]
01:23 -!- CodeShark_ [CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #secp256k1
01:23 -!- CodeShark_ [CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Client Quit]
01:24 -!- CodeShark_ [CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #secp256k1
01:25 -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 246 seconds]
01:26 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #secp256k1
01:29 -!- CodeShark_ [CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 250 seconds]
02:08 < jonasschnelli> Is it a good practice to call secp256k1_context_randomize with 256bit entropy from /dev/urandom?
02:09 < sipa> yes, but not portable
02:09 < jonasschnelli> For POSIX only, right.
02:10 < jonasschnelli> or would it make sense to implement your bitcoin-core Fortuna patch? (as a custom library)?
02:16 < CodeShark> on windows, openssl does some weird heap crawling crap for entropy
02:17 < CodeShark> if you get entropy when the program first launches it returns quickly...but if you wait until the program has already loaded it can take forever to return
02:17 < jonasschnelli> hmm... is there no platform independent entropy library (in c)?
02:17 < jonasschnelli> (next to openssl)
02:17 < sipa> CodeShark: see #5885 for a patch that implements various entropy-gathering algorithms
02:18 < jonasschnelli> https://github.com/bitcoin/bitcoin/pull/5885
02:18 < jonasschnelli> also a good read in that field: http://blog.cr.yp.to/20140205-entropy.html
02:24 < CodeShark> what about HW RNGs?
02:26 < CodeShark> is that a standard op in modern CPUs already? :)
02:27 < jonasschnelli> CodeShark: for our hardware wallet we use http://www.atmel.com/devices/ATAES132A.aspx
02:28 < jonasschnelli> FIPS RNG
02:29 < CodeShark> looks nice
02:34 < CodeShark> small and simple, but I guess it does the trick
02:34 < CodeShark> cheap and low power
02:34 < CodeShark> so how does it work? detuned oscillators?
02:37 < CodeShark> oh..."On power-up, the stored seed
02:37 < CodeShark> is read from the EEPROM, cryptographically combined with the hardware RNG output, and then stored in SRAM.
02:37 < CodeShark> Whenever a random number is required, this SRAM Seed is cryptographically combined with the hardware RNG
02:37 < CodeShark> output and the optional input seed to create both a new SRAM Seed and the random number."
02:41 < jonasschnelli> So right. TRNG requires EEPROM interaction (reduced the lifespan).
02:43 < jonasschnelli> CodeShark: ATMEL does not reveal how they generate entropy. But we have tested it against one of the FIPS standard tests (took a night or so). But even with that prove we xor the entropy with additional sources (https://github.com/digitalbitbox/mcu/blob/master/src/random.c#L84).
02:43 < jonasschnelli> But offtopic probably
02:44 < sipa> andytoshi, gmaxwell: i stumbled upon an environment in which computing the signing table at initialization is preferable to having it precompiled: if you want to compile the library using emscripten to asm.js, to run in a browser
02:46 < sipa> and want to keep the js code small
04:08 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 244 seconds]
04:48 < wumpus> jonasschnelli: cjdns has a nice collection of entropy gatherers for various platforms (on Linux it uses /dev/urandom, sysctl(RANDOM_UUID) and /proc/sys/.../uuid) https://github.com/cjdelisle/cjdns/tree/master/crypto/random/seed   ... that's quite paranoid; though using only RtlGenRandom on windows seems weak in comparison
04:50 < jonasschnelli> wumpus: Nice! Thanks. Will have a close look at it soon... maybe it would make sense to form a independent library out of it.
04:50 < wumpus> but probably we want to fatctor our sipa's fortuna patch into a random library
04:51 < wumpus> yes
04:55 < jonasschnelli> wumpus: sipa's fortuna patch would first need a (not sure if trivial) rewrite to c
04:58 < wumpus> why?
05:00 < wumpus> though I don't think it would be very difficult
05:05 < jonasschnelli> wumpus: I would prefer a c library over a c++ one. I have a use case for embedded environments.
05:09 < wumpus> it doesn't seem to be relying on any c++ features, just using classes for organization
05:09 < wumpus> although the entropy gathering part will not help you in an embedded environment
05:10 < wumpus> (ok unless it's "embedded" linux/windows)
05:12 < wumpus> any ideas for the name of the library?
05:14 < jonasschnelli> wumpus: In my case i have a chip based RNG (proprietary interface) but i could still use the Fortuna entropy accumulator, etc.
05:14 < wumpus> ooh a "libfortuna" exists: https://github.com/waitman/libfortuna http://lists.randombit.net/pipermail/cryptography/2013-July/004789.html
05:14 < jonasschnelli> hmm... interesting.
05:15 < wumpus> jonasschnelli: sure, but I first thought your question was about gathering initial entropy from the OS, wiser now :)
05:16 < jonasschnelli> wumpus: Right. I also looking for a way to initial seed secp256k1 with some non-openssl-generated entropy. So two birds with one stone.
05:29 < wumpus> not sure that library is a very good starting point: it contains quite some cruft (md5, sha1? some abstractions from pgsql), doesn't seem actively maintained and has no tests. Its interface however is nice and simple: just fortuna_get_bytes and fortuna_add_entropy. Internally it supports multiple contexts, but not exposed on the API
05:29 < wumpus> it also has no functions for OS entropy gathering - initial entropy has to be provided by the client
05:29 < wumpus> but anyhow 'libfortuna' is taken
05:45 < jonasschnelli> wumpus: what about libprng?
05:53 < wumpus> exists: https://bitbucket.org/marpin/prng-library/src  seems to be a collection of prng algorithms, not a single as-secure-as-possible one
05:55 < jonasschnelli> wumpus: hmm... libfortunaprng .. :)
05:55 < wumpus> :D
05:56 < wumpus> sgtm
08:53 <@gmaxwell> sipa: hah. you found one enviroment! :P At the same time,... perhaps the slowness of that enviroment makes init bad?
08:54 < sipa> gmaxwell: that environment seems very fast in practice
11:44 -!- nullbyte [NSA@gateway/vpn/mullvad/x-hburmhykqxbnphkx] has joined #secp256k1
13:52 -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #secp256k1
13:56 -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Client Quit]
14:01 <@gmaxwell> Anyone want to go implement sign to contract.
15:50 <@gmaxwell> E3- 1230 @ 3.2GHz ecdsa_verify: avg 64.2us
15:50 <@gmaxwell> E5 2.40GHz ecdsa_verify: avg 60.6us
15:54 <@gmaxwell> I'm surprised at how much better the haswell part is there (clock per clock)
20:31 -!- nullbyte [NSA@gateway/vpn/mullvad/x-hburmhykqxbnphkx] has quit [Quit: leaving]