[3792] in linux-net channel archive

home help back first fref pref prev next nref lref last post

No subject found in mail header

daemon@ATHENA.MIT.EDU (Olaf Titz)
Sun Jul 21 06:12:02 1996

Date: 	Sat, 20 Jul 96 20:03 +0200
From: olaf@bigred.inka.de (Olaf Titz)
To: submit-linux-dev-net@ratatosk.yggdrasil.com

Newsgroups: linux.dev.net
Path: not-for-mail
From: Olaf Titz <olaf@bigred.inka.de>
Subject: Re: Encryption
Message-ID: <duustn.b3z@bigred.inka.de>
Date: 20 Jul 1996 20:03:20 +0200
References: <Pine.LNX.3.93.960714002211.10453C-100000@brando>
 <19960716134656.31485.qmail@slip-63-3.ots.utexas.edu>
Organization: private Linux site, southern Germany
Lines: 36

lilo  <TaRDiS@mail.utexas.edu> wrote:
> On Sun, 14 Jul 1996, Kevin M Bealer wrote:
> > I had a wierd idea for encryption -- Wouldn't it be possible
> > albeit slow to transmit encrypted data in the "magic number" of a
> > TCP packet? This is supposed to be a random number in all regards,

You mean either the TCP initial sequence number or the magic number of
PPP LCP, but it can be done.

> The way to detect it is being done is to keep up with this mailing list, and
> then look at the source, the source being publicly available.  Busted.
> Wouldn't apply to a proprietary solution, of course.  But it's `security by
> obscurity.'

Imagine someone implements a setsockopt() to set the ISN for an
unconnected TCP socket, and a getsockopt() to read it for a connected
socket. Reading the Linux source and this list will reveal that such
an API exists (heck, it should be fairly trivial) but neither this nor
network snooping will tell whether it's actually _used_. You can
transmit data with such a method without anyone being able to tell
that data _is_ transmitted.

(And don't think this is impractical. Even if you only transfer 16
bits of data per connection to satisfy the monotonicity (?) property
of ISNs, just set up an innocuous application like a WWW site mirror
that fires up many connections rapidly. You definitely are able to
transmit messages in this way. And as the secure random ISN option is
implemented now, traffic analysis won't tell that "something's
wrong".)

olaf
-- 
___        Olaf.Titz@inka.de or @{stud,informatik}.uni-karlsruhe.de       ____
__ o           <URL:http://www.inka.de/~bigred/>     <IRC:praetorius>
__/<_              >> Just as long as the wheels keep on turning round
_)>(_)______________ I will live for the groove 'til the sun goes down << ____


home help back first fref pref prev next nref lref last post