[Cryptography] traffic analysis
ianG
iang at iang.org
Fri Jan 30 04:34:25 EST 2015
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
More information about the cryptography
mailing list