[p2p-hackers] amicima's MFP - preannouncement

[Alex Pankratov]

Matthew Kaufman wrote:

[snip]

>>Few I can think of off hand are -
>>
>>* the use of MACs. Relying on validity marker in plaintext 
>>payload to detect corrupted packets is expensive 
>>computationally-wise in a worst case scenario, while 
>>HMAC-based authentication costs pennies.
> 
> Not true. See appendix B of rfc3723 (or other equivalent sources). For a

[snip]

> Summary is that if you run SHA1 HMAC and AES, you save about 10% on cycles
> when you're being attacked and you pay for that small savings by using
> almost 90% more cycles when you're not.

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.

If you consider a hardware implementation, then any modern ESP-capable
crypto accelerator will be computing HMAC in parallel with decryption,
which would result in zero overhead.

> 
>>It also 'not good' from cryptographical perspective, but I 
>>cannot comment on that (note though how SSH was switched to 
>>using MACs in v2). Besides MACs are also required for implementing -
>>
>>* replay protection, which involves tagging packets with 
>>unique sequence numbers after the encryption but before the 
>>authentication.
> 
> Replay protection can also be placed inside the encryption in a similar
> fashion... The real question is, does putting it outside and using HMAC save
> you cycles in the being-attacked case (so that you can discard replays prior
> to decryption cost)? And the answer is "not enough, especially given the
> penalty in the non-attack case".

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.

[snip]

> 
>>This way replayed or duplicate packets can be discarded 
>>without wasting any time on decryption or authentication at all.
> 
> 
> Well, you can't use the non-encrypted sequence number that you see until you
> check the HMAC... And that has non-zero cost, as described above.

See above.

>>* session key being derived in 'symmetrical way', when both 
>>parties contribute to the key in equal degree.
> 
> This is a valid argument, and we have previously discussed this internally

[snip]

> 
>>Basically security component of your protocol looks very 
>>different from existing mature protocols. And I would suspect 
>>that this will not facilitate adoption of MFP .. at least not 
>>in its secured form.
> 
> It actually looks quite like IPSEC ESP without AH... Consider the session ID
> as the security association identifier and go from there.
 >
> In reality, though, in order to determine if a secure network protocol is
> right for your application, you must consider the threats that you are
> protecting against, and compare that to the benefits. 

Agreed.

 > Is this as secure as
> some other protocols? Probably not. Does it have numerous advantages for
> certain applications? Absolutely. 

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.

Alex