Closed deadcafe closed 7 years ago
Hi Deadcafe, Many thanks for your patch. I'll have a look into it soon.
In current shape of the code NULL_CIPHER and NULL_HASH can be used as follows: NULL_CIPHER usage: Order = HASH_CIPHER, Cipher = NULL_CIPHER, Direction = any
NULL_HASH usage: For ENCRYPT: Order = CIPHER_HASH, hash = NULL_HASH, Direction = ENCRYPT For DECRYPT: Order = HASH_CIPHER, hash = NULL_HASH, Direction = DECRYPT
I should have included the above in the documentation. I'll fix it soon. There are other software components using NULL CIPHER/HASH interface in the form above and if this is not something urgent/critical I wouldn't like to change it. Please let me know what you think.
Thanks, Tomasz
For the time being I have merged the commit regarding gcm_defines.h and precomp functions. Please provide more context on your NULL CIPHER usage and please check if the model described above would be enough. Thanks, Tomasz
Sorry for my late reply. It is understood that only the combination of NULL_CIPHER and NULL_HASH is acceptable. ORDER and DIRECTION are always equals relationship, right? So it is better to check them regardless of the algorithm. the tag_len is also so. Since NULL_CIPHER does not copy from SRC to DST, you should make sure that it is the same address.
#I deleted my branch by mistake, sorry.
Sorry for delay. Many thanks for the details. I'll have a second look into your patch wrt the check.
I was testing the is_job_invalid() patch in terms of functionality and performance - some comments to the original version:
Hi Tomasz, thank you for merging my request. This patch is intended to make NULL_CIPHER easier to use. NULL_CIPHER is very useful in product development. why not recommended to use NULL_CIPHER and NULL_HASH?
In addition, I have some suggestions. (1) separate the expanded_keys from gcm_data. (2) integrate GCM API into MB.
I like this library because it is very fast.