[tor-dev] GSoC project idea: pluggable transport that hides data in TCP SEQ numbers / UDP SRC ports
Jim Rucker
mrjimorg at gmail.com
Fri Jan 10 06:19:32 UTC 2014
This is an attempt at security though obscurity, which doesn't work well in
open source projects.
On Tue, Jan 7, 2014 at 10:09 AM, George Danezis <georged at gmail.com> wrote:
> Hello Jacek and all,
>
> Before, going down this path I would recommend reading the very relevant
> works:
>
> *Embedding Covert Channels into TCP/IP*
> *Steven J. Murdoch, Stephen Lewis <http://www.cl.cam.ac.uk/%7Esrl32/>*
> It is commonly believed that steganography within TCP/IP is easily
> achieved by embedding data in header fields seemingly filled with “random”
> data, such as the IP identifier, TCP initial sequence number or the least
> significant bit of the TCP timestamp. We show that this is not the case;
> these fields naturally exhibit sufficient structure and non-uniformity to
> be efficiently and reliably differentiated from unmodified ciphertext.
> Previous work on TCP/IP steganography does not take this into account and,
> by examining TCP/IP specifications and open source implementations, we have
> developed tests to detect the use of naïve embedding. Finally, we describe
> reversible transforms that map block cipher output into TCP ISNs,
> indistinguishable from those generated by Linux and OpenBSD. The techniques
> used can be extended to other operating systems. A message can thus be
> hidden in such a way that an attacker cannot demonstrate its existence
> without knowledge of a secret key.
> *7th Information Hiding Workshop <http://www.uoc.edu/symposia/ih05/>,
> Barcelona, Catalonia (Spain), 06–08 June 2005. Published in LNCS 3727
> <http://www.springerlink.com/content/978-3-540-29039-1/>, Springer-Verlag.*[
> paper <http://www.cl.cam.ac.uk/%7Esjm217/papers/ih05coverttcp.pdf> ]
>
> and
>
> John Giffen, Rachel Greenstadt, Peter Litwack, Richard Tibbetts, Covert
> Messaging in TCP<https://www.cs.drexel.edu/%7Egreenie/eecs_files/tcpcovertchannels.pdf>,
> Privacy Enhancing Technologies (PET), April 2002 <http://www.pet2002.org>
>
> Best regards,
>
> George
>
>
> On Tue, Jan 7, 2014 at 4:02 PM, Ian Goldberg <iang at cs.uwaterloo.ca> wrote:
>
>> On Tue, Jan 07, 2014 at 06:41:02AM -0800, Jacek Wielemborek wrote:
>> > Hi,
>> >
>> > I recently had an opportunity to watch David Fifield's lightning talk on
>> > pluggable transports that he gave on 30C3. I find the topic fascinating
>> and I'm
>> > considering an application to your project for the upcoming Google
>> Summer of
>> > Code.
>> >
>> > My idea is a bit complicated - I'd like to create a pluggable transport
>> that
>> > hides data in TCP sequence number gaps or UDP source port numbers. I
>> don't yet
>> > have all details thought over, but the way I imagine it right now, the
>> user
>> > would have to establish a TCP or UDP connection to the relay. The
>> connection
>> > could be completely bogus, though it'd be useful if a lot of data was
>> sent
>> > over it. After connecting, the client sends to the server a message
>> with a
>> > random RSA key steganographically hidden in the TCP sequence numbers.
>> If the
>> > server replies the same way with an RSA-encrypted AES key, the rest of
>> the
>> > hidden transmission goes encrypted with it. Since the SEQ number gaps
>> are
>> > meant to be random anyway, I believe that this could be very hard to
>> detect.
>>
>> Only the initial SEQ of a TCP connection is random (and usually only ~24
>> bits at that). The subsequent SEQs are deterministic. Can you clarify
>> your intent?
>>
>> - Ian
>> _______________________________________________
>> tor-dev mailing list
>> tor-dev at lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>>
>
>
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20140110/35a68d78/attachment.html>
More information about the tor-dev
mailing list