[p2p-hackers] amicima's MFP - preannouncement

[Matthew Kaufman]

Alex Pankratov:
> I have no doubt the authors of rfc3723 computed cycles/byte 
> correctly, however running a quick test with openssl yields 
> 36:5 ratio between AES-128-CBC and HMAC-SHA1. Note that this 
> uses assembly optimized AES implementation and rather 
> frivolious implementation of HMAC.

We will be benchmarking several implementations today. Last night I was
simply using the data I had available. Even at 36:5, HMAC isn't "free", and
you do pay for the extra overhead *in addition* to the symmetric encryption
*at both the sender and the receiver* in the non-attack case.

There is nothing about our design which precludes adding an HMAC trailer,
even a mandatory one, and we may add this to the specification after we see
the results of the benchmarks and look at the possible attacks.

> You don't need to check MAC to discard duplicate packet. If 
> you are looking at seqno that you already saw, you can drop 
> packet right away.

But an attacker isn't going to replay packets at you with existing sequence
numbers if he knows you're going to discard ones that you've already seen
without further processing... The attacker will instead modify the packets
in order to generate the maximum possible load at the receiver (since once
you have sequence numbers, the remaining attack is a cryptographic load
denial of service attack)

> The problem here is in 'probably not'. The mere presence of 'probably'
> outweighs all benefits. It basically means that security 
> services provided by the protocol may be susceptible to 
> certain attack that may or may not be on the list of threats 
> we are trying to defend against.

This "probably" is also true of SSL, TLS, IPSEC, etc. Each one has
already-known attack vectors and tradeoffs in their designs and
implementation. And new ones are being found all the time. The IPSEC
situation, for instance, is in many ways worse than this.

It is also true of the underlying choice of cryptosystem... Using SHA-1 as
your HMAC basis opens you to known attacks on SHA-1. Using RSA for your
public-key crypto opens you up to brute-force attacks (and maybe more)
against the private keys.

But the good news is that what we're releasing will be available in source
form, for inspection, and we are open to improving the security as known or
suspected attacks against it materialize. (And if we stop being open to it,
you can change the source yourself) Already, that's better than the
cryptography that most existing P2P users are using (none, in the case of
most p2p networks, or proprietary and unavailable for inspection, in a few
cases, like Skype)

Our primary goal in adding encryption and authentication to MFP was not to
make the strongest possible transport... It was rather to get relatively far
away from the present situation, where everyone doing P2P is running
everything in plain text with no attempt at authentication at all.  If by
making a few changes we can make it all that much stronger, then sure, we'll
do that.

Matthew