On 15-02-2018 11:58, Stephan Mueller wrote: > Am Donnerstag, 15. Februar 2018, 06:30:36 CET schrieb Harsh Jain: > > Hi Harsh, > >> On 14-02-2018 18:22, Stephan Mueller wrote: >>> Am Mittwoch, 14. Februar 2018, 06:43:53 CET schrieb Harsh Jain: >>> >>> Hi Harsh, >>> >>>> Patch set is working fine with chelsio Driver. >>> Thank you. >>> >>>> Do we really need IV locking mechanism for AEAD algo because AEAD algo's >>>> don't support Partial mode operation and Driver are not updating(atleast >>>> Chelsio) IV's on AEAD request completions. >>> Yes, I think we would need it. It is technically possible to have multiple >>> IOCBs for AEAD ciphers. Even though your implementation may not write the >>> IV back, others may do that. At least I do not see a guarantee that the >>> IV is *not* written back by a driver. >> There is no use of writing IV back in AEAD algo till Framework starts >> supporting Partial mode. > I agree. > >> Even if Driver starts updating IV for AEAD, >> Multiple IOCB's in both cases will yield wrong results only. > This would only be the case if the driver would not implicitly or explicitly > serialize the requests. >> Case 1 : If we have AEAD IV serialization applied, Encryption will be >> wrong if same IV gets used. > Agreed. > >> Case 2: If we do not have IV serialization for >> AEAD. Encryption will be fine but user will have multiple Authentication >> tag (that too with final block processed). Its like 2nd Block encryption >> is based on IV received from 1st block and Authentication Tag value is >> based on 2nd block content only. > Agreed. > > But are we sure that all drivers behave correctly? Before you notified us of > the issue, I was not even aware of the fact that this serialization may not be > done in the driver. And we only have seen that issue with AF_ALG where we test > for multiple concurrent AIO operations. I am sure other H/W will have similar problem, It's just that we tested it first. > > Besides, when we do not have the locking for AEAD, what would we gain: one > less lock to take vs. guarantee that the AEAD operation is always properly > serialized. 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. We should not allow this type of requests for AEAD. Can you think of any use case it is going to solve? Can receiver decrypt(with 2 IOCB) the same request successfully without knowing sender has done the operation in 2 request with size "x" each? > > Ciao > Stephan > >
