--- Log opened Tue Jul 29 16:54:31 2003
17:11 <@hezekiah> Tue Jul 29 21:11:18 UTC 2003
17:11 <@hezekiah> The 51th (I think) iip-dev meeting.
17:11 <@hezekiah> Agenda:
17:11 <@hezekiah> 1.) Welcome
17:11 <@hezekiah> 2.) jrand0m's stuff
17:11 <@hezekiah> 3.) Any of the other developer's stuff
17:11 <@hezekiah> 4.) Anything nop adds when/if he gets here
17:12 <@hezekiah> 5.) Questions and Comments from the ever eager unwashed
	 masses. ;-)
17:12 <@hezekiah> OK!
17:12 <@hezekiah> Welcome everyone to the 51th (I think) iip-dev meeting
17:12 <@hezekiah> Item number 2!
17:12 <@hezekiah> jrand0m's stuff
17:12 -!- thetower [none@anon.iip] has joined #iip-dev
17:12  * hezekiah hands the mike to jrand0m
17:12 <@jrand0m> sub-agenda:
17:12 <@jrand0m> 2.1) I2CP spec &amp; dev status
17:12 < co> Where are the logs for meeting 50?
17:12 <@jrand0m> 2.2) SDK plans
17:12 <@jrand0m> 2.3) crypto
17:12 <@jrand0m> 2.4) roadmap / network proto status
17:13 <@hezekiah> co: cohesion is working on getting them up
17:13 <@jrand0m> (btw, its "mic", for microphone)
17:13 <@hezekiah> jrand0m: Sorry. :)
17:13 <@hezekiah> jrand0m: (And this mistake from a sound tech guy!)
17:13 -!- luckypunk [~yetalohe@anon.iip] has joined #iip-dev
17:13 -!- odargur [odargur@anon.iip] has joined #iip-dev
17:13 <@jrand0m> 2.1) I2CP: the spec is committed to CVS with a slight mod
	 to one of the messages (MessageStatusMessage)
17:14 <@jrand0m> Comments are always welcome on I2CP, but the sooner the
	 better.
17:14 <@hezekiah> jrand0m: Where's the spec in CVS? ... and is it on the SF
	 CVS too?
17:14 <@jrand0m> The reason for sooner the better is that we'll have a
	 working Java client implementation by friday.
17:14 -!- some_random_guy [~dan@anon.iip] has joined #iip-dev
17:14  * thecrypto crosses fingers on that one
17:14 <@jrand0m> Plus a local only router by the end of the weekend, I'm hoping
17:15 <@jrand0m> no hez, only on the cathedral
17:15 <@jrand0m> good point thecrypto.
17:15 <@jrand0m> Caveat:
17:15 <@hezekiah> Ugh. I still can't get CVS to work with cathedral.
17:15 <@jrand0m> some crypto isn't 100%, but its all stub'ed to let us plug
	 in more complete or other implementations later
17:15 <@jrand0m> hezekiah> we'll get you up after the meeting.
17:15 <@hezekiah> jrand0m: Thanks. :)
17:16 <@jrand0m> the spec is in the
	 i2p/doc/specs/data_structure_spec/datastructures.html
17:16 <@jrand0m> thecrypto> do you have anything to add re: java impl?
17:16 -!- ArdVark [simple1@anon.iip] has joined #iip-dev
17:16 <@jeremiah> the local-only router you mentioned was the python one,
	 right? or is there a java one too?
17:17 <@jrand0m> that all depends :)
17:17 <@jrand0m> jeremiah/hezekiah> how goes the python client and local-only
	 router?
17:17 <@thecrypto> not really, except for the crypto issue i think we'll
	 talk about in a bit
17:17 <@jrand0m> word thecrypto.
17:17 <@hezekiah> jrand0m: It's coming. I finally got the TCP transport
	 stuff working yesterday.
17:17 <@jeremiah> it seems ok, i think most of it will be dependent on
	 hezekiah's dev speed more than mine
17:17 <@hezekiah> jrand0m: Jeremiah has some nice stuff going with the
	 message strcutures.
17:18 <@hezekiah> hezekiah: I'm hoping that we can make the deadline.
17:18 <@jrand0m> cool.
17:18 <@jeremiah> also... friday is my birthday, so I plan on not being
	 around the computer then
17:18 <@hezekiah> jeremiah: Understandable. :)
17:18 <@hezekiah> jeremiah: And happy birthday in advance. :)
17:18 <@jeremiah> thanks
17:18 <@jrand0m> jumping slightly to agenda 2.4> when would we expect to be
	 able to have the python local only router?  realistically?
17:19 <@jrand0m> word, if you code on friday I'll kick your ass
17:19 <@jrand0m> virtually, at least
17:19 <@hezekiah> jrand0m: I thought that's what I'm coding. The Python
	 local only router.
17:19 <@jrand0m> si, that you are
17:19 <@hezekiah> Well the deadline is August 1st.
17:19 <@jeremiah> right now we're working on message to-from binary format
	 stuff
17:19 <@hezekiah> That's not that hard.
17:19 <@jeremiah> right
17:19 <@hezekiah> I'm hoping to have that done in a day or two.
17:20 <@jrand0m> thats friday :)
17:20 <@jrand0m> awesome
17:20 <@hezekiah> I hope it will be done by August 1st. Realistically it
	 might be a few days late, but I hope not.
17:20 <@jrand0m> 'k, I'll hold off on touching any java local only stuff
	 then and work on the network spec after the java client api is set.
17:20 <@hezekiah> Yes. Specs are good.
17:21 <@hezekiah> They make my job a LOT easier! :)
17:21 <@jrand0m> word.
17:21 <@jrand0m> I'll write up a quick 2 paragraph run through of the java
	 I2CP test harness too
17:21 <@jrand0m> I'll get that out tonight
17:22 <@hezekiah> jrand0m: I love how you get these specs written so fast.
17:22 <@hezekiah> This is fun. :)
17:22 <@jrand0m> Ok, hez/jeremiah/thecrypto> anything else on I2CP?
17:22 <@jrand0m> lol
17:22 -!- dm [~hifi@anon.iip] has joined #iip-dev
17:22 <@hezekiah> Um ...
17:22 <@hezekiah> I want the crypto spec!
17:22 < dm> welcome
17:22  * hezekiah pouts like a baby
17:22 <@hezekiah> ;-)
17:23 <@hezekiah> Seriously, ... I can't think of anything.
17:23 <@jrand0m> thats agenda item 2.3
17:23 <@thecrypto> still waiting for 2.3 to come up
17:23 <@hezekiah> If I do, I'll just come online and pester you with questions,
	 jrand0m. :)
17:23 <@jrand0m> word.
17:23 <@jrand0m> ok.  2.2) SDK plans
17:23 <@hezekiah> What agenda point did we just finish?
17:23 <@hezekiah> 2.4?
17:23 <@hezekiah> And have we finished 2.1 yet?
17:23 <@jrand0m> 2.1
17:24 <@jrand0m> now 2.2> the SDK
17:24 <@hezekiah> OK.
17:24 < dm> agenda has decimal point in it now? I see progress already.
17:24 <@hezekiah> I'm found now (as opposed to lost).
17:24 <@thecrypto> we might have 2 decimal points :)
17:25 <@jeremiah> what makes up the SDK apart from the various APIs?
17:25 <@jrand0m> the SDK is: the client API (as many as we have available), the
	 local only router, a trivial sample app, and some docs on how to use the APIs.
17:25 <@hezekiah> jrand0m: Would I be correct in assuming that you're writing
	 the docs? :)
17:26 <@jrand0m> I'd like to have the SDK released asap, so that 3rd (or
	 even 2nd or 1st) party developers can write and test applications that will
	 run over I2P, so once the network is operational, we'll hit the ground running.
17:26 <@jrand0m> hezekiah> I'd actually prefer not to.
17:26 <@jrand0m> hezekiah> and I say that not because I don't want to document,
	 but because I'm too close to it.
17:26 <@hezekiah> jrand0m: OK.
17:26 <@jrand0m> we should have somone who *doesn't* actually implement the
	 code write that doc, so it can be understandable to people who didn't write
	 the I2CP spec
17:26 <@hezekiah> jrand0m: We'll cross that bridge when we get there.
17:26 <@jrand0m> but if need be, I'll jump on it.
17:26 <@jrand0m> word.
17:27 < dm> what incentive do people have to write apps without an operational
	 network, and how would they even test their app.
17:27 <@hezekiah> jrand0m: Or why don't someone who designed the protocol
	 write it, and then have someone who never worked with it go over it until
	 it makes sense?
17:27 <@jrand0m> Ok, there has been some discussion of a simple 'talk'
	 style app.
17:27 <@jrand0m> dm> people will be able to test with the SDK.
17:27 <@thecrypto> actully, i was wondering what would be the use of that
	 if it's local only
17:28 <@jeremiah> dm: the idea is to implement a simple network that isn't
	 fully functional but can pass messages
17:28 <@thecrypto> you'd only be able to talk to yourself
17:28 <@jeremiah> it's not actually local-only, but it only includes
	 client-router, not router-router code
17:28 <@jrand0m> thecrypto> you can talk to other Destinations. I2P is
	 location independent - local is the same as remote.
17:29 <@thecrypto> okay
17:29 < dm> nice and all, I just don't see anyone (besides you 3-4) writing
	 anything if you can only test locally. But anyway, doesn't matter.
17:29 <@jrand0m> so a talk app can open up two instances of the application
	 and talk to oneself, etc
17:30 <@thecrypto> but when we add the remote stuff, the app should just work
17:30 <@jrand0m> dm> right, this is just a prereq for having other people
	 write apps.
17:30 <@jrand0m> exactly.
17:30 <@jrand0m> the app will work with absolutely NO changes
17:30 < co> dm: This is a test application. Once the router-router code is
	 written, you will be able to talk to others.
17:30 <@jeremiah> having local-only just lets us develop in parallel
17:30 < dm> yes, but if the app assumes 10 ms latency, and it ends being 12
	 seconds, it won't work too well :)
17:31 <@jrand0m> agreed dm
17:31 < dm> any estimates on latency btw? :)
17:31 <@jrand0m> if we have 12 second latency, we have work to do.
17:31 <@jrand0m> we won't have that though.
17:31 <@jrand0m> estimates are .6-2.7sec
17:31 <@jrand0m> for a 5,000,000 router network.
17:31 <@hezekiah> BTW, that reminds me. We need to talk about ElGamal.
17:31 <@thecrypto> the longest time is setup
17:31 <@jrand0m> (see iip-dev archives for the rudimentary models)
17:31 < dm> lower or higher for smaller networks?
17:32 <@jrand0m> hezekiah> 2.3: crypto.
17:32 <@thecrypto> after that the time the drops dramatically
17:32 <@jrand0m> dm> lower.
17:32 <@thecrypto> hezekiah: you prolly have the same question as i
17:32 <@jrand0m> thecrypto> exactly, setup time is offline for message
	 delivery though [aka set up tunnels prior to sending messages]
17:32 < dm> ok, just checking you ;)
17:32 <@jrand0m> heh
17:33 <@jrand0m> ok.  last part of the SDK - the app
17:33 <@jrand0m> co/thecrypto: thoughts on a java talk impl?  workable?
	 time?  plans?  interest?
17:34 <@thecrypto> once the API is up, we can prolly have a talk done in
	 about a week or so, 2 tops, co agrre?
17:34 <@jeremiah> chat could be built in as a jabber router, right?
17:34 < co> That should be fairly easy to do.
17:34 < co> thecrypto: I agree.
17:34 <@jrand0m> jeremiah> I don't know jabber, but if jabber can run over
	 the api, cool
17:35 <@jrand0m> word co &amp; thecrypto
17:35 <@jrand0m> jeremiah> note that this is just a trivial app to do proof
	 of concept with, not a Kickass Anonymous IM System :)
17:35 <@jeremiah> not yet ;)
17:35 <@thecrypto> we can add that functionallity later
17:35 <@jeremiah> k
17:36 <@jrand0m> heh
17:36 <@thecrypto> let's start small
17:36  * jrand0m puts in the schedule "add feature: be kickass"
17:36 < some_random_guy> heh
17:36 < some_random_guy> nice feature :)
17:36 -!- dm2 [~hifi@anon.iip] has joined #iip-dev
17:37 <@jeremiah> jrand0m: I think I missed this in 2.1, but any thoughts
	 on kademlia as a DHT? it requires less upkeep than Chord
17:37 -!- nop [nop@anon.iip] has joined #iip-dev
17:37 < nop> sorry
17:37 <@jrand0m> plus one of these days we need to get someone on the IIP
	 redesign to run over this.
17:37 -!- dm [~hifi@anon.iip] has quit [Ping timeout]
17:37 < nop> what?
17:37 < nop> who
17:37 < nop> where
17:37 < nop> when
17:37 < nop> ?
17:37 -!- dm2 is now known as dm
17:37 <@jrand0m> hey, speakin of the devil
17:37 < WinBear> why?
17:37 < WinBear> nm
17:37 < nop> I'm an angel actually
17:37 <@hezekiah> lol
17:38 <@thecrypto> someone hand nop a log
17:38 < WinBear> azrel
17:38 <@jrand0m> jeremiah> kademila is a good DHT, and we will definitely
	 review that plus the chord/tapestry crew, along with sloppy dhts in the
	 network spec.
17:38 <@jeremiah> jrand0m: cool
17:38 <@hezekiah> thecrypto: I'm working on it. :)
17:38 < nop> I was hearing of one that kicks but
17:38 < nop> called chord/middle
17:38 -!- hif [~hifi@anon.iip] has joined #iip-dev
17:39 < nop> but you know who is good to talk to his brandon wiley
17:39  * jrand0m !thwaps nop
17:39 < nop> I knew that would hurt
17:39 <@hezekiah> lol
17:39 <@hezekiah> Who's Brandon Wiley?
17:39 < nop> someone I'm sure jrand0m has been in numerous discussions with
17:39 < nop> :)
17:39 < nop> someone email me a log
17:39 < dm> Brandon is jrandom's real name, busted!
17:39 <@hezekiah> I'm working on it.
17:40 <@hezekiah> Hold you horses, nop. :)
17:40 < nop> haha
17:40 < dm> Brandon Wiley is the first Freenet programmer, having
17:40 < dm> co-founded the development effort with the system's inventor,
	 Ian Clarke
17:40 < nop> is userx here or there
17:40 < WinBear> you can talk to my brandon wiley
17:40 <@hezekiah> OK. It's on the way ... if my mail client will cooperate
	 and send a 15K attachement.
17:41 <@thecrypto> we've talked alot :)
17:41 <@hezekiah> nop: UserX is niether hither or thither.
17:41 <@hezekiah> OK!
17:41 <@hezekiah> The log is sent nop! Go read. :)
17:41 <@thecrypto> and now we wait
17:41 <@jrand0m> ok, anyone have any SDK thoughts while we give nop a min
	 to catch up? ;)
17:41 <@hezekiah> jrand0m: Now that I've gotten that log business done
	 ... what's kademlia?
17:42 <@jrand0m> Yet Another Academic DHT :)
17:42 <@hezekiah> And where I can get a link to kademlia's webpage?
17:42 -!- Erazerhead [JohnDoe@anon.iip] has joined #iip-dev
17:42 <@jeremiah> http://kademlia.scs.cs.nyu.edu/
17:42 <@hezekiah> Thanks. :)
17:42 <@thecrypto> YAADHT?
17:42 <@hezekiah> lol
17:42 <@hezekiah> Names these days ... I tell ya'!
17:43 <@jrand0m> and if there's ever any CS stuff mentioned that you don't
	 understand, go to citeseer.nj.nec.com/cs
17:43 < WinBear> klamidia?
17:43 <@hezekiah> OK.
17:43 < nop> jrand0m: I was just about to say citeseer
17:43 < dm> what's the ETA on the SDK?
17:44  * jrand0m avoids injecting the clap into I2P
17:44  * jrand0m hopes the SDK will be out next week.  perhaps next friday?
17:44  * thecrypto crosses another pair of fingers
17:45 <@jrand0m> ok.  moving on to 2.3) Crypto.
17:45  * hezekiah imagines thecrypto with about 13 sets of fingers crossed
	 ... and then realized that he must have run out by now.
17:45 <@hezekiah> Yay!
17:45  * jrand0m pokes nop to make sure he's here
17:45 <@hezekiah> Crypto!
17:45 <@hezekiah> I have something to start us off with. :)
17:46 <@thecrypto> i have something too
17:46 <@thecrypto> Dibs! :)
17:46  * jrand0m doesn.t so you two fight it out
17:46 <@hezekiah> thecrypto can go first. :)
17:46 <@jrand0m> thecrypto> speak
17:46 <@jrand0m> :)
17:46 <@thecrypto> Ok, on Elgamal
17:47 <@thecrypto> We have to figure out whether or not we have common p
	 and alpha
17:47 -!- some_random_guy [~dan@anon.iip] has quit [BitchX: the original
	 point-and-click interface.]
17:47 <@thecrypto> the problem with a common p and alpha is that we'd have
	 to find someway to change everyone's keys at the same time
17:48 <@jrand0m> aka: really bad.
17:48 < co> thecrypto: Sorry, what are p and alpha?
17:48 <@thecrypto> the advantage is that we can pick specially optimized
	 ones and the amount of data transmitted for a public key is very small
17:48  * jrand0m sees no good reason to use common p and alpha, beyond saving
	 a few bits
17:48 <@thecrypto> co: for all intensive purposes, special big numbers
17:49 <@jrand0m> thecrypto> we can still optimize for commonly encrypted to
	 destination's p and alpha
17:49 <@thecrypto> or should i go into an explaination of how elgamal workds
17:49 <@thecrypto> jrand0m: yes
17:49 < co> thecrypto: OK.
17:49 <@thecrypto> we can also have everyone have a different p and alpha
17:50 <@jeremiah> for those who are interested:
	 http://www.wikipedia.org/wiki/ElGamal_discrete_log_cryptosystem
17:50 <@thecrypto> this means that the amount of data transmitted is much
	 larger and we have to figure out how to pack it in
17:50 <@jrand0m> word, thanks jeremiah
17:50 <@jrand0m> much larger?
17:50 <@jrand0m> I thought with varying p and alpha we can use smaller p
	 and alpha?
17:51 <@thecrypto> instead of 160 bit numbers we are now talking 2 1024 bit
	 and 1 160
17:51 <@thecrypto> or overall 2308
17:51 <@hezekiah> 288 bytes
17:51 <@hezekiah> Big deal.
17:52 <@jrand0m> ok, thats not too bad.  we've planned on 256bytes
17:52 <@hezekiah> These keys aren't transfered all that often, are they?
17:52 <@jrand0m> another 32 doesn't hurt
17:52 <@jrand0m> hezekiah> they're inserted into the DHT
17:52 <@hezekiah> Ah!
17:52 <@hezekiah> That's why we wanted it small.
17:53 <@thecrypto> also, another problem about elgamal we might also have
	 to worry about
17:53 <@jrand0m> well, it doesn't really hurt if the RouterInfo structure
	 is about 10K or so
17:53 -!- mrflibble [mrflibble@anon.iip] has joined #iip-dev
17:53 <@jrand0m> 'k, s'up thecrypto?
17:53 <@thecrypto> message expansion is 2, the size of an encryption or a
	 signature is twice the size of the message
17:54 <@jrand0m> ElG encryption is only of the AES key
17:54 <@jrand0m> ElG signature is only of the SHA256 hashes
17:55 <@thecrypto> okay, it's just something to bring up as well
17:55 <@hezekiah> jrand0m: Which makes me _really_ puzzled.
17:55 <@thecrypto> now back to the original issue, do we want to have a
	 shared p and alpha or do we want everyone to have different p and alphas?
17:55 <@jrand0m> hezekiah> hmm?  you read the data structure spec for
	 #Payload ?
17:55 <@jrand0m> any thoughts/questions on that hezekiah?
17:55  * dm now understands how DHTs work.
17:55 <@jrand0m> nop> thoughts?
17:55 <@jrand0m> awesome dm
17:55 <@hezekiah> If a signature is twice the size of the data signed,
	 then why does the IC2P spec say a signature is 128 bytes?
17:56 < nop> no
17:56 < nop> shared p
17:56 <@hezekiah> Shouldn't it bee 512?
17:56 <@thecrypto> the hash of the bytes
17:56 < nop> and alphas
17:56 < dm> seems like a lot of work is required when joining a DHT, but I
	 guess it works.
17:56 < nop> shared base, shared p
17:56 <@jrand0m> hezekiah> bits / bytes.
17:56 < nop> this will eliminate a lot of risk
17:56 <@thecrypto> then how big do we want it?
17:56 <@hezekiah> Hmm
17:56 <@jrand0m> nop> in 3 years, will we want to have everyone change their
	 p and alpha at the same time?
17:56 < nop> and hold our protocol to standards
17:57 <@thecrypto> since it does open up that p and alpha huge attacks
17:57 < nop> jrand0m: there is such a thing called cooked primes, at this
	 time, and this is the time I'm looking at
17:57 <@thecrypto> which if completed bring the entire network down
17:57 < nop> I believe we can modify with the times
17:57 < nop> but a static oakley approved prime is advised
17:57 < nop> as they have been reviewed thoroughly as secure
17:58 < nop> and that is a better basis than any of our assumptions about
	 primes being generated (probable at that)
17:58 <@thecrypto> if it's not prime, encryption or signatures won't work
	 so we just throw it our
17:59 <@jrand0m> agreed, they have better primes.  so when one of those
	 primes are factored, everyone using them is exposed, correct?
17:59 < dm> hmmm, I gotta go. This is logged right?
17:59 < nop> jrand0m: yes
17:59 <@thecrypto> yup
17:59 < nop> jrand0m: when that happens we'll all know
17:59 < nop> I don't want to risk prime generation
17:59 -!- dm [~hifi@anon.iip] has quit [it better be]
17:59 <@thecrypto> how will we know?
17:59 < nop> plus it adds to our calculation time
17:59 -!- hif [~hifi@anon.iip] has quit []
17:59 < nop> thecrypto: if you use a standard defined Oakley prime set,
	 you will know when it's been cracked
18:00 <@thecrypto> how?
18:00 < nop> as it will be very public news
18:00 <@jrand0m> nop> we'll know unless the NSA cracks it.
18:00 < co> nop: How many of those primes are there? If not many, using them
	 is a risk.
18:00 <@thecrypto> yeah, passive evesdropping is still a threat
18:00 <@thecrypto> and i can make a program to generate ps and alphas and
	 test them in about an hour
18:00 <@jrand0m> nop> it would be very public news unless it was a threat
	 to national security.
18:00 < co> Wait... no, that's a stupid question. Never mind.
18:01 < nop> this is true, but I believe from numerous contacts in the
	 cryptography community that if it's solved it will be solved before the NSA
	 does it
18:01 < nop> our prime generation will not secure that either way
18:01 < nop> if they solve those primes
18:01 < nop> you may as well figure out a new algo to use
18:01 <@jrand0m> 'k.
18:02 < nop> please use static, it will relieve problems with cryptanalysis,
	 and reduce the risks of mistake in our crypto
18:02 <@jrand0m> I was on the fence, and I'm fine with going with shared
	 known good primes.
18:02 <@thecrypto> okay, then let's pick a prime then
18:02 <@jrand0m> nop> we've still got you penciled in the ganttchart for
	 crypto spec
18:02 <@thecrypto> and do they have generators for these primes?
18:02 < nop> yes
18:02 < nop> yes I do
18:03 < nop> 2
18:03 < nop> that is a primitive root of the primes I will have
18:03 < nop> what size primes do you guys want?
18:03 <@thecrypto> i'm thinking somewhere between 2048-4096
18:03 <@hezekiah> We're using a 2048 key, right?
18:03 < nop> yes, so use a 4096 or higher prime
18:04 <@thecrypto> because the sharedness means we're out in the open
18:04 <@thecrypto> and if this takes off, it would be a very valuble prime
	 to break
18:04  * cohesion missed the meeting
18:04 < co> You are using this prime within ElGamal, though, right?
18:04 <@hezekiah> So the keys will be 4096 bits?
18:04 <@cohesion> did someone log?
18:04 < nop> co yes
18:04 < nop> no hezekiah
18:04 < nop> the keys will be 2048
18:04 <@cohesion> ok
18:04 < nop> the prime will be higher than 4096
18:04  * cohesion goes back to his work
18:04 <@hezekiah> OK. Please forgive my horribe understanding here. :)
18:04 < nop> brb
18:05 <@thecrypto> p and alpha can be fixed, alpha will be 2 and p will be
	 the prime we pick
18:05 < nop> ok, let me email the prime candidates
18:05 < nop> give me a couple of hours I have some work to do
18:05  * jeremiah wanders to dinner, will read logs later
18:05 <@thecrypto> the serect key is a, a number between 0 and p - 2
18:05 <@thecrypto> the public key is 2^a mod p
18:06 < nop> can we move to next topic and come back so I can be here for
	 that, I'll be right back, at work and have to do a task real quick
18:06 <@hezekiah> OK, so you call my 'x' as 'a'
18:06 <@hezekiah> ... and my 'g' as 'alpha'.
18:06 < nop> please move the algo talk explanations to a private message
18:06 <@hezekiah> thecrypto: Right?
18:06 <@thecrypto> yes
18:06 <@jrand0m> ok.  so thecrypto, nop, and hezekiah will work out the
	 details of the algo later.
18:06 < nop> ok
18:06 < nop> for sure
18:06 <@hezekiah> OK ... so thecrypto, are you done with your question?
18:06 <@thecrypto> so let's move on
18:06 < nop> I'll email our primes
18:06 <@thecrypto> ye
18:06 <@thecrypto> s
18:06 <@hezekiah> OK. My turn! :)
18:07 <@hezekiah> Why on earth are we using ElGamal for signing?
18:07 <@jrand0m> ok.  2.4) roadmap / network proto status
18:07 <@jrand0m> not yet hez :)
18:07 <@jrand0m> oh hez
18:07 <@hezekiah> When do I get to ask it?
18:07 -!- dm [~hifi@anon.iip] has joined #iip-dev
18:07 <@jrand0m> what would you recommend, when we have ElG public keys?
18:07 <@thecrypto> when nop gets back
18:07 <@jrand0m> no, you're right, I'm wrong.  now is the right time.
18:07 < co> Next topic, please.
18:07 <@hezekiah> jrand0m: Well, the problem is this:
18:07 <@hezekiah> speed
18:08 <@hezekiah> I was playing around with the crypto stuff today, and got
	 a nasty shock.
18:08 <@hezekiah> ElGamal was _astronomically_ slower at verifying a signature
	 than DSA or RSA.
18:08 <@jrand0m> hezekiah> is that a library implementation problem or
	 the algorithm?
18:08 <@hezekiah> I don't know.
18:09 <@hezekiah> But I checked Applied Crypto and saw that at least _part_
	 of the problem is with ElGamal.
18:09 <@hezekiah> AC has tables of the amount of time it takes for signing
	 and verification for DSA, RSA, and ElGamal.
18:09 <@jrand0m> so are you suggesting we go to RSA for encryption, decryption,
	 and signing?
18:09 <@hezekiah> I
18:09 <@hezekiah> I'm not really suggesting much that's definate.
18:09 <@jrand0m> ...though we *could* add a second signing public key to
	 the RouterInfo structure
18:10 <@hezekiah> I'm just saying, that AC lists ElGamal verification at
9.30 seconds.
18:10 <@hezekiah> RSA is 0.08 seconds
18:10 <@thecrypto> for 1024 bits
18:10 <@jrand0m> damn.
18:10 <@hezekiah> DSA is 1.27 seconds
18:10 <@hezekiah> Now you see my problem.
18:10 <@hezekiah> ElGamal is dirt slow ...
18:10 <@jrand0m> we need sub <100ms verification.
18:10 <@jrand0m> if not sub <10ms
18:10 <@hezekiah> ... and my CPU is 333MHz.
18:11 <@hezekiah> BTW, these calculations were done on a SPARC II
18:11 <@hezekiah> I've got an AMD K6-2 333MHz.
18:11 <@jrand0m> a sparc 2 is a 40Mhz machine.
18:11 <@hezekiah> Verifying an ElGamal sig with my Python module (which uses
	 a C backend but smells a little fishy).
18:11 < luckypunk> god
18:11 < luckypunk> well
18:11 <@hezekiah> jrand0m: OK. I have no clue about SPARC's.
18:11 <@hezekiah> Anyway, it took about 20 seconds.
18:12 <@hezekiah> If not a little more.
18:12 < luckypunk> anyone with a 1 ghz -2 ghz proc doesn't need to worry.
18:12 < co> hezekiah: On modern computers, then, the verification should be
	 acceptably fast.
18:12 <@hezekiah> DSA and RSA were nearly instantainious.
18:12 <@jrand0m> hezekiah> I do.  sparc 2 was fast in '92
18:12 <@hezekiah> Anyway, that's why I bring all this up.
18:12 <@hezekiah> We could add a DSA key, but that would meen 2 keys
18:12 <@thecrypto> we should still wonder about people who don't have the
	 uber fast machines
18:12 <@hezekiah> Or we could go with RSA.
18:12 <@jrand0m> my memory of our rationale for ElG as opposed to RSA was
	 the preference was not very strong.
18:13 <@hezekiah> Or we can live with the long verification time and use ElG.
18:13 <@jrand0m> thecrypto> absolutely.
18:13 <@thecrypto> nop was the one to say, let's use elgamal
18:13 <@hezekiah> thecrypto: Precisely. Mom and Pop will eventually be
	 transparently using I2P.
18:13 <@jrand0m> we're going to want bootable distros for 386s, as well as
	 in-applet implementations.
18:13 <@hezekiah> Mom and Pop won't have state of the art hardware.
18:13 < luckypunk> oh god
18:14 < luckypunk> everyone who would want this has at least a p100 or so.
18:14 < co> Let's not compromise security by choosing a weaker algorithm
	 that is faster.
18:14 <@hezekiah> co: I'm not suggesting we do.
18:14 <@thecrypto> elgamal and DSA are equivilent
18:14 <@jrand0m> ok.  so we're going to revisit the RSA/ElG choice.  the code
	 changes shouldn't be a problem.
18:14 < luckypunk> they can suffer.
18:14 <@hezekiah> co: RSA and DSA are just as reputable as ElGamal.
18:14 < luckypunk> lol
18:14 < luckypunk> if you're concerned about anonyminity
18:14 <@hezekiah> thecrypto: And nothing could be farther from the truth.
18:14 < luckypunk> you won't care about speed too much.
18:14 <@thecrypto> hezekiah: they are both implementations of the same
	 general algorithim
18:14 < dm> the obvious step here is for someone to figure out for certain
	 what the CPU usages for the two are :)
18:14 <@jrand0m> luckypunk> you listen to the complaints wrt freenet much?
18:15 <@hezekiah> thecrypto: DSA can't encrypt. It's only a sig algo, and
	 it's a lot faster than ElG.
18:15 <@thecrypto> hezekiah: it just happens that the signing and verification
	 equations for DSA are faster
18:15 <@jrand0m> dm> if Applied Crypto benchmarked RSA verification at
1/100th ElG, thats enough for me.
18:15 <@thecrypto> we can use ElG for encryption/decryption and DSA for
	 signing/verification
18:15 <@jrand0m> the options are go to RSA or add a DSA key (~256bytes more)
	 to the RouterInfo structure
18:15 <@hezekiah> Right. But now the DHT has 2 public keys in it.
18:16 <@jrand0m> so?
18:16 < co> Let's have one public key. That will be less confusing.
18:16 <@hezekiah> co: It would only be 'confusing' for developers ... and
	 we need to know what we're doing. :)
18:16 <@thecrypto> i think it's time to wait for nop on this one too
18:16 <@hezekiah> Right.
18:16 <@jrand0m> but if its 100times a slow...
18:16 <@jrand0m> anyway, we'll continue the crypto design discussion offline.
18:17 <@hezekiah> jrand0m: Email the mailing list, will ya'?
18:17 < luckypunk> jrand0m: god, i don't mind, if you cant wait 40 sseconds
	 for your page to load, fuck off.
18:17 <@thecrypto> or after the main part of the meeting
18:17 <@jrand0m> shit, I email the list daily :)
18:17 <@jrand0m> heh lucky
18:17 -!- hif [~hifi@anon.iip] has joined #iip-dev
18:17 <@jrand0m> right.
18:17 <@jrand0m> ok> 2.4) roadmap / network proto status
18:17 -!- hif is now known as dm2
18:18 <@jrand0m> I have done very little wrt the network proto beyond
	 responding to co's messages, as I've been working on the java and I2CP.
18:18 <@jrand0m> roadmap still seems on target.
18:18 <@jrand0m> any changes to the roadmap?
18:19 <@jrand0m> ok.  if there are, whenever there are, just mail the list.
18:19 <@hezekiah> Right.
18:19 -!- dm [~hifi@anon.iip] has quit [Ping timeout]
18:19 <@jrand0m> the roadmap.xml is now in the i2p cvs module
	 i2p/doc/projectPlan
18:19 -!- dm2 is now known as dm
18:20 <@hezekiah> jrand0m: Let me guess ... that's on cathedral too?
18:20 < nop> back
18:20 < nop> sorry bout that
18:20 <@jrand0m> ok, thats it for that (though we can come back to network
	 protocol questions in the questions section).
18:20 <@jrand0m> I have no more subitems
18:20 <@jrand0m> hezekiah> I don't use sf
18:20 <@thecrypto> well, now that nop is back we can go back to the speed
	 issue quickly
18:20 <@hezekiah> Right.
18:21 < nop> which speed issue
18:21 <@thecrypto> Elgamal is slow to verify
18:21 < nop> that's true
18:21 < nop> but so is rsa
18:21 <@jrand0m> nop> Applied Crypto benchmarked RSA verification at 1/100th
	 ElG for signing.
18:21 < nop> hmm
18:22 <@hezekiah> RSA and DSA are instantanious for me.
18:22 <@hezekiah> ElG takes 20 seconds.
18:22 < nop> DSA is el gamal
18:22 <@jrand0m> So we can either jump to RSA or add a DSA key to the
	 RouterInfo structure
18:22 < nop> DSA
18:22 < nop> I have anything with R's in it
18:22 < nop> ;)
18:22  * jrand0m doesn't remember a really strong reason for ElG as opposed
	 to RSA
18:22  * jrand0m resents that
18:22 <@hezekiah> nop: Will you enlighten us? Why don't we use RSA?
18:23 <@hezekiah> In all the gory detials. :)
18:23 < nop> for the reasons of this, and it's debatable, but
18:23 < dm> someone msg me the URL to the iip-dev again when you get a chance.
18:23 < nop> factoring primes is how to solve RSA
18:23 < dm> iip-dev list that is.
18:23 < luckypunk> RSA has been cracked.
18:23 < luckypunk> practically.
18:23 < nop> yes, 512 bit RSA has been cracked
18:23 < luckypunk> or was it DES?
18:23 < luckypunk> bah.
18:23 <@hezekiah> DES has been cracked.
18:23 < nop> it was DES I think you're talking about
18:23 < co> luckypunk: Keys of certain size have been cracked.
18:23 <@hezekiah> RSA is not quite there yet.
18:24 < nop> anyway
18:24 < luckypunk> but it might.
18:24 < nop> back to my point
18:24 <@hezekiah> But the question is: is a 2048 or 4096 RSA key secure today?
18:24 <@thecrypto> hold one second
18:24 < nop> 512 bit RSA keys have been cracked with office computers
18:24 <@jrand0m> we're looking at 2048bit RSA or ElG
18:24 < nop> hezekiah: it would be, but here's the fun part
18:24 < nop> if you can factor primes
18:24 < nop> you can crack RSA
18:24 < nop> if you can compute discrete logarithms you can solve RSA and
	 EL gamal
18:24 < nop> we're closer to factoring
18:24 < nop> than we are with computing discrete logs
18:24 < nop> at this time
18:24 < luckypunk> isn't discrete logs a bit harder?
18:25 <@hezekiah> If you can factor primes _quickly_ you can crack RSA.
18:25 <@hezekiah> luckypunk: That's what nop's saying.
18:25 < luckypunk> quantum computers.
18:25 < luckypunk> are damned near to functional.
18:25 <@hezekiah> lol
18:25 < nop> and the ratio of bit sizes for pub keys for discrete logs is
	 stronger than RSA's keys
18:25 < nop> for instance 768 bit key is not advised by diffie-hellman
	 variants, but it has not been provably cracked
18:25 <@hezekiah> So, the end of it is that we add a DSA key.
18:25 <@thecrypto> nop, don't do a bill gates, it's factor large n where n = pq
18:25 < nop> as 512 bit RSA keys have
18:25 <@thecrypto> since factoring prime numbers is easy
18:25 < nop> thnx
18:25 < nop> sorry
18:25 <@jrand0m> hezekiah> thats what its looking like.
18:26 < nop> I was trying to let everyone understand
18:26 < nop> sorry
18:26 <@thecrypto> just a bit of a clarification
18:26 <@jrand0m> word nop, thats cool, gracias
18:26 <@hezekiah> OK.
18:26 < nop> so DSA
18:26 < nop> then
18:26 <@hezekiah> So we're adding a DSA key?
18:26 < nop> which is a diffie-hellman variant as well
18:26 <@jrand0m> ok, given that, we'll continue crypto details offline.
18:26 < nop> I'm in favor of logs over factors
18:27 < nop> ;)
18:27 <@hezekiah> BTW, what do we still need to continue?
18:27 < co> dm: That URL is
	 http://news.gmane.org/thread.php?group=gmane.comp.security.invisiblenet.iip.devel
18:27 <@thecrypto> hezekiah: picking the magic prime
18:27 <@hezekiah> Oh, right!
18:27 < dm> thanks co, I found jrand0m's specs. Now all I need is a printer
	 with lots of toner.
18:27 < nop> I'll send that out
18:27 <@jrand0m> hezekiah> update the data structure spec, add info wrt the
	 DSA, specify key size for dsa, etc.
18:27 < nop> let's do that offline
18:27 <@jrand0m> lol dm.
18:28 <@hezekiah> OK, so do you have anything left, jrand0m?
18:28 <@jrand0m> ok, I'm done with my stuff.  hezekiah> you had # 3?
18:28 <@hezekiah> Yeah.
18:28 < dm> hmmm. pictures are not showing up.
18:28 <@hezekiah> 3.) Whatever nop wants to add to the agenda.

18:28 < dm> jrand0m: is there a place to get the 'I2P Network Spec Draft
2003.07.23' with pictures included?
18:29 < co> dm: Yes, I have had that problem, too.
18:29 <@jrand0m> dm/co> get the first rev of the network spec (two weeks
	 prior in the zip), which includes the png.
18:30 <@jrand0m> (its in cvs too, but thats not anon/public yet)
18:30 < arj> when will it be? :)
18:30 <@hezekiah> Wow!
18:30 <@hezekiah> CVS is fast now!
18:31 <@jrand0m> arj> we're doing our best to avoid hype, so once its ready
	 we're going to put things public, but keep it largely quiet until.
18:31 < nop> hezekiah: what the cathedral one?
18:31 <@jrand0m> arj> however, everything we're doing is GPL, at least so far.
18:31 <@hezekiah> nop: Yeah
18:31 <@hezekiah> !
18:31 < dm> two weeks prior in which zip?
18:31 <@jrand0m> oh word, you got it working hezekiah?
18:31 < arj> jrand0m: just wanted to read the latest specs
18:31 <@jrand0m> dm> network_spec_*.zip iirc
18:31 <@hezekiah> jrand0m: Yup! :)
18:31 < dm> same here, with pictures!
18:31 <@thecrypto> iip-dev has most of it
18:32 <@jrand0m> arj>
	 http://article.gmane.org/gmane.comp.security.invisiblenet.iip.devel/292 has
	 all but one tiny change.
18:32 <@jrand0m> (well, except for the Client Access Layer, which is in a
	 different spec now)
18:33 < arj> ok thanx
18:33 <@jrand0m> the client access layer spec is
	 http://article.gmane.org/gmane.comp.security.invisiblenet.iip.devel/298
18:33 < dm> ok, and the link to the zip with the pictures?
18:33 <@jrand0m> ok.  nop you have anything, or we "5) opening up to
	 questions/thoughts from the masses"?
18:34 -!- mihi [none@anon.iip] has quit [Ping timeout]
18:34  * jeremiah is back and has read the backlog
18:34 <@jrand0m> dm> h/o, pulling it up
18:34 <@jrand0m>
	 http://article.gmane.org/gmane.comp.security.invisiblenet.iip.devel/269
18:35 < dm> ty
18:35 <@jrand0m> ok, any questions / thoughts?
18:35 -!- arj [anders@anon.iip] has quit [EOF From client]
18:35 < co> yes.
18:35 <@jrand0m> np
18:35 < co> Are we on item 5 now?
18:35  * jrand0m knew you'd have some co :)
18:35 < co> Currently, communication between client and router (outgoing)
	 is not encrypted.
18:35 <@jrand0m> yes, since nop is slow :)
18:35 <@jrand0m> (damn people with jobs and stuff)
18:36 <@hezekiah> lol
18:36 < co> Suppose I have a trusted friend and want to use his router for
	 outgoing messages.
18:36 <@hezekiah> jrand0m: Well, you know. Not everyone can aford not having
	 a life.
18:36 <@jrand0m> co> largely correct.  message payloads are encrypted,
	 but the rest of I2CP isn't
18:36 < co> Wouldn't that put me at risk of having my messages captured.
18:37 <@hezekiah> Yeah. They would be transfered in the clear over the wire.
18:37 <@hezekiah> Unless you ssh tunnel to his router or something.
18:37 <@jrand0m> if you have a trusted friend and connect to their router,
	 they can know that you sent or recieved a message, but they can't know what
	 you sent.
18:37 <@jeremiah> wouldn't the messages still go under public key encryption?
18:37 <@hezekiah> Oops.
18:37 <@hezekiah> My bad.
18:37 < dm> I'm gonna use I2P as a way to learn new stuff to prevent 9to5
	 (windows admin, VB tools) job from turning me into a zombie.
18:37 <@jrand0m> I'm fine with adding SSL listener support, as opposed to
	 just TCP listener.
18:37 <@hezekiah> I forgot that clients to end to end encryption.
18:37 < co> Your assumption is that I run a local trusted router, but as
	 stated above, I might not want to do that so that messages would not be
	 connected to me.
18:37 <@jrand0m> yes jeremiah, but thats only for the payload
18:37 <@jrand0m> heh word dm
18:37 -!- mihi [none@anon.iip] has joined #iip-dev
18:38 <@jrand0m> hmm.
18:38 <@hezekiah> jrand0m: Why not add support later on for client-to-router
	 comm to be encrypted?
18:38 <@jrand0m> you really always should have a local trusted router.
	 you can have it connect to another known non-local trusted router too.
18:39 < co> True, but I would like to second hezekiah's suggestion.
18:39 <@jrand0m> hezekiah> I'm fine with adding it later (where later:
	 t=0...releaseDate ;)
18:40 <@jrand0m> I have absolutely no qualms with even adding support for
	 DH+AES for I2CP
18:40 < nop> good
18:40 <@jrand0m> actually, those features can be added on per-router basis
	 as well
18:41 < nop> jrand0m: also I believe the polymorphic key rotation will be
	 needed as well as chaffe traffic
18:41 < nop> I'm sure we're looking at that at a later meeting
18:41 < nop> just my side comment
18:41 < nop> using key sets
18:41 <@jrand0m> yes, when we touch the router-router comm.
18:41 <@jrand0m> (1-2 weeks off)
18:41 < co> nop: Currently, I don't see chaffe traffic in the spec, but it
	 would be good to add.
18:42 <@jrand0m> there is chaffe, in the sense that routers and tunnel
	 participants test themselves and their peers.
18:42 -!- arj [~anders@anon.iip] has joined #iip-dev
18:42 <@jrand0m> plus DHT requests are chaffe wrt payload messages
18:42 < nop> jrand0m: well I'll dive into some research on evading some
	 traffic analysis and giving away any known plaintext
18:42 <@jrand0m> *and* individual transports will have hteir own chaffe styles
	 (e.g. http transport will query google for "cute puppy dogs" periodically,
	 or whatever)
18:43 < nop> well, that chaffe is nice, but I also mean encrypted chaffe
18:43 < nop> this helps rotate the session keys
18:43 < nop> and keep your node busy even when inactive
18:43 < dm> maybe change that to hard child porn for more realistic chaffe
18:43 <@jrand0m> word.
18:43 < dm> just kidding!
18:43 <@hezekiah> dm: Good. Otherwise I'd have to !thwack you.
18:43 <@hezekiah> :)
18:44 <@jrand0m> DHT (link encrypted) and test messages (free route mix,
	 ala onion/garlic) won't have known plaintext problems
18:44 < nop> since newer nodes will have less traffic when starting out
18:44 <@jrand0m> plus we'll have support for constant bitrate transports
18:44 < nop> garlic rocks
18:44 < nop> :)
18:44 < nop> jrand0m: DC net style :)
18:44  * jrand0m is making some pasta w/ lots of garlic after this meeting
	 is over
18:45 < nop> jrand0m: I meant garlic routing
18:45 <@hezekiah> lol!
18:45 <@jrand0m> i know ;)
18:45 < nop> jrand0m: anyway, constant bitrate could be forced with the
	 block encryption since AES generates 128 bit blocks
18:45 < nop> ;)
18:45 < nop> so we could just pad all data to be 16 bytes per message
18:45 <@jrand0m> co> did my answers to your email make sense?
18:47 <@jrand0m> *ping*
18:47 <@hezekiah> *pong*
18:47 <@thecrypto> *pong
18:47 <@thecrypto> *
18:47 <@jrand0m> any other questions from anyone, or has my iproxy
	 disconnected?
18:47 <@jrand0m> heh word
18:47 <@hezekiah> thecrypto: Fragmented packet!
18:47 <@hezekiah> lol
18:48 <@thecrypto> lost that tail end there
18:48 <@thecrypto> smaller MTU here :)
18:48 <@hezekiah> jrand0m: Well, I have no questions.
18:48 < co> jrand0m: Yes, the answers made sense.
18:48 < co> I have no more questions.
18:48 < dm> I shall create questions when I read the specs tomorrow.
18:49 <@jrand0m> well, I hope you have more later :)
18:49 <@jrand0m> awesome dm
18:49 < dm> awesome initially maybe.
18:49 < dm> well, i'm off. good luck people!
18:49 -!- dm [~hifi@anon.iip] has quit []
18:50 <@jrand0m> we *do* still have the big 2 week peer review period in
	 the schedule, but review before then is appreciated (even though all the
	 details haven't yet been put in)
18:51 <@jrand0m> ok.  any other questions, or are we going to wrap up #52
	 as a 102 minute meeting?
18:52 <@thecrypto> #51
18:52 <@hezekiah> Uh, I read 1:57 minutes.
18:52 <@hezekiah> Duh.
18:52 <@hezekiah> I'm stupid
18:52 <@hezekiah> Never mind me.
18:52 <@hezekiah> I have no questions ...
18:52 <@hezekiah> Questions!
18:52  * jrand0m could never add...
18:52 <@hezekiah> Speak now or hold you peace until next Tuesday!
18:52 <@hezekiah> Going once!
18:53 <@hezekiah> ... Going twice!
18:53 <@thecrypto> Sold to the guy in a button down shirt
18:53 <@hezekiah> Gone!
18:53  * jrand0m goes to the kitchen to make some long overdue dinner
18:53 <@jrand0m> gracias srs y srtas
18:53 <@hezekiah> Goodbye everyone!
18:53 <@jeremiah> I should checkout the source before I wander off
18:53 <@hezekiah> See you next Tuesday!
--- Log closed Tue Jul 29 18:53:55 2003