[p2p-hackers] amicima's MFP - preannouncement

[Matthew Kaufman]

Lauri Pesonen:
>
> I'm sure you are aware that encryption only without 
> authentication is considered a bad idea in crypto circles

It is considered an idea which leaves open additional theoretical avenues of
attack which are only partially mitigated by adding the authentication.

(AES without HMAC is safe unless someone can corrupt the AES data in such a
way as to cause a problem for you. Then you're safer with HMAC, *only* as
long as the same attacker doesn't also have a working attack against your
HMAC scheme... All you're doing is locking two doors instead of one...
You're not preventing a great locksmith from getting through both)

> (even the IPSec RFCs warn against it)

The case of IPSEC is substantially different... The IPSEC RFCs warn against
encryption without authentication because in IPSEC there are fields which
*cannot be encrypted*, but which *can* be protected with the HMAC.

The attack vectors against IPSEC when used with ESP and without AH largely
rely on the possibility opened to manipulate the fields which are not
encrypted and are then not protected with the AH.

> and I assume you have 
> decided to go against the grain here for performance reasons.

Performance and because the attack possibilities are different than in
IPSEC. We are open to analyses that show how big the real vulnerability is
in our work. And there's nothing about our protocol design that precludes
adding an HMAC trailer if it were to be deemed necessary.

> That does not change the fact that it's a bad idea. Recently 
> there was an attack published on IPSec with ESP and without AH:
> 
> http://www.uniras.gov.uk/niscc/docs/al-20050509-00386.html?lang=en

I've seen this... There are three basic attacks described in the paper, none
of which appears to directly apply to our work.

In #1, you perform a successful bit-flipping attack on the encryption to
change the destination address on a tunneled packet, which is then decrypted
by the tunnel endpoint and sent to the wrong final destination, which could
be where the attacker is monitoring.

We are potentially vulnerable to bit-flipping attacks, but you'd need to
successfully flip bits such that the checksum stays valid and the chunk
formatting stays valid, which is probably harder than modifying a single IP
address in the header. Furthermore, because we don't decrypt at an
intermediate tunnel, this attack cannot be used to redirect plaintext data
anywhere, it could only be used to change what is being received, if it were
carried out successfully (requires the ability to do this data modification
*and* intercept the valid packets before those arrive).

In #2 and #3 you damage the encrypted tunneled packet such that after it is
decrypted and passed to the final recipient, the final recipient rejects it
with a plaintext ICMP message which contains, as per the ICMP spec, a
portion of the plaintext that was received.

Both of these rely on the obvious danger of including decrypted plaintext in
an error reply, and are much easier to carry out, because you can leave the
authenticated part alone, damage the encrypted part, and get the plaintext
out. Since we never generate plaintext replies, particularly plaintext
copies of encrypted data, we don't have this issue. Also, we don't have a
non-encrypted part that can stay undamaged.

> Now the attack is a very special case and from a practical 
> point of view and does not give the attacker a huge 
> advantage. This might be even more true for MFP. But it does 
> show that encryption without authentication is a bad idea and 
> does give the attacker _an_ advantage. 

But in the IPSEC case that advantage comes primarily from the ability to
manipulate the encrypted part separately from the unencrypted (and not
authenticated if you're not using AH) part in some of the earlier published
attacks, or the ability to leave the tunnel encapsulation intact while
modifying the interior encrypted packet (as in the cases discussed above).

> And as history shows, 
> any advantage in crypto tends to grow bigger as attacks 
> evolve in time.

This is true. And over time, the algorithms become less secure against both
analysis and brute-force attacks.
 
> I think you should look again at your performance 
> requirements and re-evaluate whether adding authentication 
> incurs an unacceptable performance hit. Basically at the 
> moment you are going against time-proven crypto thinking.

We will reevaluate this, but as I pointed out above, all that is going on
here is adding a second door. Adding an HMAC simply means that someone who
figures out a successful attack vector that depends on modifying the
AES-encrypted data such that it is wrong but checksums and passes format
checks correctly must now also have an attack on the HMAC that works too.
What it doesn't do is change this from "insecure" to "perfectly secure", and
since we don't know the odds that someone who can manipulate AES to their
advantage also knows how to create HMAC collisions, we don't even know how
much more secure it would be.

Matthew