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? > >> 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.
I personally feels AEAD IV serialization logic is incomplete without partial tag support. >> 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 > >
