i2p.www/i2p2www/blog/2006/09/12/status.html

<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi y'all, here's our *cough* weekly status notes

* Index:
1) 0.6.1.25 and net status
2) I2PSnark
3) Syndie (what/why/when)
4) Syndie crypto questions
5) ???

* 1) 0.6.1.25 and net status

The other day we pushed out the 0.6.1.25 release, including the swarm of
bugfixes accumulated over the past month, as well as zzz's work on
I2PSnark and Complication's work trying to make our time synchronization
code a bit more robust.  Right now the network seems to be fairly stable,
though IRC has been a bit rough in the last few days (due to reasons
unrelated to I2P).  With perhaps half of the network upgraded to the
latest release, tunnel build success rates have not changed much, though
overall throughput seems to have increased (likely due to an increase in
the number of people using I2PSnark).

* 2) I2PSnark

zzz's updates to I2PSnark included protocol optimizations as well as web
interfaces changes, as described in the history log [1].  There have been
a few small updates for I2PSnark since the 0.6.1.25 release as well, and
perhaps zzz can give us an overview of whats up on during the meeting
tonight.

[1] <a  rel="nofollow" href="http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD">http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD</a>

* 3) Syndie

As y'all know, my time has been focused on revamping Syndie, though
&quot;revamp&quot; may not be the right word.  Perhaps you can consider what is
currently deployed as a &quot;proof of concept&quot;, since the new Syndie has
been redesigned and reimplemented from the ground up, though many
concepts remain.  When I refer to Syndie below, I'm talking about the
new Syndie.

* 3.1) What is Syndie

Syndie is, at its most basic level, a system for operating offline
distributed forums.  While its structure leads to a large number of
different configurations, most needs will be met by selecting one of
the options from each of the following three criteria:
 - Forum types:
   - Single author (typical blog)
   - Multiple authors (multiauthor blog)**
   - Open (newsgroups, though restrictions may be included so that only
     authorized** users can post new threads, while anyone can comment on
     those new threads)
 - Visibility:
   - Anyone can read anything
   - Only authorized* people can read posts, but some metadata is exposed
   - Only authorized* people can read posts, or even know who is posting
   - Only authorized* people can read posts, and no one knows who is
     posting
 - Comments/replies:
   - Anyone can comment or send private replies to the author/forum
     owner
   - Only authorized** people can comment, and anyone can send private
     replies
   - No one can comment, but anyone can send private replies
   - No one can comment, and no one can send private replies

 * reading is authorized by giving people the symmetric key or passphrase
   to decrypt the post.  Alternately, the post may include a publicly
   visible prompt, where the correct answer serves to generate the
   correct decryption key.
** posting, updating, and/or commenting is authorized by providing those 
   users with asymmetric private keys to sign the posts with, where the
   corresponding public key is included in the forum's metadata as
   authorized to post, manage, or comment on the forum.  Alternately, the
   signing public keys of individual authorized users may be listed in
   the medtata.

Individual posts may contain many different elements:
 - Any number of pages, with out of band data for each page specifying
   the content type, language, etc.  Any formatting may be used, as its
   up to the client application to render the content safely - plain text
   must be supported, and clients that can should support HTML.
 - Any number of attachments (again, with out of band data describing the
   attachment)
 - A small avatar for the post (but if not specified, the author's 
   default avatar is used)
 - A set of references to other posts, forums, archives, URLs, etc (which
   may include the keys necessary to post, manage, or read the referenced
   forums)

On the whole, Syndie works at the *content layer* - individual posts are
contained in encrypted zip files, and participating in the forum means
simply sharing these files.  There are no dependencies upon how the files
are transferred (over I2P, Tor, Freenet, gnutella, bittorrent, RSS,
usenet, email), but simple aggregation and distribution tools will be
bundled with the standard Syndie release.

Interaction with the Syndie content will occur in several ways.  First,
there is a scriptable text based interface, allowing basic command line
and interactive reading from, writing to, managing, and synchronizing
the forums.  For instance, the following is a simple script to generate
a new &quot;message of the day&quot; post -

    login
    menu post
    create --channel 0000000000000000000000000000000000000000
    addpage --in /etc/motd --content-type text/plain
    addattachment --in ~/webcam.png --content-type image/png
    listauthkeys --authorizedOnly true
    authenticate 0
    authorize 0
    set --subject &quot;Today's MOTD&quot;
    set --publicTags motd
    execute
    exit

Simply pipe that through the syndie executable and the deed is done:
cat motd-script | ./syndie &gt; syndie.log

Additionally, there is work going on for a graphical Syndie interface,
which includes the safe rendering of plain text and HTML pages (of
course, with support for transparent integration with Syndie's
features).

Applications based on the old Syndie's &quot;sucker&quot; code will enable the
scraping and rewriting of normal web pages and web sites so that they
can be used as single or multipage Syndie posts, including images and
other resources as attachments.

Down the line, firefox/mozilla plugins are planned to both detect and
import Syndie formatted files and Syndie references, as well as notify
the local Syndie GUI that a particular forum, topic, tag, author, or
search result should be brought into focus.

Of course, since Syndie is, at its core, a content layer with a defined
file format and cryptographic algorithms, other applications or
alternate implementations will probably be brought forward over time.

* 3.2) Why does Syndie matter?

I've heard several people ask over the last few months why I'm working
on a forum/blogging tool - what does that have to do with providing
strong anonymity?

The answer: *everything*.

To briefly summarize:
 - Syndie's design as an anonymity-sensitive client application carefully
   avoids the intricate data sensitivity problems that nearly every
   application not built with anonymity in mind does not.
 - By operating on the content layer, Syndie does not depend upon the
   performance or reliability of distributed networks like I2P, Tor, or
   Freenet, though it can exploit them where appropriate.
 - By doing so, it can operate fully with small, ad-hoc mechanisms for
   content distribution - mechanisms which may not be worth the effort
   for powerful adversaries to counteract (since the 'payoff' of busting
   just a few dozen people will likely exceed the cost of mounting the
   attacks)
 - This implies that Syndie will be useful even without a few million
   people using it - small unrelated groups of people should set up their
   own private Syndie distribution scheme without requiring any
   interaction with or even awareness by any other groups.
 - Since Syndie does not rely upon real-time interaction, it can even
   make use of high latency anonymity systems and techniques to avoid the
   attacks that all low latency systems are vulnerable to (such as
   passive intersection attacks, passive and active timing attacks, and
   active blending attacks).

On the whole, its my view that Syndie is even more important to I2P's
core mission (providing strong anonymity to those who need it) than even
the router.  Its not the end-all, be-all, but its a key step.

* 3.3) When can we use Syndie?

While a lot of work has been completed (including nearly all of the
text interface and a good portion of the GUI), work still remains.  The
first Syndie release will include the following baseline functionality:

 - Scriptable text interface, packaged up as a typical java application,
   or buildable with a modern GCJ
 - Support for all forum types, replies, comments, etc.
 - Manual syndication, transferring .snd files.
 - HTTP syndication, including simple CGI scripts to operate archives,
   controllable through the text interface.
 - Specs for the file formats, encryption algorithms, and database
   schema.

The criteria I'm using for pushing that out will be &quot;fully functional&quot;.
Joe Sixpack isn't going to mess around with a text-based app, but I'm
hoping some geeks will.

Subsequent releases will improve upon Syndie's capabilities across
several dimensions:
 - User interface:
  - SWT-based GUI
  - Web browser plugins
  - Web scrape text UI (pulling in and rewriting pages)
  - IMAP/POP3/NNTP reading interface
 - Content support
  - Plain text
  - HTML (safe rendering within the GUI, not in a browser)
  - BBCode (?)
 - Syndication
  - Feedspace, Feedtree, and other low-latency synchronization tools
  - Freenet (storing .snd files at CHK@s and archives referencing
    the .snd files at SSK@s and USK@s)
  - Email (post through SMTP/mixmaster/mixminion, read through
    procmail/etc)
  - Usenet (post through NNTP or remailers, read through (proxied)
    NNTP)
 - Full text search with Lucene integration
 - Extension of HSQLDB for full database encryption
 - Additional archive management heuristics

What comes out when depends on when things are done.

* 4) Open questions for Syndie

Right now, Syndie has been implemented with I2P's standard crypto
primitives - SHA256, AES256/CBC, ElGamal2048, DSA.  That last one is the
odd man out, however, since it uses 1024bit public keys and depends upon
(the rapidly weakening) SHA1.  One murmur I've heard from the field has
been the augmentation of DSA with SHA256, and while that's doable (though
not yet standardized), it only offers 1024bit public keys.

Since Syndie hasn't been pushed out into the wild yet, and there's no
worry about backwards compatability, we have the luxury of swapping the
crypto primitives around.  One line of thought is to opt for ElGamal2048
or RSA2048 signatures instead of DSA, while another line of thought is to
look towards ECC (with ECDSA signatures and ECIES asym encryption),
perhaps at the 256bit or 521bit security levels (paralleling 128bit and
256bit symmetric key sizes, respectively).

As for the patent issues regarding ECC, those seem to be relevent only
for particular optimizations (point compression) and algorithms we dont
need (EC MQV).  There isn't much out there in terms of Java support,
though the bouncycastle lib seems to has some code.  However, it probably
wouldn't be much trouble to add tiny wrappers to libtomcrypt, openssl, or
crypto++ either, like we did for libGMP (giving us jbigi).

Any thoughts on that?

* 5) ???

There's a lot to digest up there, which is why (on cervantes' suggestion)
I'm sending out these status notes so early.  If you've got any comments,
questions, concerns, or suggestions, please swing on by #i2p tonight at
8pm UTC on irc.freenode.net/irc.postman.i2p/irc.freshcoffee.i2p for our
*cough* weekly meeting!

=jr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFFBpC0zgi8JTPcjUkRAoPWAKCBhSJg6NOc0SY4xP/LuVRM6PxzZwCeIe9l
esxfTWz6qhtpyTUqsmoNlB4=
=zCOG
-----END PGP SIGNATURE-----


</pre>