[Cryptography] traffic analysis

[ianG]

On 30/01/2015 01:35 am, Richard Outerbridge wrote:
> On 2015-01-29 (29), at 11:22:14, ianG <iang at iang.org> wrote:
>
> [….]
>
>>> Which as we all know is pretty much impossible.
>>
>> That I don't follow.
>>
>> iang
>>
>
> Maybe things have changed. I’ve always thought in principle
> it is impossible to achieve insignificant (for some epsilon
> of significance) levels of false positives & false negatives
> at the same time with the same level of insignificance. No?


Oh I see.  A second reading made it clear.  You're talking about the 
base rate fallacy.

Yes, if there is any uncertainty, but I'm assuming that there is no 
uncertainty.  I'm thinking these assumptions:

1.  the packets are indistinguishable from random.
2.  receiver takes the last N bytes and assumes it is a HMAC.  If it 
calculates, it is good, if not, throw.
3.  inside the encryption packet there is a further authenticator e.g. 
public-key sig at the application level.

Due to DOS and performance reasons, you can dial the HMAC down a fair 
bit, the public-key sig will have your back.  SHA1 which I've used in 
the past is way overkill, I'd reckon about 8 bytes would do it.

The hard part is 1. indistinguishable from random.  Because you're doing 
this over IP packets there are IP# and port# considerations (how many 
clients, routers, etc).

Also, for testing and usability you actually want to know what is going 
wrong, and this notion deliberately hides that.  Note also Jerry's 
rather interesting comment that we need include anti-DOS as a 
requirement, that is pretty challenging.  We also want to include 
anti-DOS detection at least where mucky intermediates just cause the 
packets to drop because they can't do deep-packet inspection on them.

All of these things have tended to be broad giveaways as to the type of 
traffic.  So you can only go so far before you're dancing on a pin.



iang