Add GCM ciphers (AES/ARIA) to providers#9231
Conversation
|
The s390 AES_GCM support requires the z14 model, which I currently don't have access to. |
|
@p-steuer are you able to help on the S390 front? |
|
yes, ill look at it. |
p-steuer
left a comment
There was a problem hiding this comment.
With my non-question comments resolved, the code builds warning-free and passes openssl's test suite on z14.
|
Thanks @p-steuer for looking at this. I have updated the code, could you reconfirm that this updated code passes the tests & actually runs the kma code. |
Yes, i noticed it was still failing after my fixes but i already thought its unrelated.
Will do today. |
There was a problem hiding this comment.
This macro would only be used in the S390X_gcm_ivpadlen macro directly below plus padding is lcm(ivlen,16)+16 as S390X_gcm_ivpadlen does it, not just 16.
So id say keep the +16 instead of introducing a new macro (there is no predefined GHASH_BLOCK_SIZE macro).
|
Heres a diff of the proposed changes: |
|
With the proposed changes, test suite is passed (excuding params test) and kma instruction is used. perf tool report from |
Thankyou again @p-steuer. Your changes have been merged.. |
|
Now that the s390 is functional the WIP name has been removed. |
|
ok hopefully that fixes it.. If not I will get back to it tomorrow. |
providers/common/ciphers/aes_gcm.c
Outdated
There was a problem hiding this comment.
Shouldn't we confirm that ivlen == ctx->ivlen? Most importantly, if ivlen is less than ctx->ivlen then we could end up with an OOB read. I see the equivalent check does exist for the keylen, so it seems strange not to also do it for the IV.
There was a problem hiding this comment.
No: The way that this works is that it passes in the default length (which comes from EVP_CIPHER_CTX_iv_length() which is always 12 bytes
the ctx->ivlen can be set by the caller to anything that fits in the iv_buffer. It checks its size in set_params.
There was a problem hiding this comment.
See also the existing comment above the function
There was a problem hiding this comment.
The keylength however needs to be the default size
There was a problem hiding this comment.
Hmmm. Then something isn't right. The ivlen parameter comes from ivlen in aes_gcm_einit or aes_gcm_dinit. Which is intended to be the length of the IV actually passed. That at least is supposed to be the contract between libcrypto<->providers. Now, due to deficiencies with the APIs as they currently are, libcrypto has to figure out how long that IV is when it calls the provider which is I guess why its calling EVP_CIPHER_CTX_iv_length(). I imagine some future iteration of the API where an application passes an explicit length.
9593f7a to
0a205ff
Compare
|
ping @mattcaswell |
providers/common/ciphers/aes_gcm.c
Outdated
There was a problem hiding this comment.
Hmmm. Then something isn't right. The ivlen parameter comes from ivlen in aes_gcm_einit or aes_gcm_dinit. Which is intended to be the length of the IV actually passed. That at least is supposed to be the contract between libcrypto<->providers. Now, due to deficiencies with the APIs as they currently are, libcrypto has to figure out how long that IV is when it calls the provider which is I guess why its calling EVP_CIPHER_CTX_iv_length(). I imagine some future iteration of the API where an application passes an explicit length.
|
Just noticed s390 build is broken right now due to the missing gcm defines in aes_platform.h thing due to 459b15d . I thought it was previously broke due to this PR. So i think it would make sense to put the fix in a seperate commit and not hide it inside the other changes. |
|
From this API: And then this one really does the same thing... |
I was hoping this wouldnt take so long to get merged. Will add a seperate PR. |
The code has been modularized so that it can be shared by algorithms. A fixed size IV is now used instead of being allocated. The IV is not set into the low level struct now until the update (it uses an iv_state for this purpose). Hardware specific methods have been added to a PROV_GCM_HW object. The S390 code has been changed to just contain methods that can be accessed in a modular way. There are equivalent generic methods also for the other platforms.
|
ping |
|
|
||
| static void gcm_deinitctx(PROV_GCM_CTX *ctx) | ||
| { | ||
| OPENSSL_cleanse(ctx->iv, sizeof(ctx->iv)); |
There was a problem hiding this comment.
Isn't the IV public anyway? So why is this needed?
There was a problem hiding this comment.
I dont think it will hurt - this pattern is in a lot of places.
|
@mattcaswell updated to address the ivlength issue + iv gen can happen in non fips mode. |
mattcaswell
left a comment
There was a problem hiding this comment.
Approved subject to the naming nit being fixed.
The code has been modularized so that it can be shared by algorithms. A fixed size IV is now used instead of being allocated. The IV is not set into the low level struct now until the update (it uses an iv_state for this purpose). Hardware specific methods have been added to a PROV_GCM_HW object. The S390 code has been changed to just contain methods that can be accessed in a modular way. There are equivalent generic methods also for the other platforms. Reviewed-by: Matt Caswell <[email protected]> Reviewed-by: Patrick Steuer <[email protected]> (Merged from #9231)
|
Thanks.. Merged to master. |
Checklist