On 3/12/2013 10:57 PM, Chaoxing Lin wrote:
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.
Horia,
Do you plan to fix talitos driver to make it ESN capable in the near future? Or just simply remove ESN option completely.
On-going discussion internally, since right now adding proper support
for ESN doesn't seem to be trivial, so right now I don't have an answer.
The freescale crypto engine is still capable of doing AES-CBC + HMAC-SHAxxx in one shot.
"DESC_HDR_TYPE_IPSEC_ESP" may not able to achieve authencesn.
Correct. And that's why I think reverting "crypto: talitos - add IPsec
ESN support" is the right thing to do.
But the hmac-snoop-aes should do the job well.
You mean "hmac_snoop_no_afeu" (defined DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU
but not implemented...) ? I doubt this is the straightforward choice.
2 descriptors are needed.
Agree.
The first one is to do AES-CBC,
The second one snoop the output from the first crypto operation and then does HMAC-SHAxxx.
The two descriptors are chained and pushed to crypto engine at the same time. Callback is triggered only when both operations are done.
From the looks of it, both descriptors need to be of type
"DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU", first - ablkcipher - doing
aes(cbc), second - ahash - performing hmac(sha).
Since you are from freescale, I assume you know what I am talking about.
Try searching "AN3645 SEC 2/3x Descriptor Programmer’s Guide", the
application note contains more details than the reference manual I
assume you are using.
--
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
