Am Donnerstag, 15. Februar 2018, 08:03:20 CET schrieb Harsh Jain:
> 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.
> 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
> 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
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
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