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

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

[Nicolas Brunie]

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

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

[Stephan Mueller]

Am Dienstag, 26. Juli 2016, 13:48:21 CEST schrieb Nicolas Brunie:

Hi Nicolas,

> 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.

See [1] for the library around it.
> *
> **
> 
> Socket / Connection :
> 
> Is it legal to open multiple connections on an AF_ALG socket ? How is
> the behavior defined

Yes, you get a handle (i.e. a file descriptor) for each connection.
> 
> *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.

It is allowed

> *
> 
> 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 ?

Yes.
> 
> *
> *
> 
> 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 ?)*.*

You can read intermediary results. recv does not check for the MSG_MORE flag.

> 
> *
> 
> AES-GCM / AEAD
> 
> Does the aead_assoclen must be set once and for all for each stream or
> is it a by message option ?

Assoclen is handled like the IV, per message where a message may be sent in 
multiple chunks.
> 
> 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

Option 1, if I read your text right.
> 
> *

[1] http://www.chronox.de/libkcapi.html
> 
> best regards,
> Nicolas Brunie
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



Ciao
Stephan

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

[Tadeusz Struk]

Hi,
On 07/26/2016 04:54 AM, Stephan Mueller wrote:
>> > 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 ?
> Yes.

I think that's not correct. Please define a "connection".
If you think of connections as separate sockets, then you can
have different keys for each socket. The difference is that
you set a key per each socket once, and you send IV for each
operation (encrypt/decrypt).
Thanks,
-- 
TS

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

[Nicolas Brunie]

Hi,
  In my understanding, a socket is the file descriptor given as argument to a bind call and a connection is the file descriptor returned by an accept call. 

NB



----- Mail original -----
De: "Tadeusz Struk" <tadeusz.struk@intel.com>
À: "Stephan Mueller" <smueller@chronox.de>, "Nicolas Brunie" <nicolas.brunie@kalray.eu>
Cc: "Linux Crypto Mailing List" <linux-crypto@vger.kernel.org>
Envoyé: Mardi 26 Juillet 2016 16:37:51
Objet: Re: a few questions on AF_ALG specification (AEAD, socket/connection, ...)

Hi,
On 07/26/2016 04:54 AM, Stephan Mueller wrote:
>> > 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 ?
> Yes.

I think that's not correct. Please define a "connection".
If you think of connections as separate sockets, then you can
have different keys for each socket. The difference is that
you set a key per each socket once, and you send IV for each
operation (encrypt/decrypt).
Thanks,
-- 
TS

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

[Stephan Mueller]

Am Montag, 1. August 2016, 11:14:07 CEST schrieb Nicolas Brunie:

Hi Nicolas,

> Hi,
>   In my understanding, a socket is the file descriptor given as argument to
> a bind call and a connection is the file descriptor returned by an accept
> call.

This would be an appropriate naming:

The key is set on a socket. The IV is given with the connection.

> 
> NB
> 
> 
> 
> ----- Mail original -----
> De: "Tadeusz Struk" <tadeusz.struk@intel.com>
> À: "Stephan Mueller" <smueller@chronox.de>, "Nicolas Brunie"
> <nicolas.brunie@kalray.eu> Cc: "Linux Crypto Mailing List"
> <linux-crypto@vger.kernel.org>
> Envoyé: Mardi 26 Juillet 2016 16:37:51
> Objet: Re: a few questions on AF_ALG specification (AEAD, socket/
connection,
> ...)
> 
> Hi,
> 
> On 07/26/2016 04:54 AM, Stephan Mueller wrote:
> >> > 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 ?
> > 
> > Yes.
> 
> I think that's not correct. Please define a "connection".
> If you think of connections as separate sockets, then you can
> have different keys for each socket. The difference is that
> you set a key per each socket once, and you send IV for each
> operation (encrypt/decrypt).
> Thanks,



Ciao
Stephan