Quick recap

Present: jeremiah, jrand0m, mihi, nop, thecrypto

Meeting Log

[23:00] ok, topics> x.0: welcome x.1: spec questions x.2: elg issues x.3: sdk status x.4: release plan x.5: apps [23:00] is x == 0 or 1 or 2? [23:00] 22/7 [23:01] i think it's 0 [23:01] * jrand0m always logs, so wtf, why not. [23:01] 0.0: welcome. [23:01] hi. [23:01] 0.1: spec questions [23:01] anyone read the specs? :) [23:02] * mihi did. at least tried to [23:02] w0ah word [23:02] nope [23:02] what are the new ones? [23:02] occasionally [23:02] mihi> tried to, hard to read, bad language, incomprehensible organization, or just boring as fuck? [23:03] i'm just not familiar enough with crypto. the first part was very interesting. [23:03] jeremiah> specs are in cvs, and I post to iip-dev when they come out. current ones are: i2cp, i2np, i2p data structures, polling http transport proto [23:03] but when it got into detaily, you could have described how to brew an irish stew and i would not hav noticed ;) [23:04] sweet [23:04] lol mihi [23:05] although the format had its problems as well -don't have open office here, just ol' staroffice 5.2 [23:05] does star office 5.2 not read it? would you prefer .pdf or kludged html? [23:05] (or .txt? though txt wouldn't have pics or real formatting) [23:05] i'd prefer "old" .sdw format. [23:05] pdf if at all possible [23:05] or pdf [23:06] pdf is a one click solution. [23:06] * jrand0m edits in open office, reads in pdf [23:06] or appleworks [23:06] ;) [23:06] sxw is supported only in staroffice 6.0 and above [23:06] ah ok mihi [23:06] * jrand0m put out .sxw because last time people complained and wanted .sxw. when we publish we'll put out .sxw, .sdw, and .pdf [23:07] (or maybe .doc if i'm feeling dirty) [23:07] i would not mind .sdw.zip or .sdw.gz or .sdw.bzw either... [23:07] s/bzw/bz2/ [23:07] heh, zipped up, for sure. [23:08] the data structures spec may require a mod, and the network proto requires some fixed urls before release. [23:08] anyone have any questions on any of the four specs? [23:09] not at the momemet [23:10] ok. 0.2: elg issues [23:10] we're having some probs w/ elgamal encryption as specified on p13 of the data structures spec. [23:11] it may be key related, algorithm related, or implementation related. probably not implementation related, as this has been tested against two implementations. [23:11] if its algorithm related, we're going to want to update the spec prior to spec release to reflect whatever we need to change to make it work. [23:12] if its implementation or key generation related, we can publish the spec and fix the sdk when resolved. [23:13] thecrypto> any thoughts on whats up, or we waiting for nop to reply to the list (or here, if he's around and available to talk) [23:14] i'm trying to figure it out at the moment [23:15] *** Signoff: mihi (Ping timeout) [23:15] *** mihi_ (~none@anon.iip) has joined channel #iip-dev [23:15] 'k [23:15] *** mihi_ is now known as mihi [23:15] i have to run some math and through some other implementation and figure it out [23:15] i never had a problem with elgamal [23:15] last time i tested [23:16] *** Signoff: mihi ((null)) [23:17] with that benchmark [23:17] right, but the benchmark only tried one key [23:17] ahh [23:17] i can quite repeatedly get the error without any mods to the elg impl [23:17] didn't we have a wrong key message that came up? [23:18] yes, those still come up [23:18] *** mihi_ (~none@anon.iip) has joined channel #iip-dev [23:18] periodically (usually 2-4 times per keygen) [23:18] *** mihi (~none@anon.iip) has joined channel #iip-dev [23:18] *** mihi is now known as mihi_backup [23:18] *** mihi_ is now known as mihi [23:18] and we still get bad keys? [23:19] or something. [23:19] all that wrong size tests is "if ( (k0.length == PublicKey.KEYSIZE_BYTES) && (k1.length == PrivateKey.KEYSIZE_BYTES) ) {" [23:19] no value evaluation, etc. [23:20] one second [23:23] can you check if x the private key is < p [23:23] if (m.compareTo(CryptoConstants.elgp) >= 0) [23:23] already done. [23:23] (throw new IllegalArgumentException("ARGH. Data cannot be larger than the ElGamal prime. FIXME");) that exception is never thrown. [23:23] er x? hmm. [23:24] 'k. perhaps we may want to steal bouncycastle's or another impl's elg key gen algo [23:25] ok. 0.3> sdk issues [23:26] elg is pending, but other than that the sdk is very close to 0.8 (aka release matching specs) [23:26] (only the elg issue plus the LeaseSet modification is left) [23:26] I'd like to have the SDK 0.8 ready to go with the spec release, but I don't think we should commit to that. [23:27] or even whether we need to include SDK 0.1 with the spec release. [23:27] gah! annoying [23:28] miracl which nop pointed me too does the exact same thing we do [23:28] and they have no checks [23:28] unsigned though. [23:28] (since miracl is in c) [23:28] * jrand0m assumes [23:28] yes [23:29] but still, i make sure we never have a signed biginteger [23:30] biginteger.toByteArray() returns a signed byte array [23:30] sorry, continue [23:30] 'k [23:30] any movement on the python front jeremiah? [23:31] hey [23:31] sorry I was reading the backlog [23:31] heh hi [23:31] nope, I'm still getting used to classes [23:31] coo' [23:31] no prob [23:31] I think I'm gonna sleep for a bit actually [23:31] 'k [23:32] 0.4: release plan [23:32] we need the sdk issues resolved in the next day or so, one way or another. [23:32] we need to get working on wiki-fiying the security model [23:32] (wiki, where art thou) [23:33] we need to get the performance model up (not a prob, ill have it in a day or so) [23:33] we need to update the specs to include any elg mods, plus real URLs to other specs. [23:33] miracl [23:33] has a port [23:33] to java [23:33] perhaps we need to host the specs && / || sdk outside the US for export regulations [not that i care] [23:34] right, but miracl's java port doesnt have elg encryption last i checked. [23:34] i'll check again. [23:34] jrand0m, we don't care, but we'll worry about that later [23:34] jrand0m if it has bigdig() and modexp() [23:34] you're fine [23:34] *** yodel (~yodel@anon.iip) has joined channel #iip-dev [23:34] one second [23:34] i think i found our problem [23:35] word, whats up thecrypto? [23:35] can you check jrand0m [23:35] our k isn't being checked for relitive prime [23:36] will that cause the problems described thecrypto? i thought that would just render the encryption insecure (a problem, nonetheless) [23:36] but that would mean only some messages with the key would fail [23:36] it's something in keygen [23:36] nop> we'll find something to solve it. but i outlined some specific questions in my email that are implementation independent [23:36] ok thecrypto, we'll work through that after the meeting [23:37] the double ciphertext question? [23:37] okay [23:37] nop> thats one of the questions [23:37] * nop goes to read [23:39] nop> any ideas on when the wiki will be up? if its just dns, whats the IP so I can mod my hosts file so I can start editing? [23:40] quick q jrand0m: where does it fail, the benchmark runs perfectly and it makes a new keypair every time? [23:41] let me get it up, hold [23:41] wiki.invisiblenet.net == jasonclinton.com [64.91.236.103] [23:41] gracias mihi [23:42] thecrypto> it makes a new keypair each time. it fails on a two line test case that I built when debugging the ElGamalAESEngine [23:42] can i see this ElGamalAESEngine? [23:42] just commit it to CVS and i'll see what the problem is [23:43] ok wiki is cname'd [23:43] should propagate in a bit [23:43] * jrand0m doesnt commit things that don't work, but I'll email you [23:43] thanks nop [23:43] it's up [23:43] ;) [23:43] (Link: http://wiki.invisiblenet.net)http://wiki.invisiblenet.net [23:43] not on my box it aint [23:43] ;) [23:44] what are we wiki'ing [23:44] ? [23:44] the security doc, plus a place to distro the specs. [23:44] perhaps even the i2p website prior to 1.0 release, but at least the security doc. [23:45] *** Signoff: sirk ((null)) [23:45] *** Signoff: shardy_ (Ping timeout) [23:46] ok. given the above 5 points on the release plan, I'd like to have the specs out friday, saturday, or sunday, at the latest. [23:46] *** shardy_ (~shardy@anon.iip) has joined channel #iip-dev [23:46] I have a grphx guy working on the website [23:47] for i2p [23:47] any problems with that for a deadline? [friday deadline, fallback only if Bad Things Happen] [23:47] sure [23:47] jrand0m: sent? [23:47] 'k, so just the security docs and the i2p spec distro location [23:47] no thecrypto, there are half a dozen files. i'll send after the meeting. [23:47] okay [23:48] i'd like them sooner because we're moving tables around today so i need to move computers soon [23:48] jrand0m, I'll need to look at your email and I'll respond shortly [23:48] multi-tasking [23:49] 'k. [23:49] 0.5> apps [23:49] the name service is awol, as co aint around ;) [but i think he just went off to school too, so thats to be expected for the short term] [23:49] mihi has an awesome awesome i2ptunnel app [23:50] *** Signoff: WinBear_ (EOF From client) [23:50] strip one or two `awesome's ;) [23:50] heh [23:51] well, its very impressive. there's still stuff to add, but as is its a working port forwarder with reasonable performance. a really good proof of concept [23:51] it relies on too many things i cannot see from the spec (e.g. that GUARANTEED packets are delivered in order) [23:52] guaranteed packets are not delivered in order, but the java impl blocks on send of guaranteed, so if you use the java impl w/ guaranteed and don't have multiple sending threads, its guaranteed in order. [23:52] ideally, it'd be cool if it FEC'ed or had built in ordering & reconstruction or something [23:52] (so that it didn't block on send and didn't require GUARANTEED) [23:53] that's a bot too many ifs i think... [23:53] s/bot/bit/ [23:55] but perhaps i'll have some time to add reordering/resending to it... [23:55] well, thats how the java client impl is implemented ;) guaranteed is not recommended for low latency synchronous use, as it requires an ack (which in turn is a full message delivery, though without the client side end to end crypto, just i2np crypto) [23:55] word [23:56] any other apps on the horizon? should we have a page on the wiki w/ apps & app ideas for devs to get involved with? [23:57] * jrand0m thinks we probably aren't too far off until yodel's xml rpc can operate via the i2p sdk (either through mihis tunnel or natively) [23:57] hmm [23:57] test [23:57] tset [23:57] still connected? [23:57] si sr [23:58] we're unplugging phonelines right now [23:58] IIP, it defies phone lines [23:58] heh [23:58] :) [23:58] i can get back on the IM front and file transfer [23:58] wikked [00:00] ok. thats all i have for agenda items. [00:00] any comments/questions/concerns/frisbees? [00:00] * thecrypto throws a frisbee [00:00] * jrand0m gets a frisbee in the face [00:01] i just want to get this crypto stuff done so i can go back and optimize elg [00:01] and do the same for python hopefully [00:01] word. I'll get you the code in the next 5 [00:02] that would be good [00:03] * jrand0m readies the *baf*er [00:03] * jrand0m winds up [00:03] * jrand0m *baf*s the meeting to a close.