[PATCH] IMA hash algorithm supports sm3-256

[PATCH] IMA hash algorithm supports sm3-256

[Tianjia Zhang]

The algorithm name sm3-256 referenced by IMA is implemented in crypto as sm3,
which causes IMA to not use sm3-256 algorithm. This patch solves this problem
by adding an alias name sm3-256 to sm3 algorithm, and let IMA hash algorithm
configuration list supports sm3.

[PATCH 1/2] crypto: sm3 - add a new alias name sm3-256

[Tianjia Zhang]

The name sm3-256 is defined in hash_algo_name in hash_info, but the
algorithm name implemented in sm3_generic.c is sm3, which will cause
the sm3-256 algorithm to be not found in some application scenarios of
the hash algorithm, and an ENOENT error will occur. For example,
IMA, keys, and other subsystems that reference hash_algo_name cannot use
the hash algorithm of sm3. This patch adds an alias name sm3-256 to sm3,
which can better solve the above problems.

Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
---
 crypto/sm3_generic.c | 21 +++++++++++++++++----
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/crypto/sm3_generic.c b/crypto/sm3_generic.c
index 3468975215ca..ded41031bd5f 100644
--- a/crypto/sm3_generic.c
+++ b/crypto/sm3_generic.c
@@ -163,7 +163,7 @@ int crypto_sm3_finup(struct shash_desc *desc, const u8 *data,
 }
 EXPORT_SYMBOL(crypto_sm3_finup);
 
-static struct shash_alg sm3_alg = {
+static struct shash_alg sm3_algs[2] = { {
 	.digestsize	=	SM3_DIGEST_SIZE,
 	.init		=	sm3_base_init,
 	.update		=	crypto_sm3_update,
@@ -176,16 +176,28 @@ static struct shash_alg sm3_alg = {
 		.cra_blocksize	 =	SM3_BLOCK_SIZE,
 		.cra_module	 =	THIS_MODULE,
 	}
-};
+}, {
+	.digestsize	=	SM3_DIGEST_SIZE,
+	.init		=	sm3_base_init,
+	.update		=	crypto_sm3_update,
+	.final		=	sm3_final,
+	.finup		=	crypto_sm3_finup,
+	.descsize	=	sizeof(struct sm3_state),
+	.base		=	{
+		.cra_name	 =	"sm3-256",
+		.cra_blocksize	 =	SM3_BLOCK_SIZE,
+		.cra_module	 =	THIS_MODULE,
+	}
+} };
 
 static int __init sm3_generic_mod_init(void)
 {
-	return crypto_register_shash(&sm3_alg);
+	return crypto_register_shashes(sm3_algs, ARRAY_SIZE(sm3_algs));
 }
 
 static void __exit sm3_generic_mod_fini(void)
 {
-	crypto_unregister_shash(&sm3_alg);
+	crypto_unregister_shashes(sm3_algs, ARRAY_SIZE(sm3_algs));
 }
 
 subsys_initcall(sm3_generic_mod_init);
@@ -196,3 +208,4 @@ MODULE_DESCRIPTION("SM3 Secure Hash Algorithm");
 
 MODULE_ALIAS_CRYPTO("sm3");
 MODULE_ALIAS_CRYPTO("sm3-generic");
+MODULE_ALIAS_CRYPTO("sm3-256");
-- 
2.17.1

Re: [PATCH 1/2] crypto: sm3 - add a new alias name sm3-256

[Eric Biggers]

On Fri, Feb 07, 2020 at 05:22:18PM +0800, Tianjia Zhang wrote:
> The name sm3-256 is defined in hash_algo_name in hash_info, but the
> algorithm name implemented in sm3_generic.c is sm3, which will cause
> the sm3-256 algorithm to be not found in some application scenarios of
> the hash algorithm, and an ENOENT error will occur. For example,
> IMA, keys, and other subsystems that reference hash_algo_name cannot use
> the hash algorithm of sm3. This patch adds an alias name sm3-256 to sm3,
> which can better solve the above problems.
> 
> Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
> ---
>  crypto/sm3_generic.c | 21 +++++++++++++++++----
>  1 file changed, 17 insertions(+), 4 deletions(-)
> 
> diff --git a/crypto/sm3_generic.c b/crypto/sm3_generic.c
> index 3468975215ca..ded41031bd5f 100644
> --- a/crypto/sm3_generic.c
> +++ b/crypto/sm3_generic.c
> @@ -163,7 +163,7 @@ int crypto_sm3_finup(struct shash_desc *desc, const u8 *data,
>  }
>  EXPORT_SYMBOL(crypto_sm3_finup);
>  
> -static struct shash_alg sm3_alg = {
> +static struct shash_alg sm3_algs[2] = { {
>  	.digestsize	=	SM3_DIGEST_SIZE,
>  	.init		=	sm3_base_init,
>  	.update		=	crypto_sm3_update,
> @@ -176,16 +176,28 @@ static struct shash_alg sm3_alg = {
>  		.cra_blocksize	 =	SM3_BLOCK_SIZE,
>  		.cra_module	 =	THIS_MODULE,
>  	}
> -};
> +}, {
> +	.digestsize	=	SM3_DIGEST_SIZE,
> +	.init		=	sm3_base_init,
> +	.update		=	crypto_sm3_update,
> +	.final		=	sm3_final,
> +	.finup		=	crypto_sm3_finup,
> +	.descsize	=	sizeof(struct sm3_state),
> +	.base		=	{
> +		.cra_name	 =	"sm3-256",
> +		.cra_blocksize	 =	SM3_BLOCK_SIZE,
> +		.cra_module	 =	THIS_MODULE,
> +	}
> +} };

According to https://tools.ietf.org/id/draft-oscca-cfrg-sm3-01.html,
SM3 always produces a 256-bit hash value.  E.g., it says:

	"SM3 produces an output hash value of 256 bits long"

and

	"SM3 is a hash function that generates a 256-bit hash value."

I don't see any mention of "SM3-256".

So why not just keep it as "sm3" and change hash_info.c instead?
Since the name there is currently wrong, no one can be using it yet.

- Eric

回复：[PATCH 1/2] crypto: sm3 - add a new alias name sm3-256

[Tianjia Zhang]

It is also a good idea to change "sm3-256" to "sm3" in hash_info, I will submit a new patch to fix this problem.

Re: [PATCH 1/2] crypto: sm3 - add a new alias name sm3-256

[Ken Goldman]

On 2/9/2020 10:17 PM, Eric Biggers wrote:
> According to https://tools.ietf.org/id/draft-oscca-cfrg-sm3-01.html,
> SM3 always produces a 256-bit hash value.  E.g., it says:
> 
> 	"SM3 produces an output hash value of 256 bits long"
> 
> and
> 
> 	"SM3 is a hash function that generates a 256-bit hash value."
> 
> I don't see any mention of "SM3-256".
> 
> So why not just keep it as "sm3" and change hash_info.c instead?
> Since the name there is currently wrong, no one can be using it yet.

Question:  Is 256 bits fundamental to SM3?  Could there ever be a 
variant in the future that's e.g., 512 bits?

Re: [PATCH 1/2] crypto: sm3 - add a new alias name sm3-256

[James Bottomley]

On Mon, 2020-02-10 at 11:30 -0500, Ken Goldman wrote:
> On 2/9/2020 10:17 PM, Eric Biggers wrote:
> > According to https://tools.ietf.org/id/draft-oscca-cfrg-sm3-01.html
> > ,
> > SM3 always produces a 256-bit hash value.  E.g., it says:
> > 
> > 	"SM3 produces an output hash value of 256 bits long"
> > 
> > and
> > 
> > 	"SM3 is a hash function that generates a 256-bit hash value."
> > 
> > I don't see any mention of "SM3-256".
> > 
> > So why not just keep it as "sm3" and change hash_info.c instead?
> > Since the name there is currently wrong, no one can be using it
> > yet.
> 
> Question:  Is 256 bits fundamental to SM3?

No.

>   Could there ever be a 
> variant in the future that's e.g., 512 bits?

Yes, SM3 like SHA-3 is based on a 512  bit input blocks.  However,
what's left of the standard:

https://www.ietf.org/archive/id/draft-sca-cfrg-sm3-02.txt

Currently only defines a 256 output (via compression from the final 512
bit output).  In theory, like SHA-3, SM3 could support 384 and 512
output variants.  However, there's no evidence anyone is working on
adding this.

James

RE: [PATCH 1/2] crypto: sm3 - add a new alias name sm3-256

[Van Leeuwen, Pascal]

> -----Original Message-----
> From: linux-crypto-owner@vger.kernel.org <linux-crypto-owner@vger.kernel.org> On Behalf Of James Bottomley
> Sent: Monday, February 10, 2020 5:40 PM
> To: Ken Goldman <kgold@linux.ibm.com>; Eric Biggers <ebiggers@kernel.org>; Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
> Cc: herbert@gondor.apana.org.au; davem@davemloft.net; zohar@linux.ibm.com; dmitry.kasatkin@gmail.com; jmorris@namei.org;
> serge@hallyn.com; linux-crypto@vger.kernel.org; linux-integrity@vger.kernel.org; linux-security-module@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH 1/2] crypto: sm3 - add a new alias name sm3-256
>
> <<< External Email >>>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the
> sender/sender address and know the content is safe.
>
>
> On Mon, 2020-02-10 at 11:30 -0500, Ken Goldman wrote:
> > On 2/9/2020 10:17 PM, Eric Biggers wrote:
> > > According to https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fid%2Fdraft-oscca-cfrg-sm3-
> 01.html&amp;data=01%7C01%7Cpvanleeuwen%40verimatrix.com%7C3a51d0c133dd4b00fd9a08d7ae47d6d6%7Cdcb260f9022d449586
> 02eae51035a0d0%7C0&amp;sdata=0nQ6tWMdVR5uB0MTCgdMXiOmkvTvGEKDTLcMXdzyZpg%3D&amp;reserved=0
> > > ,
> > > SM3 always produces a 256-bit hash value.  E.g., it says:
> > >
> > >     "SM3 produces an output hash value of 256 bits long"
> > >
> > > and
> > >
> > >     "SM3 is a hash function that generates a 256-bit hash value."
> > >
> > > I don't see any mention of "SM3-256".
> > >
> > > So why not just keep it as "sm3" and change hash_info.c instead?
> > > Since the name there is currently wrong, no one can be using it
> > > yet.
> >
> > Question:  Is 256 bits fundamental to SM3?
>
> No.
>
Well, the current specification surely doesn't define anything else and is
already over a decade old. So what would be the odds that they add a
different blocksize variant _now_ AND still call that SM3-something?

> >   Could there ever be a
> > variant in the future that's e.g., 512 bits?
>
> Yes, SM3 like SHA-3 is based on a 512  bit input blocks.  However,
> what's left of the standard:
>
SM3 is based on 512 bit input blocks, like _SHA-2_.
The SHA-3 variants use block sizes between 576 and 1152 bits,
depending on the output (digest) size.

The -xxx is referring to output (digest) size, not block size by the way.
And SHA-3 is indeed defined for 512 bit output size, amongst others.

> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-sca-cfrg-sm3-
> 02.txt&amp;data=01%7C01%7Cpvanleeuwen%40verimatrix.com%7C3a51d0c133dd4b00fd9a08d7ae47d6d6%7Cdcb260f9022d44958602
> eae51035a0d0%7C0&amp;sdata=9pfgM0bG%2Bp0zUavsknwn9vquWqPsqzPENV2okmgCOqE%3D&amp;reserved=0
>
> Currently only defines a 256 output (via compression from the final 512
> bit output).
>
Yes. Although that is not the original (Chinese) specification.

> In theory, like SHA-3, SM3 could support 384 and 512
> output variants.  However, there's no evidence anyone is working on
> adding this.
>
Hmm ... not without changing the word width (as for SHA-512) and/or
increasing the number of rounds plus other tweaking, I would say.
It's not as straightforward as you are suggesting (crypto rarely is).
I would even go as far as saying that is highly unlikely to happen.

Regards,
Pascal van Leeuwen
Silicon IP Architect Multi-Protocol Engines, Rambus Security
Rambus ROTW Holding BV
+31-73 6581953

Note: The Inside Secure/Verimatrix Silicon IP team was recently acquired by Rambus.
Please be so kind to update your e-mail address book with my new e-mail address.


** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **

Rambus Inc.<http://www.rambus.com>

Re: [PATCH 1/2] crypto: sm3 - add a new alias name sm3-256

[Mimi Zohar]

On Mon, 2020-02-10 at 17:01 +0000, Van Leeuwen, Pascal wrote:
> > -----Original Message-----
> > From: linux-crypto-owner@vger.kernel.org <linux-crypto-owner@vger.kernel.org> On Behalf Of James Bottomley
> > Sent: Monday, February 10, 2020 5:40 PM
> > To: Ken Goldman <kgold@linux.ibm.com>; Eric Biggers <ebiggers@kernel.org>; Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
> > Cc: herbert@gondor.apana.org.au; davem@davemloft.net; zohar@linux.ibm.com; dmitry.kasatkin@gmail.com; jmorris@namei.org;
> > serge@hallyn.com; linux-crypto@vger.kernel.org; linux-integrity@vger.kernel.org; linux-security-module@vger.kernel.org; linux-
> > kernel@vger.kernel.org
> > Subject: Re: [PATCH 1/2] crypto: sm3 - add a new alias name sm3-256
> >
> > <<< External Email >>>
> > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the
> > sender/sender address and know the content is safe.
> >
> >
> > On Mon, 2020-02-10 at 11:30 -0500, Ken Goldman wrote:
> > > On 2/9/2020 10:17 PM, Eric Biggers wrote:
> > > > According to https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fid%2Fdraft-oscca-cfrg-sm3-
> > 01.html&amp;data=01%7C01%7Cpvanleeuwen%40verimatrix.com%7C3a51d0c133dd4b00fd9a08d7ae47d6d6%7Cdcb260f9022d449586
> > 02eae51035a0d0%7C0&amp;sdata=0nQ6tWMdVR5uB0MTCgdMXiOmkvTvGEKDTLcMXdzyZpg%3D&amp;reserved=0
> > > > ,
> > > > SM3 always produces a 256-bit hash value.  E.g., it says:
> > > >
> > > >     "SM3 produces an output hash value of 256 bits long"
> > > >
> > > > and
> > > >
> > > >     "SM3 is a hash function that generates a 256-bit hash value."
> > > >
> > > > I don't see any mention of "SM3-256".
> > > >
> > > > So why not just keep it as "sm3" and change hash_info.c instead?
> > > > Since the name there is currently wrong, no one can be using it
> > > > yet.
> > >
> > > Question:  Is 256 bits fundamental to SM3?
> >
> > No.
> >
> Well, the current specification surely doesn't define anything else and is
> already over a decade old. So what would be the odds that they add a
> different blocksize variant _now_ AND still call that SM3-something?
> 
> > >   Could there ever be a
> > > variant in the future that's e.g., 512 bits?
> >
> > Yes, SM3 like SHA-3 is based on a 512  bit input blocks.  However,
> > what's left of the standard:
> >
> SM3 is based on 512 bit input blocks, like _SHA-2_.
> The SHA-3 variants use block sizes between 576 and 1152 bits,
> depending on the output (digest) size.
> 
> The -xxx is referring to output (digest) size, not block size by the way.
> And SHA-3 is indeed defined for 512 bit output size, amongst others.
> 
> > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-sca-cfrg-sm3-
> > 02.txt&amp;data=01%7C01%7Cpvanleeuwen%40verimatrix.com%7C3a51d0c133dd4b00fd9a08d7ae47d6d6%7Cdcb260f9022d44958602
> > eae51035a0d0%7C0&amp;sdata=9pfgM0bG%2Bp0zUavsknwn9vquWqPsqzPENV2okmgCOqE%3D&amp;reserved=0
> >
> > Currently only defines a 256 output (via compression from the final 512
> > bit output).
> >
> Yes. Although that is not the original (Chinese) specification.
> 
> > In theory, like SHA-3, SM3 could support 384 and 512
> > output variants.  However, there's no evidence anyone is working on
> > adding this.
> >
> Hmm ... not without changing the word width (as for SHA-512) and/or
> increasing the number of rounds plus other tweaking, I would say.
> It's not as straightforward as you are suggesting (crypto rarely is).
> I would even go as far as saying that is highly unlikely to happen.

So in terms of this discussion, does this mean you don't see a problem
with renaming "sm3-256" to "sm3" in crypto/hash_info.c?  If that's the
case, please add your Reviewed-by tag to the 1/2.

thanks,

Mimi

Re: [PATCH 1/2] crypto: sm3 - add a new alias name sm3-256

[Ken Goldman]

On 2/10/2020 12:01 PM, Van Leeuwen, Pascal wrote:
> Well, the current specification surely doesn't define anything else and is
> already over a decade old. So what would be the odds that they add a
> different blocksize variant_now_  AND still call that SM3-something?

I just got a note from a cryptographer who said there were discussions 
last year about a future SM3 with 512 bit output.

Given that, why not plan ahead and use sm3-256?  Is there any downside?
Is the cost any more than 4 bytes in some source code?

Re: [PATCH 1/2] crypto: sm3 - add a new alias name sm3-256

[Eric Biggers]

[Please fix your email client; you dropped all non-list recipients from Cc,
and I had to manually add them back...]

On Mon, Feb 10, 2020 at 01:02:42PM -0500, Ken Goldman wrote:
> On 2/10/2020 12:01 PM, Van Leeuwen, Pascal wrote:
> > Well, the current specification surely doesn't define anything else and is
> > already over a decade old. So what would be the odds that they add a
> > different blocksize variant_now_  AND still call that SM3-something?
> 
> I just got a note from a cryptographer who said there were discussions last
> year about a future SM3 with 512 bit output.
> 
> Given that, why not plan ahead and use sm3-256?  Is there any downside?
> Is the cost any more than 4 bytes in some source code?

If renaming sm3 to sm3-256 in the crypto API, no.  If adding sm3-256 alongside
sm3, then yes there is a cost to that because from the crypto API's perspective
they will be separate algorithms that each need to be registered, tested, etc.

- Eric

RE: [PATCH 1/2] crypto: sm3 - add a new alias name sm3-256

[Van Leeuwen, Pascal]

> -----Original Message-----
> From: linux-crypto-owner@vger.kernel.org <linux-crypto-owner@vger.kernel.org> On Behalf Of Ken Goldman
> Sent: Monday, February 10, 2020 7:03 PM
> Cc: linux-crypto@vger.kernel.org; linux-integrity@vger.kernel.org; linux-security-module@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH 1/2] crypto: sm3 - add a new alias name sm3-256
>
> <<< External Email >>>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the
> sender/sender address and know the content is safe.
>
>
> On 2/10/2020 12:01 PM, Van Leeuwen, Pascal wrote:
> > Well, the current specification surely doesn't define anything else and is
> > already over a decade old. So what would be the odds that they add a
> > different blocksize variant_now_  AND still call that SM3-something?
>
> I just got a note from a cryptographer who said there were discussions
> last year about a future SM3 with 512 bit output.
>
> Given that, why not plan ahead and use sm3-256?  Is there any downside?
> Is the cost any more than 4 bytes in some source code?
>

It is actually exported as "sm3" by all implementations, it's just this one reference that was off.
So fixing that one reference is less effort than fixing all implementations.
I don't think anyone cares about the 4 bytes of source code ...

As for SM3-512: that would by silly, considering recent attacks found against similar
Merkle-Darmgard structures.  Then again, I'm not talking to Chinese cryptographers.
In any case, what would be the problem with having "sm3" and "sm3-512"?
Note that nobody in the world refers to the current SM3 as "SM3-256".

Regards,
Pascal van Leeuwen
Silicon IP Architect Multi-Protocol Engines, Rambus Security
Rambus ROTW Holding BV
+31-73 6581953

Note: The Inside Secure/Verimatrix Silicon IP team was recently acquired by Rambus.
Please be so kind to update your e-mail address book with my new e-mail address.


** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **

Rambus Inc.<http://www.rambus.com>

[PATCH 2/2] ima: add sm3-256 algorithm to hash algorithm configuration list

[Tianjia Zhang]

sm3-256 has been supported by the ima hash algorithm, but it is not
yet in the Kconfig configuration list. After adding, both ima and tpm2
can support sm3-256 well.

Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
---
 security/integrity/ima/Kconfig | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
index 838476d780e5..27b5df895808 100644
--- a/security/integrity/ima/Kconfig
+++ b/security/integrity/ima/Kconfig
@@ -112,6 +112,10 @@ choice
 	config IMA_DEFAULT_HASH_WP512
 		bool "WP512"
 		depends on CRYPTO_WP512=y && !IMA_TEMPLATE
+
+	config IMA_DEFAULT_HASH_SM3_256
+		bool "SM3_256"
+		depends on CRYPTO_SM3=y && !IMA_TEMPLATE
 endchoice
 
 config IMA_DEFAULT_HASH
@@ -121,6 +125,7 @@ config IMA_DEFAULT_HASH
 	default "sha256" if IMA_DEFAULT_HASH_SHA256
 	default "sha512" if IMA_DEFAULT_HASH_SHA512
 	default "wp512" if IMA_DEFAULT_HASH_WP512
+	default "sm3-256" if IMA_DEFAULT_HASH_SM3_256
 
 config IMA_WRITE_POLICY
 	bool "Enable multiple writes to the IMA policy"
-- 
2.17.1