[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] Resisting anti-P2P software systems

From: Christian Grothoff
Subject: Re: [GNUnet-developers] Resisting anti-P2P software systems
Date: Tue, 20 Apr 2004 19:31:48 -0500
User-agent: KMail/1.6.1

On Tuesday 20 April 2004 19:01, Benjamin Kay wrote:
> We would be foolish not to pursue port knocking and other defenses against
> traffic sniffers, however I would point out that traffic sniffers cannot
> view the content of GNUnet data (it's encrypted) and that even if they
> could it wouldn't matter very much (deniablity). I think GNUnet is
> primarily about anonymity, not stealth.

GNUnet is primarily about privacy.  Now, for example steganography is 
typically far too expensive to be practical for P2P, but any level of stealth 
that is acceptable in cost is in the scope of the project (if somebody wants 
to put in the effort do actually implement it...)

> If port knocking were theoretically implemented in such a fashion that the
> traffic sniffers couldn't simply review the GNUnet code and adjust their
> sniffers to knock on ports accordingly (I have no idea how that is
> possible), that would only prevent the detection of a GNUnet node by a port
> scan.

Sure, the sequence must just not be pre-determined in the code.  Oh, and no, 
nobody has started to work on this yet.

> Ethereal-like sniffers could still examine existing traffic to 
> identify GNUnet nodes.
> Perhaps another tact would be to make GNUnet traffic inseperable from
> other, "legitimate" traffic. I cannot conceive of a way this could be used
> to conceal GNUnet traffic (other than, perhaps, steganography), but it
> would make GNUnet traffic a pain-in-the-ass to filter. A partial victory
> against the traffic sniffers.

Well, that's what the http and smtp transports are about.  Sure, now you could 
then go and program your sniffer to look for certain http/smtp traffic (would 
make the Internet crawl since the filters take so long, but that's a 
different story).  So next we use https.  And so on.  But of course all this 
assumes that someone actually implements things...



reply via email to

[Prev in Thread] Current Thread [Next in Thread]