All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: David Miller <davem@davemloft.net>
Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
	herbert@gondor.apana.org.au
Subject: Re: [PATCH v0] Add SHA-3 hash algorithm
Date: Wed, 03 Oct 2012 02:53:27 -0400	[thread overview]
Message-ID: <506BE0E7.1070701@pobox.com> (raw)
In-Reply-To: <20121003.020619.772556428995851933.davem@davemloft.net>

On 10/03/2012 02:06 AM, David Miller wrote:
> From: Jeff Garzik <jeff@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

WARNING: multiple messages have this Message-ID (diff)
From: Jeff Garzik <jgarzik@pobox.com>
To: David Miller <davem@davemloft.net>
Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
	herbert@gondor.hengli.com.au
Subject: Re: [PATCH v0] Add SHA-3 hash algorithm
Date: Wed, 03 Oct 2012 02:53:27 -0400	[thread overview]
Message-ID: <506BE0E7.1070701@pobox.com> (raw)
In-Reply-To: <20121003.020619.772556428995851933.davem@davemloft.net>

On 10/03/2012 02:06 AM, David Miller wrote:
> From: Jeff Garzik <jeff@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




  reply	other threads:[~2012-10-03  6:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-03  5:45 [PATCH v0] Add SHA-3 hash algorithm Jeff Garzik
2012-10-03  5:45 ` Jeff Garzik
2012-10-03  6:06 ` David Miller
2012-10-03  6:06   ` David Miller
2012-10-03  6:53   ` Jeff Garzik [this message]
2012-10-03  6:53     ` Jeff Garzik
2012-10-03  7:11     ` Herbert Xu
2012-10-03  7:11       ` Herbert Xu
2012-10-03  7:17       ` Jeff Garzik
2012-10-03  7:17         ` Jeff Garzik
2013-04-04  0:29 ` Jeff Garzik
2013-04-04  0:29   ` Jeff Garzik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=506BE0E7.1070701@pobox.com \
    --to=jgarzik@pobox.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.