On Thu, Feb 15, 2018 at 8:04 AM, Stephan Mueller <smuel...@chronox.de> wrote: > Am Donnerstag, 15. Februar 2018, 13:45:53 CET schrieb Harsh Jain: > >> > 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. > > As AF_ALG for AEAD is implemented, there is no stream support where the hash > is calculated at the end. This is even not supported in the current AEAD API > of the kernel crypto API as far as I see. The only "stream-like" support is > that you can invoke multiple separate sendmsg calls to provide the input data > for the AEAD. But once you call recvmsg, the ciphertext and the tag is > calculated and thus the recvmsg is akin to a hash_final operation.
If you follow Bernstein's protocol design philosophy, then messages should be no larger than about 4K in size. From https://nacl.cr.yp.to/valid.html: This is one of several reasons [1] that callers should (1) split all data into packets sent through the network; (2) put a small global limit on packet length; and (3) separately encrypt and authenticate each packet. With the [1] link being https://groups.google.com/forum/#!original/boring-crypto/BpUmNMXKMYQ/EEwAIeQdjacJ Jeff
