Re: Packet timing to send key bits

dsr_at_Florence.edu
Date: 03/02/04 

Date: Tue, 02 Mar 2004 12:47:57 GMT

On Tue, 2 Mar 2004 07:16:14 +0000 (UTC), daw@taverner.cs.berkeley.edu
(David Wagner) wrote:

>Gregory G Rose wrote:
>>David Wagner <daw-usenet@taverner.cs.berkeley.edu> wrote:
>> >Gregory G Rose wrote:
>> >>For each bit to be sent replicate it many times
>> >>and XOR with a stream cipher and use it to
>> >>influence the packet timings in some manner. At
>> >>the other end, reconstruct the packet timings, and
>> >>assign 0/1 to them on a best efforts basis. Then
>> >>XOR with the stream cipher, and coalesce the bits
>> >>back together based on simple majority rule.
>>
[snip}
>
>I guess the question of whether this provides a secure form of stego will
>depend heavily on precisely how we use each bit of ciphertext to influence
>the packet timings. The details probably matter a lot. But yes, it
>seems believable that one would be able to build a fairly well-hidden
>stegosystem in this way. (It won't be secure against "active warden"
>attacks, but security against "passive wardens" seems within reach.)

You can't expect a system to be robust simply because the details are
hidden. Since we are talking about timing tightly interlaced
transmissions with RTDSC there is a level of accuracy not achievable
from packet contents and time stamped headers. There is also a degree
of error in the measurement of these timings because crystal clocks
are not 100% accurate.

If I am transmitting in a loop from computer A to computer B then back
to computer A, some of the error from my computer will be self
canceling.
The same can be said for computer B who is sending an interlaced
signal the other direction from their computer B to computer A and
back.

The key is that an eavesdropper with computer C has an *additional
error* in measurement that can not be self canceling because they are
simply eavesdropping and not part of the dynamic rollup at either of
the destination nodes.

Using error thresholding methods you can keep computer C just out of
range enough so that you at computer A and your correspondent at
computer B can pass bits.

Relevant Pages

  • Re: performance problems ASP.NET
    ... Today I tested again without any code changes and the timings are as ... I could fix that somehow and try again, but ProcessPostData is ... measurement, ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: performance problems ASP.NET
    ... Today I tested again without any code changes and the timings are as ... I could fix that somehow and try again, but ProcessPostData is ... measurement, ...
    (microsoft.public.dotnet.framework.aspnet)