Re: authencesn compatibility problemn between software crypto and talitos driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3/11/2013 9:15 AM, Steffen Klassert wrote:
Ccing Horia Geanta, he did the esn implementation for talitos.

On Fri, Mar 08, 2013 at 03:27:48PM +0000, Chaoxing Lin wrote:
1. Can any one point me which RFC describe how exactly authencesn should work?


The ESN algorithm is described in RFC 4303 IP Encapsulating Security
Payload (ESP).

2. I test Ipsec with "esp=aes256-sha512-esn!" options and found compatibility issue between kernel software crypto and talitos driver.
Talitos <---->talitos				Good
Soft crypto<---->soft crypto			Good
Soft crypto<---->talitos			link established but no traffic can pass through.

That's what happens when interop testing is not performed...


3. Looking at source code of latest stable kernel 3.8.2, I found that these two implementations don't agree on what's to be hashed in ESN case.
Talitos driver is more intuitive in that  "assoc (SPI, SN-hi, SN-low) + IV + payload" are hashed.

The ESN implementation of the talitos driver looks rather scary,
it just renames authenc to authencesn in talitos_probe(). The
algorithm pretends to be authencesn but still does authenc, of course.
authencesn has to be implemented, it is not sufficient to change
the name, really.

Seems that somehow I got confused, considering the "one/single-pass over data" description the same as "combined mode algorithm".

I will post a fix or revert the patch if HW does not allow the correct behaviour.


Kernel software crypto is counter-intuitive in that "hsg(SPI, SN-low) + sg(IV + payload) + tsg(SN-hi" are hashed.

This might look counterintuitive, but that's what RFC 4303 describes
for ESN if separate encryption and integrity algorithms are used.

Yes, appending the SN-hi after Payload (Next Header) is the correct way to handle separate encryption and integrity algos.

For combined ones (AES-CCM, AES-GCM, AES-GMAC etc.), behavior is defined separately in corresponding RFCs (4309, 4106, 4543). Usually SN-hi is positioned between SPI and SN-lo.



--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux