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. > 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. > Can you think of any use > case it is going to solve? Well, I could fathom a use case of this. In FIPS 140-2 (yes, a term not well received by some here), NIST insists for GCM that the IV is handled by the cryptographic implementation. So, when using GCM for TLS, for example, the GCM implementation would know a bit about how the IV is updated as a session ID. I.e. after the end of one AEAD operation, the IV is written back but modified such to comply with the rules of some higher level proto. Thus, if such a scenarios is implemented by a driver here, multiple IOCBs could be used with such "TLSified" GCM, for example. And such "TLSification" could be as simple as implementing an IV generator that can be used with every (AEAD) cipher implementation. > 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 Ciao Stephan
