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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev >> > > > _______________________________________________ > tor-dev mailing list > [email protected] > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > >
_______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
