Official rebuttal

my minimum rebuttles, please add if you like.

we know the connection per node is random in the node.ref but we have
certain distances already decided in the private relay server side,
the ircd server is not on that public list, as you do not know the
topology of
the network, you will not be able to ascertain how you can attack the
anonymity
with your 15 minute preview of code. See chaining below to learn about
setting up
your own routes.

Second, iip.invisiblenet.net is definitely not the iip server or even
close, it's not relevant, it's literally another node, thanks for the
assumption though.

3rd, inform has no more information that what's in the node.ref list,
all it's duty is is to make sure routes are stable. Also, that's outside
the US either way, just by coincidence, but it doesn't hurt. If inform
goes
down or is attacked, it has no effect on the current state of IIP.

Chaining and hopping, you have the option of private relays, what we
call neighbor
noding to chain your own hops by choice, and the future versions would
like
to make this more user friendly. CofE has expressed that he uses this
feature.
Inside the directory of your iip software (if you become a private
relay, please see 
mynode.ref). Feel free to hand that to your friends as their node.ref. 

Addressed is the plaintext into the ircd server, that doesn't
eliminate anonymity, as it's as good as a public channels knowledge of
the text
seen, all we see is nick and words if we were to monitor. This is agreed
that we want to decentralize, however it does not reveal users
identities, such as freesites don't reveal identify from their messages.
(We have
an optional anonymous mode flag that could be used to hide nicks as
well, for the
extremely paranoid, or those who do not choose to use their pseudonym to
converse).

In response to the users becoming relays and timing attacks against
killed connections. If you look inside the node.ref at the network
protocol,
first marker states closedelay: we use delay to assist against this
attack,
as it delays the disconnect of a user at random intervals to make it not
exactly obvious of who is connected to what IP. This is specifically
prevalant as there are many channels and it adds doubt that you can 
possibly monitor them all since you are limited to being in 10. 
And for the users that do not join channels at all and converse
privately, 
somehow they are not anonymous?

I will admit there are a few things to do at the ircd level, removing
notice is one, and /whois is two. But stating that you have eliminated
anonymity on IIP with the data and lack of facts you have demonstrated
is rather vague and I'm glad you took 15 whole minutes to review our
code
and you know everything about the topology of IIP networking. 
The more recent developers on this project are still 
taking quite a bit of time getting through the code, and you have
miraculously eliminated the security of IIP in 15 minutes after 2 years
in
existance and it having been peer reviewed by certain members of the
cryptography community (including a presentation on it's protocol at
codecon 2k2),
as well as certain scientists at MIT.

P.S. SSL compared to our cryptography protocols is quite different.
we have implemented certain properties in order to protect against
traffic analysis and quite a bit other stuff that is specific to
anonymity needs. Thanks for the opportunity and we do appreciate your
review of it. Hopefully next time before calling out the scare
patrol, you'd like to consult with the developers before making such
assumptions. 


0x90

Also found at http://63.241.8.112/iiprebuttal.txt

Thanks.