{% extends "_layout.html" %} {% block title %}I2P Development Meeting 51{% endblock %} {% block content %}

--- 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 & 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 & 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

{% endblock %}