a few questions on AF_ALG specification (AEAD, socket/connection, ...)

[Nicolas Brunie <nicolas.brunie@kalray.eu>]

Hi All,
    I am developping a driver for a crypto offloading solution which 
uses the AF_ALG interface. I am trying to stay as close as possible to 
the specification but apart from the kernel crypto source code and a few 
documents (such as 
https://www.kernel.org/doc/htmldocs/crypto-API/ch04s06.html ) I have not 
found a lot of details on AF_ALG specification and many points are not 
very clear to me, it someone could point me towards reference to answer 
the following questions it will be deeply appreciated.
*
**

Socket / Connection :

Is it legal to open multiple connections on an AF_ALG socket ? How is 
the behavior defined

*From what I could test, at least for digests, multiple connections are 
OK, but it seems odd to allow multiple connection to a cipher while 
using a**shared key and multiple IVs. One of the use I could think of 
will be parallelizing several encryption/decryption with the same 
symmetric key.
*

Is it true that the key (defined via setsockopt) is common to all the 
connections but the IV (defined through message control header) is 
specific to each connection ?

*
*

Send/Recv interleaving

When computing a digest (e.g. sha256) it seems the recv call is 
triggering the end of the digest accumulation, such a behavior can be 
obtained by using/not using MSG_MORE flags, which *of the two*the 
canonical way to compute a hash over several send messages ? It does not 
seem possible to compute a partial digest (through a recv call) and then 
continue accumulating through other send calls (apart from the security 
risk of exposing a te*mporary digest, is there a reason why the recv 
ends a digest computation ?)*.*

*

AES-GCM / AEAD

Does the aead_assoclen must be set once and for all for each stream or 
is it a by message option ?

Option 0: set aead_assoclen during the first sendmsg and then stream 
accross several sendmsg the full AAD and then the full plaintext/ciphertext

Option 1: set aead_assoclen for each of the first sendmsg containing aad 
data. Once the aead_assoclen is strictly less than the msg’s data length 
then the next messages must have aead_assoclen set to 0

*

best regards,
Nicolas Brunie