Am Donnerstag, 12. Januar 2017, 14:19:36 CET schrieb Herbert Xu: Hi Herbert,
> On Tue, Jan 10, 2017 at 02:36:21AM +0100, Stephan Müller wrote: > > to all driver maintainers: the patches I added are compile tested, but > > I do not have the hardware to verify the code. May I ask the respective > > hardware maintainers to verify that the code is appropriate and works > > as intended? Thanks a lot. > > > > Herbert, this is my proprosal for our discussion around copying the > > AAD for algif_aead. Instead of adding the code to algif_aead and wait > > until it transpires to all cipher implementations, I thought it would > > be more helpful to fix all cipher implementations. > > I think it's too much churn. Let's get the algif_aead code fixed > up first, and then pursue this later. My idea with this patch set was to have only a minimal change to any AEAD implementation, i.e. one callback to address this issue. When addressing the issue in the algif_aead code, and expect that over time the AEAD implementations will gain the copy operation, eventually we will copy the AAD twice. Of course, this could be prevented, if the algif_aead code somehow uses the same SGL for the src and dst AAD. Some time back I published the patch "crypto: AF_ALG - disregard AAD buffer space for output". This patch tried changing the src and dst SGL to remove the AAD. Considering this patch trying to change the src and dst SGL structure, I expect that the patch to algif_aead to have a common src/dst SGL for the AAD to prevent the AAD copy from the AEAD implementations is similar in complexity. Weighing the complexity of such temporary band-aid for algif_aead with the addition of one callback to each AEAD implementation (which would need to be added some when anyway), I thought it is less complex to add the one callback to the AEAD implementations. > > BTW, why are you only doing the copy for encryption? I was looking at the only AEAD implementation that does the copy operation: authenc. There, the copy operation is only performed for encryption. I was thinking a bit about why decryption was not covered. I think the answer is the following: for encryption, the AAD is definitely needed in the dst buffer as the dst buffer with the AAD must be sent to the recipient for decryption. The decryption and the associated authentication only works with the AAD. However, after decrypting, all the caller wants is the decrypted plaintext only. There is no further use of the AAD after the decryption step. Hence, copying the AAD to the dst buffer in the decryption step would not serve the caller. Ciao Stephan -- 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
