Re: [PATCH v0] Add SHA-3 hash algorithm
On 10/03/2012 01:45 AM, Jeff Garzik wrote: Whee -- SHA-3 is out! I wanted to explore the new toy a bit, and so, here is a blatantly untested rough draft of SHA-3 kernel support. Why rough draft? Because answers to the questions below will inform a more polished version. Just to update people... this has been in a holding pattern, because apparently there are revisions to SHA-3 coming down the pipe. They want to address preimage resistance, and make things faster in hardware. Random quote from NIST, on the NIST hash-forum, which doesn't provide detail but does summarize general feeling: "As best we can tell, continuing to pay that performance penalty for all future uses of SHA3 has no benefit. (All this is a longwinded way of saying: we were wrong, but hopefully we got better.)" Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v0] Add SHA-3 hash algorithm
On 10/03/2012 01:45 AM, Jeff Garzik wrote: Whee -- SHA-3 is out! I wanted to explore the new toy a bit, and so, here is a blatantly untested rough draft of SHA-3 kernel support. Why rough draft? Because answers to the questions below will inform a more polished version. Just to update people... this has been in a holding pattern, because apparently there are revisions to SHA-3 coming down the pipe. They want to address preimage resistance, and make things faster in hardware. Random quote from NIST, on the NIST hash-forum, which doesn't provide detail but does summarize general feeling: As best we can tell, continuing to pay that performance penalty for all future uses of SHA3 has no benefit. (All this is a longwinded way of saying: we were wrong, but hopefully we got better.) Jeff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v0] Add SHA-3 hash algorithm
On 10/03/2012 03:11 AM, Herbert Xu wrote: On Wed, Oct 03, 2012 at 02:53:27AM -0400, Jeff Garzik wrote: Maybe my patch is the best we can do in the current kernel, if dynamic digest size is not currently possible. Register "sha3_224", "sha3_256", ... as you describe, and wait for actual users to appear with unsupported digest sizes. Let's see what people use before we do anything more fancy. If the variants really start proliferating, we can add a template called "trunc" and then have things like "trunc(sha3,224)", etc. If they start proliferating, you really just want a single "sha3(n)", one single shash_alg registered at driver init time. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v0] Add SHA-3 hash algorithm
On Wed, Oct 03, 2012 at 02:53:27AM -0400, Jeff Garzik wrote: > > Maybe my patch is the best we can do in the current kernel, if > dynamic digest size is not currently possible. Register "sha3_224", > "sha3_256", ... as you describe, and wait for actual users to appear > with unsupported digest sizes. Let's see what people use before we do anything more fancy. If the variants really start proliferating, we can add a template called "trunc" and then have things like "trunc(sha3,224)", etc. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v0] Add SHA-3 hash algorithm
On 10/03/2012 02:06 AM, David Miller wrote: From: Jeff Garzik Date: Wed, 3 Oct 2012 01:45:42 -0400 1) tcrypt setup blatantly wrong. What is the best setup here? Define a separate entry for each digest length? Is there some special string descriptor format that is desired, like "sha3-256" or "sha3(256)"? Good question. The base name should probably be something without dashes. Maybe "sha3_256", but yeah "sha3256" would look rediculous. Well, the more basic question was... what to do when the digest length is easily variable, vis a vis kernel hash APIs? Keccak message digest size may fall anywhere within the range 8 bits - 1600 bits at runtime. You choose the digest size when you init the context. In contrast, the kernel interface appears to require a hardcoded size, chosen at driver compile time. My patch picks sizes found in common use, consistent with existing kernel practice. However, it is valid for another Keccak user to produce a 1600 bit hash, or a 1592 bit hash, or a 1584 bit hash, etc., etc. Maybe my patch is the best we can do in the current kernel, if dynamic digest size is not currently possible. Register "sha3_224", "sha3_256", ... as you describe, and wait for actual users to appear with unsupported digest sizes. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v0] Add SHA-3 hash algorithm
From: Jeff Garzik Date: Wed, 3 Oct 2012 01:45:42 -0400 > 1) tcrypt setup blatantly wrong. What is the best setup here? Define a > separate entry for each digest length? Is there some special string > descriptor format that is desired, like "sha3-256" or "sha3(256)"? Good question. The base name should probably be something without dashes. Maybe "sha3_256", but yeah "sha3256" would look rediculous. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v0] Add SHA-3 hash algorithm
From: Jeff Garzik j...@garzik.org Date: Wed, 3 Oct 2012 01:45:42 -0400 1) tcrypt setup blatantly wrong. What is the best setup here? Define a separate entry for each digest length? Is there some special string descriptor format that is desired, like sha3-256 or sha3(256)? Good question. The base name should probably be something without dashes. Maybe sha3_256, but yeah sha3256 would look rediculous. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v0] Add SHA-3 hash algorithm
On 10/03/2012 02:06 AM, David Miller wrote: From: Jeff Garzik j...@garzik.org Date: Wed, 3 Oct 2012 01:45:42 -0400 1) tcrypt setup blatantly wrong. What is the best setup here? Define a separate entry for each digest length? Is there some special string descriptor format that is desired, like sha3-256 or sha3(256)? Good question. The base name should probably be something without dashes. Maybe sha3_256, but yeah sha3256 would look rediculous. Well, the more basic question was... what to do when the digest length is easily variable, vis a vis kernel hash APIs? Keccak message digest size may fall anywhere within the range 8 bits - 1600 bits at runtime. You choose the digest size when you init the context. In contrast, the kernel interface appears to require a hardcoded size, chosen at driver compile time. My patch picks sizes found in common use, consistent with existing kernel practice. However, it is valid for another Keccak user to produce a 1600 bit hash, or a 1592 bit hash, or a 1584 bit hash, etc., etc. Maybe my patch is the best we can do in the current kernel, if dynamic digest size is not currently possible. Register sha3_224, sha3_256, ... as you describe, and wait for actual users to appear with unsupported digest sizes. Jeff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v0] Add SHA-3 hash algorithm
On Wed, Oct 03, 2012 at 02:53:27AM -0400, Jeff Garzik wrote: Maybe my patch is the best we can do in the current kernel, if dynamic digest size is not currently possible. Register sha3_224, sha3_256, ... as you describe, and wait for actual users to appear with unsupported digest sizes. Let's see what people use before we do anything more fancy. If the variants really start proliferating, we can add a template called trunc and then have things like trunc(sha3,224), etc. Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v0] Add SHA-3 hash algorithm
On 10/03/2012 03:11 AM, Herbert Xu wrote: On Wed, Oct 03, 2012 at 02:53:27AM -0400, Jeff Garzik wrote: Maybe my patch is the best we can do in the current kernel, if dynamic digest size is not currently possible. Register sha3_224, sha3_256, ... as you describe, and wait for actual users to appear with unsupported digest sizes. Let's see what people use before we do anything more fancy. If the variants really start proliferating, we can add a template called trunc and then have things like trunc(sha3,224), etc. If they start proliferating, you really just want a single sha3(n), one single shash_alg registered at driver init time. Jeff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
