On 15-02-2018 17:15, Stephan Mueller wrote: > Am Donnerstag, 15. Februar 2018, 12:38:12 CET schrieb Harsh Jain: > > Hi Harsh, > >> On 15-02-2018 12:47, Stephan Mueller wrote: >>> Am Donnerstag, 15. Februar 2018, 08:03:20 CET schrieb Harsh Jain: >>> >>> Hi Harsh, >>> >>>> Even after guarantee of serialization, In the end we will get wrong >>>> result >>>> as mentioned above. which destination side cannot decrypt it. What I feel >>>> is scenario of sending 2 of more IOCB in case of AEAD itself is wrong. >>> Without the inline IV handling, I would concur. >> Even with Inline IV, We will have 2 Auth Tag. can we authenticate the data >> with 2 Auth Tags? > The AAD and the tag are both sent to the kernel like in the inline IV case as > part of the data via sendmsg. > > Thus, when you use inline IV support, an entire self-contained AEAD cipher > operation can be defined with one IOCB. Thus, if you have multiple IOCBs, > inline IV allow fully parallel execution of different AEAD requests. > > See the following kernel comment: > > /* > * Encryption operation - The in-place cipher operation is > * achieved by the following operation: > * > * TX SGL: AAD || PT > * | | > * | copy | > * v v > * RX SGL: AAD || PT || Tag > > /* > * Decryption operation - To achieve an in-place cipher > * operation, the following SGL structure is used: > * > * TX SGL: AAD || CT || Tag > * | | ^ > * | copy | | Create SGL link. > * v v | > * RX SGL: AAD || CT ----+ > */ > > Note, the TX SGL is what the caller submitted via sendmsg and the RX SGL is > the data the caller obtains via recvmsg. > > Hence, in inline IV support, the caller sends the following: > > encryption: IV || AAD || PT > > decryption: IV || AAD || CT || Tag > >>>> We >>>> should not allow this type of requests for AEAD. >>> "Not allow" as in "technically block"? As a user would only shoot itself >>> when he does that not knowing the consequences, I am not in favor of such >>> an artificial block. >> Agreed, It may not be right thing to do, but if we allowed it, What he will >> do with Auth( each processed with final Block) tags received in each >> request. > Each tag is returned as part of the recvmsg data. Thus, AEAD cipher operations > can commence fully parallel if inline IV handling is used. >> I personally feels AEAD IV serialization logic is incomplete without partial >> tag support. > Could you please elaborate what you mean with "partial tag" support? Here is the catch, Calculation of tag depends on total payload length atleast for shaX, gcm,ccm mode on which I have worked. If we take an example of shaX. It appends 1 special block at the end of user data which includes total input length in bit. Refer "sha1_base_do_finalize" Suppose we have 32 byte and we break this in 2 IOCB of 16 bytes each. Expected result : 32 encrypted bytes + sha auth tag considering length 32 bytes. What we will get : 16 bytes + sha auth tag considering length 16 bytes + 16 encrypted bytes + another sha tag considering 16 bytes. > > Ciao > Stephan > >
