--- Log opened Sun Mar 24 00:00:04 2013
05:20 < warren> sipa:  spring break now.  I'd like to help complete your secp256k1 so I can build bitcoind entirely without openssl.  Do you have a list of tasks that need doing?
05:22 < warren> sipa: I suppose I'm supposed to not look at openssl in order to ensure secp256k1 has a clean, independent copyright?
05:23 < sipa> warren: cool!
05:23 < sipa> what i'm doing now is convert everything to C
05:24 < warren> ah, what's the goal there?
05:24 < sipa> easier to build, mostly
05:24 < sipa> i'm not using much of C++ anyway
05:24 < warren> me too, I've done mainly C and java
05:25 < sipa> apart from that, the largest blocker is import/export of secret keys
05:25 < sipa> which is only done in the wallet
05:25 < sipa> but you probably want to stay compatible with openssl-based builds
05:26 < warren> you mean implmeent the same interface
05:26 < sipa> no. serialization/deserialization of secret key data structures
05:27 < warren> have you been clean rooming this?
05:27 < sipa> the data structures are quite standard
05:27 < sipa> they are ASN.1 encoded
05:27 < sipa> i don't care about source API compatibility
05:27 < sipa> we can change bitcoin's code to match
05:28 < warren> Our API can be much simpler because it goals are limited?
05:28 < sipa> indeed
05:28 < sipa> right now, i have one public function:
05:28 < sipa> int VerifyECDSA(const unsigned char *msg, int msglen, const unsigned char *sig, int siglen, const unsigned char *pubkey, int pubkeylen);
05:29 < warren> sipa: can you list the current status and future TODO list somewhere?
05:29 < warren> sipa: what do you want the final library name to called?
05:30 < sipa> as long as we don't support anything beyond secp256k1, i think secp256k1 is fine as a name?
05:31  * warren checks to see what bitmessage uses. 
05:31 < warren> My primary goal is here of course.
05:31 < sipa> i have personally no interest in bitmessage, but if it happens to be able to use it, no problem of course
05:31 < warren> checking
05:33 < warren> They have "secp256k1" in several parts of their code.
05:33 < warren> anyway, I'll worry about them later
05:33 < warren> so yeah, stick to this name.
05:34 < warren> sipa: you want me to autoconf/automake it?
05:34 < warren> autotoolize
05:34 < sipa> warren: if you have experience with that, sure!
05:34 < warren> haven't done it in 4 years, would need to relearn
05:34 < warren> sipa: what license you want it to be?
05:35 < warren> brb shower
05:35 < sipa> good question
05:43 < sipa> added a TODO file
05:48 < warren> sipa: I assume MIT-style to be compatible with bitcoin?
05:49 < warren> sipa: do you have your existing patches to bitcoind so I can use that as an example of the other interfaces that need replacement?
05:49 < warren> *pushed anywhere
06:03 < sipa> warren: yes, but not a complete one
06:03 < sipa> only for replacing verification
06:03 < sipa> which was probably the easiest change in bitcoin
06:04 < sipa> but the changes in bitcoind are easy, i think i know what has to be done for those
06:05 < warren> sipa: which randomness source do we want to rely upon for key generatoin?
06:05 < sipa> regarding the secp256k1 library: just take the nonce as a argument for signing
06:06 < sipa> so the caller can still use OPENSSL_rand if necessary, but i'm beginning to like the idea of deterministic nonces
06:06 < warren> I haven't learned what is the typical meaning of "nonce" in bitcoin.
06:06 < warren> I know the general meaning.
06:06 < sipa> oh, sorry
06:07 < sipa> you're talking about key generation, not nonce generation
06:07 < sipa> anyway, same thing
06:07 < sipa> ECDSA signatures need a secret nonce
06:07 < sipa> that is: a value that is not reused and not known to an attacker
06:07 < sipa> typically (and in OpenSSL), it is just randomly generated
06:08 < sipa> but it is in fact possible to just calculate it as Hash(message + pubkey + privkey)
06:08 < warren> and that's just as secure?
06:09 < sipa> well, i'm in an e-mail discussion with Dan Boneh (prof. cryptography at stanford) about BIP32
06:09 < sipa> and he actually suggested that himself, as ECDSA is otherwise very vulnerable to bad PRNG's
06:10 < warren> hm
06:10 < sipa> anyway, i want secp256k1 to just be a fast math library basically
06:11 < sipa> so anything that requires dependencies will likely be pushed to the caller
06:11 < sipa> so any key "generation" function will just take random bytes chosen by the caller
06:13 < warren> ok, so it isn't secp256k1's job to decide where hte randomness comes from
06:13 < warren> that's a bitcoin implementation detail
06:13 < sipa> indeed
06:14 < sipa> i'll try to get the C version + some rough ideas for the secp256k1 API done today
06:14 < sipa> that'll make it easier to contribute, i guess
06:15 < warren> cool
06:15 < warren> sipa: does bitcoind internally have more entropy sources?
06:15 < sipa> no, it relies on OpenSSL
06:17 < sipa> ask for an hour
06:17 < sipa> *afk
11:17 < jgarzik> sipa: C version?  w00t
11:28 < gmaxwell> warren: the determinstic nonce is used by Ed25519 and seems fairly obviously secure so long as the hash function meets the other properties we require from it.
11:28 < gmaxwell> though, ed25519's usage does have distinct state for the nonce key, which is nice.
11:31 < gmaxwell> sipa: You could do a hybrid solution where if the provided nonce pointer is null you do H(message||key) if it is non-null you do H(nonce||message||key). The idea being that even if their RNG is bad doing that bounds the baddness. And then you can still get determinstic tests.
17:38 < sipa> warren: sorry, been busy working on bitcoind network stuff today
17:38 < sipa> and next week i'll have little time i feat
17:39 < warren> sipa: OK, I have mostly family stuff this week during spring break.  if I don't make progress this week I'll have plenty of time from May to work on this.
--- Log closed Mon Mar 25 00:00:05 2013