| Message ID | 20211026075626.61975-1-tianjia.zhang@linux.alibaba.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | use SM3 instead of SM3_256 | expand |
On Tue, 26 Oct 2021 at 09:56, Tianjia Zhang <tianjia.zhang@linux.alibaba.com> wrote: > > According to https://tools.ietf.org/id/draft-oscca-cfrg-sm3-01.html, > SM3 always produces a 256-bit hash value and there are no plans for > other length development, so there is no ambiguity in the name of sm3. > What is the point of these changes? Having '256' in the identifiers is merely redundant and not factually incorrect, so why can't we just leave these as they are? > --- > v3 changes: > - The fix of document trusted-encrypted.rst is put in patch 2 > > v2 changes: > - an additional macro with the same value is defined for uapi instead > of renaming directly > > Tianjia Zhang (2): > crypto: use SM3 instead of SM3_256 > tpm: use SM3 instead of SM3_256 > > Documentation/security/keys/trusted-encrypted.rst | 2 +- > crypto/hash_info.c | 4 ++-- > drivers/char/tpm/tpm-sysfs.c | 4 ++-- > drivers/char/tpm/tpm2-cmd.c | 2 +- > include/crypto/hash_info.h | 2 +- > include/linux/tpm.h | 2 +- > include/uapi/linux/hash_info.h | 3 ++- > security/keys/trusted-keys/trusted_tpm2.c | 2 +- > 8 files changed, 11 insertions(+), 10 deletions(-) > > -- > 2.19.1.3.ge56e4f7 >
On Tue, 2021-10-26 at 18:08 +0200, Ard Biesheuvel wrote: > On Tue, 26 Oct 2021 at 09:56, Tianjia Zhang > <tianjia.zhang@linux.alibaba.com> wrote: > > According to https://tools.ietf.org/id/draft-oscca-cfrg-sm3-01.html > > , > > SM3 always produces a 256-bit hash value and there are no plans for > > other length development, so there is no ambiguity in the name of > > sm3. > > > > What is the point of these changes? Having '256' in the identifiers > is merely redundant and not factually incorrect, so why can't we just > leave these as they are? Me too on this. Plus the various standards bodies we follow are still using the 256 suffix and it's not clear they'll change. Finally, I'm not sure, given the confusion over sha256 and sha3-256, that the IETF won't eventually decide that all hash algorithms should be designated by <algorithm>-<bitlength> in which case this will get churned again ... James
On 10/27/21 12:08 AM, Ard Biesheuvel wrote: > On Tue, 26 Oct 2021 at 09:56, Tianjia Zhang > <tianjia.zhang@linux.alibaba.com> wrote: >> >> According to https://tools.ietf.org/id/draft-oscca-cfrg-sm3-01.html, >> SM3 always produces a 256-bit hash value and there are no plans for >> other length development, so there is no ambiguity in the name of sm3. >> > > What is the point of these changes? Having '256' in the identifiers is > merely redundant and not factually incorrect, so why can't we just > leave these as they are? > Sorry for the late reply. This is just to fix the ambiguity that may be caused by the macro name. It seems that there is no need to modify it. Please ignore this patch. Kind regards, Tianjia