| Message ID | 20200207092219.115056-2-tianjia.zhang@linux.alibaba.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/2] crypto: sm3 - add a new alias name sm3-256 | expand |
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
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?
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
> -----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&data=01%7C01%7Cpvanleeuwen%40verimatrix.com%7C3a51d0c133dd4b00fd9a08d7ae47d6d6%7Cdcb260f9022d449586 > 02eae51035a0d0%7C0&sdata=0nQ6tWMdVR5uB0MTCgdMXiOmkvTvGEKDTLcMXdzyZpg%3D&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&data=01%7C01%7Cpvanleeuwen%40verimatrix.com%7C3a51d0c133dd4b00fd9a08d7ae47d6d6%7Cdcb260f9022d44958602 > eae51035a0d0%7C0&sdata=9pfgM0bG%2Bp0zUavsknwn9vquWqPsqzPENV2okmgCOqE%3D&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>
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&data=01%7C01%7Cpvanleeuwen%40verimatrix.com%7C3a51d0c133dd4b00fd9a08d7ae47d6d6%7Cdcb260f9022d449586 > > 02eae51035a0d0%7C0&sdata=0nQ6tWMdVR5uB0MTCgdMXiOmkvTvGEKDTLcMXdzyZpg%3D&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&data=01%7C01%7Cpvanleeuwen%40verimatrix.com%7C3a51d0c133dd4b00fd9a08d7ae47d6d6%7Cdcb260f9022d44958602 > > eae51035a0d0%7C0&sdata=9pfgM0bG%2Bp0zUavsknwn9vquWqPsqzPENV2okmgCOqE%3D&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
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?
[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
> -----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>
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");
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(-)