mbox series

[0/2] tpm: use SM3 instead of SM3_256

Message ID 20211009130828.101396-1-tianjia.zhang@linux.alibaba.com (mailing list archive)
Headers show
Series tpm: use SM3 instead of SM3_256 | expand

Message

tianjia.zhang Oct. 9, 2021, 1:08 p.m. UTC
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.

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                    | 2 +-
 security/keys/trusted-keys/trusted_tpm2.c         | 2 +-
 8 files changed, 10 insertions(+), 10 deletions(-)

Comments

James Bottomley Oct. 9, 2021, 1:29 p.m. UTC | #1
On Sat, 2021-10-09 at 21:08 +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.

For the TPM we're following the TPM Library specification

https://trustedcomputinggroup.org/resource/tpm-library-specification/

Which is very clear: the algorithm name is TPM_ALG_SM3_256

We're using sm3 as our exposed name because that's what linux crypto
uses, so there should be no problem in what the end user sees, but
changing to non standard TPM definitions is only going to cause
confusion at the kernel level.

James
tianjia.zhang Oct. 11, 2021, 7:02 a.m. UTC | #2
Hi James,

On 10/9/21 9:29 PM, James Bottomley wrote:
> On Sat, 2021-10-09 at 21:08 +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.
> 
> For the TPM we're following the TPM Library specification
> 
> https://trustedcomputinggroup.org/resource/tpm-library-specification/
> 
> Which is very clear: the algorithm name is TPM_ALG_SM3_256
> 
> We're using sm3 as our exposed name because that's what linux crypto
> uses, so there should be no problem in what the end user sees, but
> changing to non standard TPM definitions is only going to cause
> confusion at the kernel level.
> 
> James
> 

Thanks for your attention. This is really tricky. I will contact 
trustedcomputinggroup first and give some suggestions, It would be best 
if a more standard algorithm name can be used from the source of the 
specification.

I think the macro definition of the crypto directory can remove this 
suffix first, that is, apply patch 1. What's your opinion?

Best regards,
Tianjia
Ken Goldman Oct. 19, 2021, 10:26 p.m. UTC | #3
On 10/11/2021 3:02 AM, Tianjia Zhang wrote:
> 
> Thanks for your attention. This is really tricky. I will contact trustedcomputinggroup first and give some suggestions, It would be best if a more standard algorithm name can be used from the source of the specification.

This was discussed in the TCG's TPM WG in February, 2020.  At the time,
someone said that there was a possibility of a 512-bit version in the
future.

For TCG members:

https://members.trustedcomputinggroup.org/wg/TPMWG/mail/thread/61442#136758

My guess is that, since it's already in many TCG specs and code, TCG
will want to leave it as is.
tianjia.zhang Oct. 20, 2021, 12:01 p.m. UTC | #4
Hi Ken,

On 10/20/21 6:26 AM, Ken Goldman wrote:
> 
> 
> 
> On 10/11/2021 3:02 AM, Tianjia Zhang wrote:
>>
>> Thanks for your attention. This is really tricky. I will contact 
>> trustedcomputinggroup first and give some suggestions, It would be 
>> best if a more standard algorithm name can be used from the source of 
>> the specification.
> 
> This was discussed in the TCG's TPM WG in February, 2020.  At the time,
> someone said that there was a possibility of a 512-bit version in the
> future.
> 
> For TCG members:
> 
> https://members.trustedcomputinggroup.org/wg/TPMWG/mail/thread/61442#136758
> 
> My guess is that, since it's already in many TCG specs and code, TCG
> will want to leave it as is.
> 

I got it. thanks for your information.

Best regards,
Tianjia