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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
