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.
---
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
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.
Signed-off-by: Tianjia Zhang <[email protected]>
---
Documentation/security/keys/trusted-encrypted.rst | 2 +-
drivers/char/tpm/tpm-sysfs.c | 4 ++--
drivers/char/tpm/tpm2-cmd.c | 2 +-
include/linux/tpm.h | 2 +-
security/keys/trusted-keys/trusted_tpm2.c | 2 +-
5 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/security/keys/trusted-encrypted.rst b/Documentation/security/keys/trusted-encrypted.rst
index 80d5a5af62a1..3292461517f6 100644
--- a/Documentation/security/keys/trusted-encrypted.rst
+++ b/Documentation/security/keys/trusted-encrypted.rst
@@ -162,7 +162,7 @@ Usage::
default 1 (resealing allowed)
hash= hash algorithm name as a string. For TPM 1.x the only
allowed value is sha1. For TPM 2.x the allowed values
- are sha1, sha256, sha384, sha512 and sm3-256.
+ are sha1, sha256, sha384, sha512 and sm3.
policydigest= digest for the authorization policy. must be calculated
with the same hash algorithm as specified by the 'hash='
option.
diff --git a/drivers/char/tpm/tpm-sysfs.c b/drivers/char/tpm/tpm-sysfs.c
index 63f03cfb8e6a..fe6c785dc84a 100644
--- a/drivers/char/tpm/tpm-sysfs.c
+++ b/drivers/char/tpm/tpm-sysfs.c
@@ -471,7 +471,7 @@ PCR_ATTR_BUILD(TPM_ALG_SHA1, sha1);
PCR_ATTR_BUILD(TPM_ALG_SHA256, sha256);
PCR_ATTR_BUILD(TPM_ALG_SHA384, sha384);
PCR_ATTR_BUILD(TPM_ALG_SHA512, sha512);
-PCR_ATTR_BUILD(TPM_ALG_SM3_256, sm3);
+PCR_ATTR_BUILD(TPM_ALG_SM3, sm3);
void tpm_sysfs_add_device(struct tpm_chip *chip)
@@ -500,7 +500,7 @@ void tpm_sysfs_add_device(struct tpm_chip *chip)
case TPM_ALG_SHA512:
chip->groups[chip->groups_cnt++] = &pcr_group_sha512;
break;
- case TPM_ALG_SM3_256:
+ case TPM_ALG_SM3:
chip->groups[chip->groups_cnt++] = &pcr_group_sm3;
break;
default:
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index 20f55de9d87b..d5a9410d2273 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -19,7 +19,7 @@ static struct tpm2_hash tpm2_hash_map[] = {
{HASH_ALGO_SHA256, TPM_ALG_SHA256},
{HASH_ALGO_SHA384, TPM_ALG_SHA384},
{HASH_ALGO_SHA512, TPM_ALG_SHA512},
- {HASH_ALGO_SM3, TPM_ALG_SM3_256},
+ {HASH_ALGO_SM3, TPM_ALG_SM3},
};
int tpm2_get_timeouts(struct tpm_chip *chip)
diff --git a/include/linux/tpm.h b/include/linux/tpm.h
index aa11fe323c56..56a79fee1250 100644
--- a/include/linux/tpm.h
+++ b/include/linux/tpm.h
@@ -40,7 +40,7 @@ enum tpm_algorithms {
TPM_ALG_SHA384 = 0x000C,
TPM_ALG_SHA512 = 0x000D,
TPM_ALG_NULL = 0x0010,
- TPM_ALG_SM3_256 = 0x0012,
+ TPM_ALG_SM3 = 0x0012,
};
/*
diff --git a/security/keys/trusted-keys/trusted_tpm2.c b/security/keys/trusted-keys/trusted_tpm2.c
index 52a696035176..b15a9961213d 100644
--- a/security/keys/trusted-keys/trusted_tpm2.c
+++ b/security/keys/trusted-keys/trusted_tpm2.c
@@ -23,7 +23,7 @@ static struct tpm2_hash tpm2_hash_map[] = {
{HASH_ALGO_SHA256, TPM_ALG_SHA256},
{HASH_ALGO_SHA384, TPM_ALG_SHA384},
{HASH_ALGO_SHA512, TPM_ALG_SHA512},
- {HASH_ALGO_SM3, TPM_ALG_SM3_256},
+ {HASH_ALGO_SM3, TPM_ALG_SM3},
};
static u32 tpm2key_oid[] = { 2, 23, 133, 10, 1, 5 };
--
2.19.1.3.ge56e4f7
On Tue, 26 Oct 2021 at 09:56, Tianjia Zhang
<[email protected]> 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 15:56 +0800, Tianjia Zhang 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.
Please just drop this piece.
[...]
> hash= hash algorithm name as a string. For TPM 1.x
> the only
> allowed value is sha1. For TPM 2.x the allowed
> values
> - are sha1, sha256, sha384, sha512 and sm3-256.
> + are sha1, sha256, sha384, sha512 and sm3.
the hash parameter is an external ABI we can't simply change ... as
Jarkko already told you.
The rest are constants defined in the TPM standard, which we shouldn't
change because then it makes everyone wonder why we're deviating.
James
On Tue, 2021-10-26 at 18:08 +0200, Ard Biesheuvel wrote:
> On Tue, 26 Oct 2021 at 09:56, Tianjia Zhang
> <[email protected]> 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
> <[email protected]> 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