Hi all, Le 13/01/2017 à 12:39, Herbert Xu a écrit : > On Fri, Jan 13, 2017 at 12:36:56PM +0100, Stephan Müller wrote: >> >> I thought I understood that you would not want to see it in any >> implementation. But, ok, if you want to leave it. > > If you remove it from authenc then authenc will be broken. >
Hence if the copy of the associated data is needed in the crypto/authenc.c driver, then I should also keep this copy in the drivers/crypto/atmel-aes.c for authenc(hmac(shaX),cbc-aes) algorithms [1], shouldn't I? If so, should I keep the current not optimized implementation of atmel_aes_authenc_copy_assoc() or try to use the code extracted by Stephan from crypto/authenc.c using the null cipher as proposed in this thread? As said earlier in this thread, copying the associated data is not a so big deal when compared to the main crypto processing. For instance, with IPSec ESP with AES in CBC mode, the associated data layout should be: Security Parameters Index (SPI): 4 bytes Sequence Number: 4 bytes AES IV: 16 bytes So it's only a 24 byte copy. I've taken Stephan's other comments into account from his review of the atmel-authenc driver so I'm preparing a new series but I don't know what to do for the associated data copy. Please let me know what you recommend, thanks! Best regards, Cyrille [1] https://lkml.org/lkml/2016/12/22/306 -- 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
