162 lines
6.6 KiB
HTML
162 lines
6.6 KiB
HTML
<pre>-----BEGIN PGP SIGNED MESSAGE-----
|
|
Hash: SHA1
|
|
|
|
Well boys 'n girls, its Tuesday again!
|
|
|
|
* Index:
|
|
1) 0.3.4.3
|
|
2) 0.3.5 and 0.4
|
|
3) docs
|
|
4) stasher update
|
|
5) ???
|
|
|
|
* 1) 0.3.4.3
|
|
|
|
Well, as I'm you've all noticed, while the number of users on the
|
|
network has stayed pretty steady, the performance has significantly
|
|
degrated over the last few days. The source of this has been a
|
|
series of bugs in the peer selection and message delivery code,
|
|
exposed when there was a minor DoS last week. The result has been
|
|
essentially everyone's tunnels have been consistently failing, which
|
|
has a bit of a snowball effect. So no, its not just you - the net
|
|
has been horrid for the rest of us as well ;)
|
|
|
|
But the good news is we fixed the issues pretty quickly, and they've
|
|
been in CVS since last week, but the network will still suck for
|
|
people until the next release is out. On that note...
|
|
|
|
* 2) 0.3.5 and 0.4
|
|
|
|
While the next release will have all the goodies we've got planned
|
|
for the 0.4 release (new installer, new web interface standard,
|
|
new i2ptunnel interface, systray & windows service, threading
|
|
improvements, bugfixes, etc), the way the last release degraded over
|
|
time was telling. I want us to move more slowly on these releases,
|
|
giving them time to deploy more fully and for kinks to show
|
|
themselves. While the simulator can explore the basics, it doesn't
|
|
have any way of simulating the natural network issues we see on the
|
|
live net (at least, not yet).
|
|
|
|
As such, the next release will be 0.3.5 - hopefully the last 0.3.*
|
|
release, but perhaps not, if other issues arise. Looking back at
|
|
how the network operated when I was offline in June, things started
|
|
to degrade after about two weeks. As such, my thoughts are to hold
|
|
off marking us up to the next 0.4 release level until we can sustain
|
|
a high degree of reliability for at least two weeks. That doesn't
|
|
mean we won't be doing work in the meantime, of course.
|
|
|
|
Anyway, as mentioned last week, hypercubus is chugging away at the
|
|
new install system, dealing with me changing things around and
|
|
requiring support for goofball systems. We should have things
|
|
hammered out in the next few days to push out a 0.3.5 release in
|
|
the next few days.
|
|
|
|
* 3) docs
|
|
|
|
One of the important thing we need to do during that two week
|
|
"testing window" before 0.4 is to document like crazy. What I'm
|
|
wondering is what things you feel our documentation is missing -
|
|
what questions do you have that we need to answer? While I'd like
|
|
to say "ok, now, go write those documents", I'm realistic, so all
|
|
I'm asking is if you can identify what those documents would
|
|
discuss.
|
|
|
|
For instance, one of the docs I'm working on now is a revision of
|
|
the threat model, which I'd now describe as a series of use cases
|
|
explaining how I2P can serve different individual's needs,
|
|
including the functionality, the attackers that person is worried
|
|
about, and how they defend themselves.
|
|
|
|
If you don't think your question requires a full blown document to
|
|
address, simply phrase it as a question and we can add it to the
|
|
FAQ.
|
|
|
|
* 4) stasher update
|
|
|
|
Aum was by the channel earlier today with an update (while I
|
|
peppered him with questions):
|
|
|
|
< aum> quick stasher update, with apologies for tomorrow's meeting:
|
|
< aum> infinite-level splitfiles working, have successfully
|
|
inserted and retrieved large files
|
|
< jrandom> w00t
|
|
< aum> splitfile fragmentation/reassembly transparently occuring
|
|
within stasher
|
|
< aum> freenet interface working
|
|
< jrandom> wow
|
|
< jrandom> so FUQID/FIW works?
|
|
< aum> use of fcp splitfile commands in freenet clients strictly
|
|
forbidden (at this stage)
|
|
< aum> most clients such as fuqid/fiw should allow setting
|
|
extremely large splitfile sizes, which should prevent them
|
|
trying to talk splitfiles
|
|
< aum> if not, then i can dummy up something
|
|
< jrandom> r0x0r aum, that kicks ass!
|
|
< aum> hooks are in for detailed freenet key support
|
|
< jrandom> detailed freenet key support?
|
|
< aum> yes, specific chk@, ssk@, ksk@
|
|
< aum> seriously considering datastore encryption:
|
|
< jrandom> ok great, so they're all verified @ each node, etc?
|
|
< aum> no - only verifiable by the requestor
|
|
< aum> my thinking is, given KSK@fred = 'mary',
|
|
< aum> to store as SHA1(SHA1("KSK@fred")) = E(mary), where key
|
|
for E is SHA1("KSK@fred")
|
|
< aum> ie, crypto key is SHA1(uri), and kademlia key is
|
|
SHA1(SHA1(uri))
|
|
< jrandom> hm
|
|
< aum> so a possessor of the URI can decyrpt, but owner of a
|
|
datastore cannot decrypt (and therefore has plausible
|
|
deniability)
|
|
< jrandom> well, ksks are inherently insecure, so thats no big
|
|
loss, but what about ssk?
|
|
< deer> <detonate> those keys aren't very large
|
|
< aum> SSK as for freenet
|
|
< jrandom> so the SSKs are verified at each node?
|
|
< aum> except i'm looking to use same encryption over the top
|
|
< aum> not feasible to verify SSK at the target node
|
|
< jrandom> why not? freenet does
|
|
< aum> well maybe it is feasible,
|
|
< aum> i guess i shouldn't be so lazy
|
|
< aum> i was trying to keep the kademlia and freenet layers
|
|
separate
|
|
< jrandom> heh, you're not being lazy, there's a truckload of
|
|
work here, and you're doing a great job
|
|
< aum> verifying on target node will cause some pathological
|
|
couplings between the two layers, and force deviation
|
|
from pure kademlia
|
|
< jrandom> i dont think its possible to do SSKs or CHKs
|
|
securely without having the node validate the key
|
|
properties
|
|
< aum> not correct
|
|
< aum> fred asks mary, 'gimme SSK@madonna'
|
|
< aum> mary sends back what she thinks is 'SSK@madonna'
|
|
< aum> fred tests it, barfs, then goes on to ask the next node
|
|
< aum> anyway, i MUST go - but am open to continuing discussion
|
|
over email, or tomorrow
|
|
< aum> bbl guys
|
|
< jrandom> mallory floods the net with 'SSK@madonna' ==
|
|
'sexDrugsRockNRoll'
|
|
< jrandom> l8r aum
|
|
|
|
So, as you can see, lots and lots of progress. Even if the
|
|
keys are validated above the DHT layer, that's wikked cool (imho).
|
|
Go aum!
|
|
|
|
* 5) ???
|
|
|
|
Ok, thats all I've got to say (which is good, since the meeting
|
|
starts in a few moments)... swing on by and say whatcha want!
|
|
|
|
=jr
|
|
|
|
-----BEGIN PGP SIGNATURE-----
|
|
Version: PGP 8.1
|
|
|
|
iQA/AwUBQTTlqRpxS9rYd+OGEQJd3ACfYXJRO6EFjOVgO7KNbQcdr1YevJYAnj0Q
|
|
gEg6cYDHMxLuGop/ALQwU+bg
|
|
=A3Um
|
|
-----END PGP SIGNATURE-----
|
|
|
|
|
|
</pre>
|