gnunet-developers
[Top][All Lists]
Advanced

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

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


From: Benjamin Kay
Subject: Re: [GNUnet-developers] Resisting anti-P2P software systems
Date: Wed, 21 Apr 2004 00:01:48 +0000
User-agent: KMail/1.6.1

On Tuesday 20 April 2004 11:24 pm, Alexander Winston wrote:
> Because we lack detailed knowledge of these systems' innards, we can
> only assume that they all function in the same basic manner as ICARUS.
> This would mean that they have the ability to scan ports and monitor all
> of the data that are transmitted back and forth from the computers.
>
> I know that Christian Grothoff has suggested the use of port knocking;
> this would possibly be an effective defense against the systems' port
> scanning. I am curious to know how development of this is going, if at
> all.
>
> What do we have already or what can we write to project against complete
> traffic sniffing?

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.

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




reply via email to

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