Hi,
I'm trying to experimentally implement the GCM-SIV AEAD algorithm from
[1] for the Linux crypto API and I've ran into a problem...
Basically, the encryption/decryption process starts by deriving a
so-called "record-encryption key" from the nonce (by encrypting it
using another key) and this key is then used to encrypt the plaintext
in CTR mode and to encrypt the final authentication tag (otherwise it
works similarly to GCM).
Since the API is asynchronous and multiple requests can be executed in
parallel over a single cipher handle (according to [2]), I need to
have a separate underlying cipher handle for each AEAD request.
Now this is a problem, because aead_request has no init/destroy
mechanism where I could allocate/free the cipher handle, which means I
would have to do this inside the encrypt/decrypt function. AFAIK,
allocating with GFP_KERNEL inside encrypt/decrypt functions is
problematic, as they may be called from an atomic context.
Besides, it seems that also the crypto_*_setkey functions are not
guaranteed to be atomic [3], and I will need to call such function
either way... OTOH, the CTR mode/AES driver should not really need to
allocate any memory there, so this may be tolerable...
Does anyone have any ideas how to deal with this?
BTW, for justification of deriving the key from the nonce see section
9 of [1]. I don't really like the design decision, but there seems to
be no better way to achieve the same property...
Thanks,
Ondrej Mosnáček
[1] https://tools.ietf.org/html/draft-irtf-cfrg-gcmsiv-01
[2] https://www.kernel.org/doc/htmldocs/crypto-API/ch05s03.html
[3] https://www.spinics.net/lists/linux-crypto/msg17733.html
Am Dienstag, 5. Juli 2016, 13:44:05 schrieb Ondrej Mosnáček:
Hi Ondrej,
> Hi,
>
> I'm trying to experimentally implement the GCM-SIV AEAD algorithm from
> [1] for the Linux crypto API and I've ran into a problem...
>
> Basically, the encryption/decryption process starts by deriving a
> so-called "record-encryption key" from the nonce (by encrypting it
> using another key) and this key is then used to encrypt the plaintext
> in CTR mode and to encrypt the final authentication tag (otherwise it
> works similarly to GCM).
I have not yet looked into [1], but it sounds like a specific GCM case, just
like RFC4106 formatting.
Did you consider the structure discussion in [4] and add a specific handler
like the rfc4106() handler on top of GCM?
[4] https://www.kernel.org/doc/htmldocs/crypto-API/ch02s07.html
>
> Since the API is asynchronous and multiple requests can be executed in
> parallel over a single cipher handle (according to [2]), I need to
> have a separate underlying cipher handle for each AEAD request.
>
> Now this is a problem, because aead_request has no init/destroy
> mechanism where I could allocate/free the cipher handle, which means I
> would have to do this inside the encrypt/decrypt function. AFAIK,
> allocating with GFP_KERNEL inside encrypt/decrypt functions is
> problematic, as they may be called from an atomic context.
>
> Besides, it seems that also the crypto_*_setkey functions are not
> guaranteed to be atomic [3], and I will need to call such function
> either way... OTOH, the CTR mode/AES driver should not really need to
> allocate any memory there, so this may be tolerable...
>
> Does anyone have any ideas how to deal with this?
>
> BTW, for justification of deriving the key from the nonce see section
> 9 of [1]. I don't really like the design decision, but there seems to
> be no better way to achieve the same property...
>
> Thanks,
> Ondrej Mosnáček
>
> [1] https://tools.ietf.org/html/draft-irtf-cfrg-gcmsiv-01
> [2] https://www.kernel.org/doc/htmldocs/crypto-API/ch05s03.html
> [3] https://www.spinics.net/lists/linux-crypto/msg17733.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Ciao
Stephan
Ondrej Mosnáček <[email protected]> wrote:
> Hi,
>
> I'm trying to experimentally implement the GCM-SIV AEAD algorithm from
> [1] for the Linux crypto API and I've ran into a problem...
>
> Basically, the encryption/decryption process starts by deriving a
> so-called "record-encryption key" from the nonce (by encrypting it
> using another key) and this key is then used to encrypt the plaintext
> in CTR mode and to encrypt the final authentication tag (otherwise it
> works similarly to GCM).
>
> Since the API is asynchronous and multiple requests can be executed in
> parallel over a single cipher handle (according to [2]), I need to
> have a separate underlying cipher handle for each AEAD request.
>
> Now this is a problem, because aead_request has no init/destroy
> mechanism where I could allocate/free the cipher handle, which means I
> would have to do this inside the encrypt/decrypt function. AFAIK,
> allocating with GFP_KERNEL inside encrypt/decrypt functions is
> problematic, as they may be called from an atomic context.
>
> Besides, it seems that also the crypto_*_setkey functions are not
> guaranteed to be atomic [3], and I will need to call such function
> either way... OTOH, the CTR mode/AES driver should not really need to
> allocate any memory there, so this may be tolerable...
>
> Does anyone have any ideas how to deal with this?
Well you're pretty much screwed as far as performance is concerned.
So just postpone all processing to process context and allocate a new
tfm for each request.
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Hi Stephan,
2016-07-05 18:11 GMT+02:00, Stephan Mueller <[email protected]>:
> Am Dienstag, 5. Juli 2016, 13:44:05 schrieb Ondrej Mosnáček:
>
> Hi Ondrej,
>
>> Hi,
>>
>> I'm trying to experimentally implement the GCM-SIV AEAD algorithm from
>> [1] for the Linux crypto API and I've ran into a problem...
>>
>> Basically, the encryption/decryption process starts by deriving a
>> so-called "record-encryption key" from the nonce (by encrypting it
>> using another key) and this key is then used to encrypt the plaintext
>> in CTR mode and to encrypt the final authentication tag (otherwise it
>> works similarly to GCM).
>
> I have not yet looked into [1], but it sounds like a specific GCM case, just
>
> like RFC4106 formatting.
>
> Did you consider the structure discussion in [4] and add a specific handler
>
> like the rfc4106() handler on top of GCM?
>
> [4] https://www.kernel.org/doc/htmldocs/crypto-API/ch02s07.html
Yes, if it were possible, I would certainly do it in such way :)
Unfortunately, this wouldn't work, since there are some significant
differences. For example, in GCM the initial counter block for CTR
encryption is derived directly from the nonce, while in GCM-SIV the
authentication tag is used as the ICB (with MSB set to 1).
Actually, it seems the authors tried to be clever and changed the bit
order to big endian (in gf128mul's terms it uses ble ordering instead
of lle), so even GHASH (here called POLYVAL) may need to be
reimplemented :/
Cheers,
Ondrej
>>
>> Since the API is asynchronous and multiple requests can be executed in
>> parallel over a single cipher handle (according to [2]), I need to
>> have a separate underlying cipher handle for each AEAD request.
>>
>> Now this is a problem, because aead_request has no init/destroy
>> mechanism where I could allocate/free the cipher handle, which means I
>> would have to do this inside the encrypt/decrypt function. AFAIK,
>> allocating with GFP_KERNEL inside encrypt/decrypt functions is
>> problematic, as they may be called from an atomic context.
>>
>> Besides, it seems that also the crypto_*_setkey functions are not
>> guaranteed to be atomic [3], and I will need to call such function
>> either way... OTOH, the CTR mode/AES driver should not really need to
>> allocate any memory there, so this may be tolerable...
>>
>> Does anyone have any ideas how to deal with this?
>>
>> BTW, for justification of deriving the key from the nonce see section
>> 9 of [1]. I don't really like the design decision, but there seems to
>> be no better way to achieve the same property...
>>
>> Thanks,
>> Ondrej Mosnáček
>>
>> [1] https://tools.ietf.org/html/draft-irtf-cfrg-gcmsiv-01
>> [2] https://www.kernel.org/doc/htmldocs/crypto-API/ch05s03.html
>> [3] https://www.spinics.net/lists/linux-crypto/msg17733.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-crypto"
>> in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> Ciao
> Stephan
>
2016-07-06 8:31 GMT+02:00, Herbert Xu <[email protected]>:
> Well you're pretty much screwed as far as performance is concerned.
> So just postpone all processing to process context and allocate a new
> tfm for each request.
Yeah, I guess that's the only way then...
Thanks,
Ondrej
>
> Cheers,
> --
> Email: Herbert Xu <[email protected]>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>