[p2p-hackers] amicima's MFP - preannouncement

[Matthew Kaufman]

Lauri Pesonen [mailto:lauri.pesonen at gmail.com] (sent privately but
permission to reply to the list granted):
>
> In the end it  comes down to your threat model. If you think 
> a denial of service attack is probable then you should 
> implement a MAC.

More specifically, if you think a denial of service attack is probable and
your MAC is enough cheaper in CPU cycles than your decryption, add a MAC,
or...

> Getting past a CRC when modifying encrypted data is not improbable.
> Getting this far means that you end up using resources in 
> handling invalid packets. This opens up a venue for a DoS 
> attack. Using a MAC after encryption prevents the DoS attack 
> at the cost of requiring more resources in handling valid 
> packets, as you stated earlier.

There's also reasons other than a denial-of-service attack to want a MAC,
because it does add one more hoop to jump through for an attacker, which
with today's crypto technology probably is a significant improvement in
security (though without it, the security is still pretty darn good). It is
a bunch more CPU cycles though, so as I've pointed out before, deciding
whether or not to do it requires analysis of the performance requirements
vs. the threat model.

> In any case it is seen as a good practise to implement a MAC 
> on top of encryption. In your case the CRC and message 
> structure provides some probabilistic protection against 
> tampered packets. This is not the case in all applications.

No disagreement here.

> One remaining question is why wouldn't you add a MAC to the protocol?

Because the "protocol" doesn't need to have a MAC added. See below...

> It would make a lot of crypto people very happy and the 
> performance impact is not that huge (i.e. your network link 
> will most probably get bogged down before your CPU cycles run 
> out). Obviously adding unnecessary features to your 
> implementation is silly, but a lot of crypto experts (I'm 
> definitely not one of them) seem to demand a MAC in all 
> encrypted communication protocols.

As the other programmer here pointed out to me right after I sent my last
email, because our entire payload is "encrypted", adding a trailing MAC is
trivial (unlike in IPSEC, where the MAC needs to protect a different set of
bytes than what the encryption covers)...

In our implementation of the MFP protocol, ALL cryptographic operations are
implemented by a crypto "plug-in". (This means you can easily substitute
hardware-accelerated algorithms, proprietary or classified algorithms, etc.)

Application developers who want the extra protection of wrapping the
encrypted data with an HMAC may simply define an extended crypto plugin
which adds a trailing HMAC after encryption (there are some good papers
about why it needs to be done after, not before) on the transmit side and
which checks the HMAC prior to continuing with decryption on the receive
side. This causes no changes to the protocol itself, it simply changes the
definition of the cryptosystem that is plugged in (which, like the initial
session key choice, is application-defined). The secret key for the HMAC may
either be the same key as the AES key, or may be defined as a partitioning
of a larger exchanged key into the AES key part and the HMAC key part, and
doesn't change the key exchange part of the protocol itself either, because
key encryption and decryption are *also* defined by the implementation in
the cryptographic plugin.

We may or may not provide this HMAC-extended crypto plugin as the default or
as one of the initial options that ships with the first release, but it is
absolutely trivial for a developer to add if we don't. (And other
implementations of the protocol, while they might not use the same crypto
plug-in architecture are also free to add or not add a MAC)

The only real open issue that has been raised on this list and which we are
investigating is the issue with symmetric key choice vs. having one end
choose. Changing this likely requires a small change to the protocol
definition. Whether this is in version 1 or version 2 remains to be seen.

Matthew Kaufman
matthew at matthew.at
matthew at amicima.com
www.amicima.com