[Cryptography] Really good ideas, harsh reality, tailored covertraffic

[Peter Fairbrother]

On 03/09/2020 20:36, Dan McDonald wrote:
> On Thu, Sep 03, 2020 at 10:00:16AM -0400, Paul Wouters wrote:
>> https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-01
>>
>>     This document describes a mechanism to enhance IPsec traffic flow
>>     security by adding traffic flow confidentiality to encrypted IP
>>     encapsulated traffic.  Traffic flow confidentiality is provided by
>>     obscuring the size and frequency of IP traffic using a fixed-sized,
>>     constant-send-rate IPsec tunnel.  The solution allows for congestion
>>     control as well.

Haven't read it in detail, IETF draft language gives me a headache, but 
it looks a bit like the US-USSR hotline - when it wasn't in use random 
traffic was sent so an observer couldn't tell whether the traffic was 
random-looking-encrypted-real or just random. The rate of traffic 
was/is? constant.

> It looks like an attempt to reduce bandwidth waste.  

If (it is not clear) you are referring to tailored covertraffic, that is 
more effective in reducing total traffic.

To reduce total traffic the tailoring is done in such a way that the 
covertraffic has a rate distribution and/or other characteristics 
similar to the real traffic - so instead of just the real traffic 
looking suspicious, all the traffic looks suspicious.

However it is not (necessarily) done at a constant rate.

There are some caveats and notes - the only way to be 100% sure that 
traffic is concealed is to use a constant rate. However if 100% 
confidentiality is not required then tailored covertraffic can reduce 
traffic costs.

In the original application, a steganographic filing system, you can 
under duress (eg a warrant) give up some real traffic, and an observer 
can't say you haven't given up all the real traffic.

Probably doesn't work if the duress is torture, but against "beyond 
reasonable doubt" it should work.

One thing I worry about,
> if IP packets can span multiple tunnel IP packets, won't end-to-end
> performance suffer under even mild drop rates?

This can be overcome by splitting the traffic into m-of-n blocks, where 
the real traffic is split into n blocks using a block erasure code, and 
any m (<n) blocks can reconstruct the original.

Not perfect, you still need a resend mechanism, but it takes more than 
one dropout for a resend to be required. You can also tailor it to the 
dropout rate by changing n.


Peter Fairbrother