Re: [PATCH 0/3] crypto: marvell - Remove the old CESA driver

[Jason Cooper]

Hey Boris,

On Wed, Oct 11, 2017 at 03:16:16PM +0200, Boris Brezillon wrote:
> Hello,
> 
> It's been several releases since we added a new driver to support the
> CESA IP (the new driver was introduced in 4.2). It seems most major
> bugs have been discovered and fixed and now is probably a good time to
> kill the old driver and force remaining users to switch to the new one.
> 
> This series first add a platform_device_id table to the marvell CESA
> driver so that it can work on non-DT platforms. Then we patch all
> defconfigs to select the new driver instead of the old. And finally we
> remove the old driver.
> These patches have to be applied in this order to make things
> bisectable, so, if this series is accepted it will have to go through
> a single tree (either ARM or crypto).

Thanks for keeping this on your radar.  As I was the one who originally
requested this transitioning time,

Acked-by: Jason Cooper <ja...@lakedaemon.net>

For the series.

thx,

Jason.

Re: [PATCH 0/4] hwrng: omap - fixes and improvements

[Jason Cooper]

Hi Thomas,

On Tue, Mar 07, 2017 at 03:14:45PM +0100, Thomas Petazzoni wrote:
> Hello,
> 
> This small patch series brings a few fixes and improvements to the
> omap_rng driver. The first fix is particularly important, as it fixes
> using the driver built as a module on SoCs that require a clock for
> the IP to work properly.
> 
> Thanks,
> 
> Thomas
> 
> Thomas Petazzoni (4):
>   hwrng: omap - write registers after enabling the clock
>   hwrng: omap - use devm_clk_get() instead of of_clk_get()
>   hwrng: omap - Do not access INTMASK_REG on EIP76
>   hwrng: omap - move clock related code to omap_rng_probe()
> 
>  drivers/char/hw_random/omap-rng.c | 36 +---
>  1 file changed, 25 insertions(+), 11 deletions(-)

For the whole series,

Acked-by: Jason Cooper <ja...@lakedaemon.net>

thx,

Jason.

Re: [PATCH v3 6/8] hwrng: amd: Replace global variable with private struct

[Jason Cooper]

On Sat, Aug 27, 2016 at 02:43:31PM +, Jason Cooper wrote:
> Hi Corentin,
> 
> On Fri, Aug 26, 2016 at 01:11:34PM +0200, LABBE Corentin wrote:
> > Instead of having two global variable, it's better to use a
> > private struct. This will permit to remove amd_pdev variable
> > 
> > Signed-off-by: LABBE Corentin <clabbe.montj...@gmail.com>
> > ---
> >  drivers/char/hw_random/amd-rng.c | 57 
> > ++--
> >  1 file changed, 38 insertions(+), 19 deletions(-)
> > 
> > diff --git a/drivers/char/hw_random/amd-rng.c 
> > b/drivers/char/hw_random/amd-rng.c
> > index 383e197..4ef94e9 100644
> > --- a/drivers/char/hw_random/amd-rng.c
> > +++ b/drivers/char/hw_random/amd-rng.c
> > @@ -47,15 +47,18 @@ static const struct pci_device_id pci_tbl[] = {
> >  };
> >  MODULE_DEVICE_TABLE(pci, pci_tbl);
> >  
> > -static struct pci_dev *amd_pdev;
> > +struct amd768_priv {
> > +   struct pci_dev *pcidev;
> > +   u32 pmbase;
> > +};
> >  
> >  static int amd_rng_data_present(struct hwrng *rng, int wait)
> >  {
> > -   u32 pmbase = (u32)rng->priv;
> > +   struct amd768_priv *priv = (struct amd768_priv *)rng->priv;
> 
> Please remove unnecessary casts...

Hmm, I was assuming that, like other places in the tree, that priv was
declared void*.  However, it's unsigned long in hw_random.h.

And, it looks like all users cast it.  Either to a struct, or to a void
__iomem *.

So ignore what I said in my previous email.  You can add my reviewed-by
without change.

It does look like /priv/ s/unsigned long/void */ would be a great
cleanup.

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/8] hwrng: amd: rework of the amd hwrng driver

[Jason Cooper]

Hi Corentin,

On Fri, Aug 26, 2016 at 01:11:28PM +0200, LABBE Corentin wrote:
> Changes since v2:
>  - split the latest patch in 4
> Changes since v1:
>  - Keep the hwrng name as "amd"
> 
> LABBE Corentin (8):
>   hwrng: amd: Fix style problem with blank line
>   hwrng: amd: use the BIT macro
>   hwrng: amd: Be consitent with the driver name
>   hwrng: amd: Remove asm/io.h
>   hwrng: amd: release_region must be called after hwrng_unregister
>   hwrng: amd: Replace global variable with private struct
>   hwrng: amd: Access hardware via ioread32/iowrite32
>   hwrng: amd: Convert to new hwrng read() API
> 
>  drivers/char/hw_random/amd-rng.c | 150 
> +--
>  1 file changed, 96 insertions(+), 54 deletions(-)

Once you've fixed up the casting in #6, you can add my

Reviewed-by: Jason Cooper <ja...@lakedaemon.net>

to the series.

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 5/5] hwrng: amd: Rework of the amd768-hwrng driver

[Jason Cooper]

Hi Corentin,

On Fri, Aug 26, 2016 at 10:38:02AM +0200, LABBE Corentin wrote:
> On Thu, Aug 25, 2016 at 02:56:38PM +0000, Jason Cooper wrote:
> > On Thu, Aug 25, 2016 at 02:16:35PM +0200, LABBE Corentin wrote:
> > > This patch convert the hwrng interface used by amd768-rng to its new API
> > > by replacing data_read()/data_present() by read().
> > > 
> > > Furthermore, Instead of having two global variable, it's better to use a
> > > private struct. This will permit to remove amd_pdev variable.
> > > 
> > > Finally, Instead of accessing hw directly via pmbase, it's better to
> > > access after ioport_map() via ioread32/iowrite32.
> > 
> > I was going to recommend a better $subject line, but now I see why it's
> > vague. :(  I would recommend breaking this patch up into three:
> > 
> >   hwrng: amd - Access hardware via ioread32/iowrite32
> >   hwrng: amd - Replace global variable with private struct
> >   hwrng: amd - Convert to new hwrng read() API
> > 
> 
> That was my first idea, but believed that it wasnt worth it.

When working with crypto/rng code, I'm a firm believer in moving
cautiously and deliberately. :-)

> Anyway I will do it.

Thanks!

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 5/5] hwrng: amd: Rework of the amd768-hwrng driver

[Jason Cooper]

Hi Corentin,

On Thu, Aug 25, 2016 at 02:16:35PM +0200, LABBE Corentin wrote:
> This patch convert the hwrng interface used by amd768-rng to its new API
> by replacing data_read()/data_present() by read().
> 
> Furthermore, Instead of having two global variable, it's better to use a
> private struct. This will permit to remove amd_pdev variable.
> 
> Finally, Instead of accessing hw directly via pmbase, it's better to
> access after ioport_map() via ioread32/iowrite32.

I was going to recommend a better $subject line, but now I see why it's
vague. :(  I would recommend breaking this patch up into three:

  hwrng: amd - Access hardware via ioread32/iowrite32
  hwrng: amd - Replace global variable with private struct
  hwrng: amd - Convert to new hwrng read() API

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy

[Jason Cooper]

Hey Ted,

On Wed, Aug 10, 2016 at 07:44:25PM -0400, Theodore Ts'o wrote:
> On Tue, Aug 09, 2016 at 02:04:44PM +0000, Jason Cooper wrote:
> > iiuc, Ted, you're saying using the hw_random framework would be
> > disasterous because despite most drivers having a default quality of 0,
> > rngd assumes 1 bit of entropy for every bit read?
> 
> Sorry, what I was trying to say (but failed) was that bypassing the
> hwrng framework and injecting entropy directly the entropy pool was
> disatrous.

Ok, whew. :)

> > Thankfully, most hw_random drivers don't set the quality.  So unless the
> > user sets the default_quality param, it's zero.
> 
> The fact that this is "most" and not "all" does scare me a little.

My recent grep showed that only virtio-rng set it to a non-zero value.

> As far as I'm concerned *all* hw_random drivers should set quality to
> zero, since it should be up to the system administrator.

Agreed.

Gathering conversation about this from a few related threads, I have one
concern.  Apparently there is some confusion in userspace consumers of
/dev/hwrng data as to the quality of it.  Specifically, rngd (spotted by
Stephan Mueller) appears to assume 1bit of entropy per 1 bit read. :-/

So, while moving ath9k-rng to the hwrng framework makes complete sense
internally, it's not so good for existing userspace assumptions.  I'd
think that timeriomem-rng falls in this same category.

In light of this, do you think it's worth the effort (I'm volunteering)
to create a subcategory of hwrng drivers that are 'environemntal' rngs?
They can contribute to the kernel entropy pools, but not to /dev/hwrng.

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] ath9k: disable RNG by default

[Jason Cooper]

On Thu, Aug 11, 2016 at 10:54:11AM +0800, miaoq...@codeaurora.org wrote:
> On 2016-08-10 21:24, Jason Cooper wrote:
> >The fact is, barring userspace expectations of /dev/hwrng, hw_random is
> >the appropriate place for it.  It's not a devicetree blob, mac address,
> >or pci config space.  Which are things we feed in once for the heck of
> >it.  This is a *continuous* source or questionable quality.
> >
> >I'm seriously considering putting this and timeriomem-rng into a
> >subdirectory under hw_random/, maybe environ/.  Anything in there gets
> >quality=0 for default, and *doesn't* contribute to /dev/hwrng.
> >
> >Regardless which path we take, I think we should include 'adc' in the
> >name.  I've heard countless times about "Atheros cards come with an rng
> >on board". :-/
> 
> If I understand correctly, you want to bind the ADC source to
> /dev/hwrng, and then change rng-tools to set the entropy to zero in
> the ioctl call ?  There are two major problems with that approach,

Nope.  I want to leverage the hwrng framework to facilitate feeding the
*kernel* entropy pools like all the other hwrngs do currently.  The
difference for *environmental* sources is that when userspace read()s
from /dev/hwrng, they will *not* contribute.

If the environmental sources are the only sources, then no /dev/hwrng
should appear.

> 1) We already tried once before to bind our solution to /dev/hwrng,
> and got so much complaints. The conclusion was that maybe we know that
> the output of /dev/hwrng does not have perfect entropy, but a normal
> user does not know and will misuse it. You mentioned in
> https://www.kernel.org/doc/Documentation/hw_random.txt we have
> 
> "This data is NOT CHECKED by any
>   fitness tests, and could potentially be bogus (if the
>   hardware is faulty or has been tampered with).  Data is only
>   output if the hardware "has-data" flag is set, but nevertheless
>   a security-conscious person would run fitness tests on the
>   data before assuming it is truly random."
> 
> But this is not enough to convince upstream to switch to /dev/hwrng.
> I think the concern of users misusing the solution is a very valid
> concern.

Agreed.

> 2) If we set the entropy to zero in rng-tools, we cannot tolerate the
> load.  Rng-tools is not a timer-based solution. Similar to our
> solution, it is based on
> /proc/sys/kernel/random/write_wakeup_threshold. If we do not increase
> the entropy counter, rng-tools keep writing into the pool, and both
> rng-tools and WiFi chip will be overloaded.

That's why I propose a change to the hwrng framework to permit noise
sources while not wiring them up to feed /dev/hwrng.  timeriomem-rng
should have the same problem ath9k-rng does.

Basically, if it wasn't designed to be an rng, it shouldn't be wired up
to /dev/hwrng.

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] ath9k: disable RNG by default

[Jason Cooper]

Hi Miaoqing Pan, Stephen,

*gentle reminder: others are reading which may not be directly included
in the conversation.  Including the archives.  Please avoid top posting.
:)

On Wed, Aug 10, 2016 at 07:43:45AM +, Pan, Miaoqing wrote:
> The problem with using the add_device_randomness is that we do not
> know when to call that API, and we have to make our solution either
> timer-based or interrupt based, which is not really the correct way of
> implementing this feature.

Exactly.  I think we're dancing around the problem by discussing the
quality of what the ath9k adc provides.

The fact is, barring userspace expectations of /dev/hwrng, hw_random is
the appropriate place for it.  It's not a devicetree blob, mac address,
or pci config space.  Which are things we feed in once for the heck of
it.  This is a *continuous* source or questionable quality.

I'm seriously considering putting this and timeriomem-rng into a
subdirectory under hw_random/, maybe environ/.  Anything in there gets
quality=0 for default, and *doesn't* contribute to /dev/hwrng.

Regardless which path we take, I think we should include 'adc' in the
name.  I've heard countless times about "Atheros cards come with an rng
on board". :-/

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices

[Jason Cooper]

Hi Keith,

On Tue, Aug 09, 2016 at 10:58:05AM -0700, Keith Packard wrote:
> Jason Cooper <ja...@lakedaemon.net> writes:
> > Perhaps a /dev/hwrng[0-9] per rng?  That would lend itself nicely to a
> > sysfs interface for per device quality, rate, and enabled attributes.
> > e.g. /sys/class/hw_random/hwrng0/{device/,quality,rate,enabled}
> 
> I was interested in the data being provided for /dev/random; that seems
> like the most important interface to me.

Me too, agreed.

> But, exposing all of the devices using consistent names does seem like
> a useful idea at some level.

On another thread, regarding the ath9k-rng (actually just the adc
registers), Henrique asked about per-source knobs.  My suggestion
follows from that.

> > /dev/hwrng could pull from the one with the highest quality, or user
> > specified for backwards compatibility.
> 
> I like the notion of using all of them in turn; if one of them turns out
> to be broken, you're still stirring in data from the others. After all,
> the quality metric is provided by the device, we aren't doing any
> analysis on the data to determine it independently.

Sure, but /dev/hwrng is a user interface.  Typically to rngd, but not
necessarily.  We need to make sure it's behavior is consistent with
existing expectations.

We shouldn't attach first-probed to /dev/hwrng, because that may not be
what the user is expecting.  If I bought a raw entropy source, and knew
nothing of the proposed multi-source interfaces, I'd expect the USB
dongle to be attached to /dev/hwrng.  Despite the fact that my pcie wifi
card was probed first and has adc registers providing an entropy source.

I'm not sure how we ensure that.  Perhaps an 'environmental' flag in the
hw_random source attributes?  Or a 'not-designed-to-be-an-rng' flag? :)
Maybe those would be /dev/envrng[0-9]...

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] ath9k: disable RNG by default

[Jason Cooper]

Hi Henrique,

On Tue, Aug 09, 2016 at 07:24:58AM -0300, Henrique de Moraes Holschuh wrote:
> On Tue, 09 Aug 2016, Stephan Mueller wrote:
> > RHEL 7 and Fedora do not adjust it. So, shall we consider those rng-tools 
> > then 
> > broken (at least in those large distros)?
> 
> Might I humbly suggest that the kernel start providing some metatada
> about the quality of the random source that userspace can consume?
> Preferably by a new ioctl, so that it will fit naturally if we ever
> extend /dev/hwrng to support more than one source?
> 
> That would allow for auto tunning to be implemented in userspace...

See my reply to Keith Packard's proposed multi-device hw_random patch:

  https://lkml.kernel.org/r/20160809165710.gc2...@io.lakedaemon.net

and top of thread:

  https://lkml.kernel.org/r/1469477255-26824-1-git-send-email-kei...@keithp.com

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] ath9k: disable RNG by default

[Jason Cooper]

On Tue, Aug 09, 2016 at 03:02:27PM +0800, miaoq...@codeaurora.org wrote:
> From: Miaoqing Pan <miaoq...@codeaurora.org>
> 
> ath9k RNG will dominates all the noise sources from the real HW
> RNG, disable it by default. But we strongly recommand to enable
> it if the system without HW RNG, especially on embedded systems.
> 
> Signed-off-by: Miaoqing Pan <miaoq...@codeaurora.org>

Until we get the hw_random/get_device_randomness question sorted...

Reviewed-by: Jason Cooper <ja...@lakedaemon.net>

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices

[Jason Cooper]

Hi Keith, Herbert,

On Tue, Aug 09, 2016 at 05:50:58PM +0800, Herbert Xu wrote:
> On Mon, Jul 25, 2016 at 01:07:35PM -0700, Keith Packard wrote:
> > Instead of having only one hwrng feeding /dev/random at a time, maintain
> > a list of devices and cycle between them when filling the entropy pool.
> > 
> > Signed-off-by: Keith Packard 
> 
> So you're cycling RNGs even for user-space reads? That could be
> problematic because not all hardware RNGs carry the maximum amount
> of entropy.  It would be rather annoying to be cycling between
> RNGs of different qualities.
> 
> Perhaps only cycle for the kernel hwrngd?

Perhaps a /dev/hwrng[0-9] per rng?  That would lend itself nicely to a
sysfs interface for per device quality, rate, and enabled attributes.
e.g. /sys/class/hw_random/hwrng0/{device/,quality,rate,enabled}

/dev/hwrng could pull from the one with the highest quality, or user
specified for backwards compatibility.

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy

[Jason Cooper]

Hi Ted,

On Tue, Aug 09, 2016 at 07:56:22AM -0400, Theodore Ts'o wrote:
> On Tue, Aug 09, 2016 at 06:30:03AM +, Pan, Miaoqing wrote:
> > Agree with Jason's point, also understand Stephan's concern.  The
> > date rate can be roughly estimated by 'cat /dev/random |rngtest -c
> > 1000', the average speed is .294Kibits/s. I will sent the patch
> > to disable ath9k RNG by default.
> 
> If the ATH9K is generating some random amount of data, but you don't
> know how random, and you're gathering it opportunistically --- for
> example, suppose a wireless driver gets the radio's signal strength
> through the normal course of its operation, and while there might not
> be that much randomness for someone who can observe the exact details
> of how the phone is positioned in the room --- but for which the
> analyst sitting in Fort Meade won't know whether or not the phone is
> on the desk, or in a knapsack under the table, the right interface to
> use is:
> 
>void add_device_randomness(const void *buf, unsigned int size);
>   
> This won't increase the entropy count, but if you have the bit of
> potential randomness "for free", you might as well contribute it to
> the entropy pool.  If it turns out that the chip was manufactured in
> China, and the MSS has backdoored it out the wazoo, it won't do any
> harm --- where as using the hwrng framework would be disastrous.

Ok, I get that.  However, we have Documentation/hw_random.txt saying:

  This data is NOT CHECKED by any fitness tests, and could potentially be
  bogus (if the hardware is faulty or has been tampered with).  Data is
  only output if the hardware "has-data" flag is set, but nevertheless a
  security-conscious person would run fitness tests on the data before
  assuming it is truly random.

Which I would read as "Don't assume 1 bit read from /dev/hwrng equals 1
bit of entropy."  Which runs counter to Stephan's reading of the rngd
code.

And then we have drivers like timeriomem-rng.c that appear to be
spitting out the raw 32bit register value of $SOC's timer.

Thankfully, most hw_random drivers don't set the quality.  So unless the
user sets the default_quality param, it's zero.

iiuc, Ted, you're saying using the hw_random framework would be
disasterous because despite most drivers having a default quality of 0,
rngd assumes 1 bit of entropy for every bit read?

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy

[Jason Cooper]

Hi Stephan,

On Mon, Aug 08, 2016 at 05:29:30PM +, Jason Cooper wrote:
> On Mon, Aug 08, 2016 at 08:41:36AM +0200, Stephan Mueller wrote:
...
> > If you think that this patch is a challenge because your driver starts to 
> > spin, please help and offer another solution.
> 
> Well, I don't buy the reasoning listed above for not using the hwrng
> framework.  Interrupt timings were never designed to be a source of entropy
> either.  We need to grab it where ever we can find it, especially on
> embedded systems.  Documentation/hw_random.txt even says:
> 
> """
> This data is NOT CHECKED by any fitness tests, and could potentially be
> bogus (if the hardware is faulty or has been tampered with).
> """
> 
> I really don't think there's a problem with adding these sorts of
> sources under char/hw_random/.  I think the only thing we would be
> concerned about, other than the already addressed entropy estimation,
> would be constraining the data rate.

Further research yields char/hw_random/timeriomem-rng.c

It could use an update to ->read() vice data_{present,read}(), but it's
functionally exactly what the ath9k rng is doing. :)

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy

[Jason Cooper]

Hi Stephan, Miaoqing Pan,

On Mon, Aug 08, 2016 at 08:41:36AM +0200, Stephan Mueller wrote:
> Am Montag, 8. August 2016, 02:03:36 CEST schrieb Pan, Miaoqing:
> > The entropy was evaluated by crypto expert,  the analysis report show the
> > ADC with at least 10bits and up to 22 bits of min-entropy for a 32 bits
> > value, we conservatively assume the min-entropy is 10 bits out of 32 bits,
> > so that's why set entropy quality  to  320/1024 = 10/32.

Ok, so the relevant commit is:

  ed14dc0af7cce ath9k: feeding entropy in kernel from ADC capture

Which refers to a previous commit:

  6301566e0b2d ath9k: export HW random number generator

> > Also we have explained in the commit message why can't use the HW
> > RNG framework.

>From ed14dc0af7cce:

"""
Since ADC was not designed to be a dedicated HW RNG, we do not want to
bind it to /dev/hwrng framework directly.
"""

> Where is the description of the RNG, where is the test implementation? 
> > 
> > Otherwise, your patch will cause high CPU load,  as continuously read ADC
> > data if entropy bits under write_wakeup_threshold.
> 
> The issue is that although you may have analyzed it, others are unable to 
> measure the quality of the RNG and assess the design as well as the 
> implementation of the RNG. This RNG is the only implementation of a hardware 
> RNG that per default and without being able to change it at runtime injects 
> data into the input_pool where the noise source cannot be audited. Note, even 
> other respected RNG noise sources like the Intel RDRAND will not feed into /
> dev/random per default in a way that dominates all other noise sources.
> 
> I would like to be able to deactivate that noise source to the extent that it 
> does not cause /dev/random to unblock. The reason is that your noise source 
> starts to dominate all other noise sources.

I think the short-term problem here is the config logic:

config ATH9K_HWRNG
   bool "Random number generator support"
   depends on ATH9K && (HW_RANDOM = y || HW_RANDOM = ATH9K)
   default y

If you have *any* hwrngs you want to use and you have an ath9k card
(HW_RANDOM = y and ATH9K != n), you get the behavior Stephan is pointing
out.

Short term, we should just default no here.

> If you think that this patch is a challenge because your driver starts to 
> spin, please help and offer another solution.

Well, I don't buy the reasoning listed above for not using the hwrng
framework.  Interrupt timings were never designed to be a source of entropy
either.  We need to grab it where ever we can find it, especially on
embedded systems.  Documentation/hw_random.txt even says:

"""
This data is NOT CHECKED by any fitness tests, and could potentially be
bogus (if the hardware is faulty or has been tampered with).
"""

I really don't think there's a problem with adding these sorts of
sources under char/hw_random/.  I think the only thing we would be
concerned about, other than the already addressed entropy estimation,
would be constraining the data rate.

Is ath9k the only wireless card that exposes ADC registers?  What about
sound cards?

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC][PATCH] RANDOM: ATH9K RNG delivers zero bits of entropy

[Jason Cooper]

Hi Stephan,

On Sat, Aug 06, 2016 at 10:03:58PM +0200, Stephan Mueller wrote:
> Am Samstag, 6. August 2016, 19:45:51 CEST schrieb Jason Cooper:
> > On Fri, Aug 05, 2016 at 05:08:14PM +0200, Stephan Mueller wrote:
...
> > > diff --git a/drivers/net/wireless/ath/ath9k/rng.c
> > > b/drivers/net/wireless/ath/ath9k/rng.c index d38e50f..d63dc48 100644
> > > --- a/drivers/net/wireless/ath/ath9k/rng.c
> > > +++ b/drivers/net/wireless/ath/ath9k/rng.c
> > > @@ -92,8 +92,7 @@ static int ath9k_rng_kthread(void *data)
> > > 
> > >   fail_stats = 0;
> > >   
> > >   /* sleep until entropy bits under write_wakeup_threshold */
> > > 
> > > - add_hwgenerator_randomness((void *)rng_buf, bytes_read,
> > > -ATH9K_RNG_ENTROPY(bytes_read));
> > 
> > This is the only use of this macro.  I'd remove the #define on line 25
> > as well.
> 
> My idea for leaving it was that folks who would bring the RNG into the 
> hwrandom framework could reuse the ideas from the original authors.
> 
> What about commenting it out with #if 0 ?

#if 0 is frowned upon.  If that calculation is documented somewhere,
then it can be redone from the spec.  If it isn't, then I'd be curious
to know where it came from.

Perhaps one of the ath9k devs can point to a document containing the
formula?  We could put the reference in a comment.

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC][PATCH] RANDOM: ATH9K RNG delivers zero bits of entropy

[Jason Cooper]

Hi Stephan,

On Fri, Aug 05, 2016 at 05:08:14PM +0200, Stephan Mueller wrote:
> Hi Ted, Herbert,
> 
> I sent a question to the ATH9K RNG some time ago to the developers.
> See https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg19115.html
> 
> I have not yet received a word and I think this issue should be resolved.
> 
> Thanks
> Stephan
> 
> ---8<---

If the above text is placed below the three dashes, "---", below ...

> The ATH9K driver implements an RNG which is completely bypassing the
> standard Linux HW generator logic.
> 
> The RNG may or may not deliver entropy. Considering the conservative
> approach in treating entropy with respect to non-auditable sources, this
> patch changes the delivered entropy value to zero. The RNG still feeds
> data into the input_pool but it is assumed to have no entropy.
> 
> When the ATH9K RNG changes to use the HW RNG framework, it may re-enable
> the entropy estimation considering that a user can change that value at
> boot and runtime.
> 
> Signed-off-by: Stephan Mueller <smuel...@chronox.de>
> ---

here, then the mail can be applied directly without editing.

>  drivers/net/wireless/ath/ath9k/rng.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath9k/rng.c 
> b/drivers/net/wireless/ath/ath9k/rng.c
> index d38e50f..d63dc48 100644
> --- a/drivers/net/wireless/ath/ath9k/rng.c
> +++ b/drivers/net/wireless/ath/ath9k/rng.c
> @@ -92,8 +92,7 @@ static int ath9k_rng_kthread(void *data)
>   fail_stats = 0;
>  
>   /* sleep until entropy bits under write_wakeup_threshold */
> - add_hwgenerator_randomness((void *)rng_buf, bytes_read,
> -ATH9K_RNG_ENTROPY(bytes_read));

This is the only use of this macro.  I'd remove the #define on line 25
as well.

> +     add_hwgenerator_randomness((void *)rng_buf, bytes_read, 0);
>   }
>  
>   kfree(rng_buf);

Other than that,

Reviewed-by: Jason Cooper <ja...@lakedaemon.net>

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/7] A couple of generated files

[Jason Cooper]

Hey Sandy,

I know we talked  about this series offlist, but we need to fill in
folks who are seeing it for the first time.  Usually, this is done with
a coverletter (--coverletter for git format-patch).  No need to resend
before receiving feedback, but would you mind replying with a
description of the problem you're attempting to solve and how the series
solves it?

thx,

Jason.

On Sat, Nov 07, 2015 at 09:30:36AM -0500, Sandy Harris wrote:
> Signed-off-by: Sandy Harris 
> ---
>  .gitignore | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/.gitignore b/.gitignore
> index fd3a355..dd80bfd 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -112,3 +112,6 @@ all.config
>  
>  # Kdevelop4
>  *.kdev4
> +
> +certs/x509_certificate_list
> +scripts/gen_random
> -- 
> 2.5.0
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/7] Initialise pools randomly if CONFIG_RANDOM_INIT=y

[Jason Cooper]

On Sat, Nov 07, 2015 at 09:30:38AM -0500, Sandy Harris wrote:
> Signed-off-by: Sandy Harris 
> ---
>  drivers/char/random.c | 50 ++
>  1 file changed, 46 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index d0da5d8..e222e0f 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -231,7 +231,7 @@
>   * not be attributed to the Phil, Colin, or any of authors of PGP.
>   *
>   * Further background information on this topic may be obtained from
> - * RFC 1750, "Randomness Recommendations for Security", by Donald
> + * RFC 4086, "Randomness Requirements for Security", by Donald

I'm pretty sure you already sent this hunk separately.  Please remove it
from the next version.

thx,

Jason.

>   * Eastlake, Steve Crocker, and Jeff Schiller.
>   */
>  
> @@ -275,13 +275,19 @@
>  /*
>   * Configuration information
>   */
> +#ifdef CONFIG_RANDOM_INIT
> +
> +#include 
> +
> +#else
>  #define INPUT_POOL_SHIFT 12
>  #define INPUT_POOL_WORDS (1 << (INPUT_POOL_SHIFT-5))
>  #define OUTPUT_POOL_SHIFT10
>  #define OUTPUT_POOL_WORDS(1 << (OUTPUT_POOL_SHIFT-5))
> -#define SEC_XFER_SIZE512
> -#define EXTRACT_SIZE 10
> +#endif
>  
> +#define EXTRACT_SIZE 10
> +#define SEC_XFER_SIZE512
>  #define DEBUG_RANDOM_BOOT 0
>  
>  #define LONGS(x) (((x) + sizeof(unsigned long) - 1)/sizeof(unsigned long))
> @@ -296,6 +302,27 @@
>  #define ENTROPY_SHIFT 3
>  #define ENTROPY_BITS(r) ((r)->entropy_count >> ENTROPY_SHIFT)
>  
> +/* sanity checks */
> +
> +#if ((ENTROPY_SHIFT+INPUT_POOL_SHIFT) >= 16)
> +#ifndef CONFIG_64BIT
> +#error *_SHIFT values problematic for credit_entropy_bits()
> +#endif
> +#endif
> +
> +#if ((INPUT_POOL_WORDS%16) || (OUTPUT_POOL_WORDS%16))
> +#error Pool size not divisible by 16, which code assumes
> +#endif
> +
> +#if (INPUT_POOL_WORDS < 32)
> +#error Input pool less than a quarter of default size
> +#endif
> +
> +#if (INPUT_POOL_WORDS < OUTPUT_POOL_WORDS)
> +#error Strange configuration, input pool smalller than output
> +#endif
> +
> +
>  /*
>   * The minimum number of bits of entropy before we wake up a read on
>   * /dev/random.  Should be enough to do a significant reseed.
> @@ -442,16 +469,23 @@ struct entropy_store {
>  };
>  
>  static void push_to_pool(struct work_struct *work);
> +
> +#ifndef CONFIG_RANDOM_INIT
>  static __u32 input_pool_data[INPUT_POOL_WORDS];
>  static __u32 blocking_pool_data[OUTPUT_POOL_WORDS];
>  static __u32 nonblocking_pool_data[OUTPUT_POOL_WORDS];
> +#endif
>  
>  static struct entropy_store input_pool = {
>   .poolinfo = _table[0],
>   .name = "input",
>   .limit = 1,
>   .lock = __SPIN_LOCK_UNLOCKED(input_pool.lock),
> - .pool = input_pool_data
> +#ifdef CONFIG_RANDOM_INIT
> + .pool = pools,
> +#else
> + .pool = input_pool_data,
> +#endif
>  };
>  
>  static struct entropy_store blocking_pool = {
> @@ -460,7 +494,11 @@ static struct entropy_store blocking_pool = {
>   .limit = 1,
>   .pull = _pool,
>   .lock = __SPIN_LOCK_UNLOCKED(blocking_pool.lock),
> +#ifdef CONFIG_RANDOM_INIT
> + .pool = pools + INPUT_POOL_WORDS,
> +#else
>   .pool = blocking_pool_data,
> +#endif
>   .push_work = __WORK_INITIALIZER(blocking_pool.push_work,
>   push_to_pool),
>  };
> @@ -470,7 +508,11 @@ static struct entropy_store nonblocking_pool = {
>   .name = "nonblocking",
>   .pull = _pool,
>   .lock = __SPIN_LOCK_UNLOCKED(nonblocking_pool.lock),
> +#ifdef CONFIG_RANDOM_INIT
> + .pool = pools + INPUT_POOL_WORDS + OUTPUT_POOL_WORDS,
> +#else
>   .pool = nonblocking_pool_data,
> +#endif
>   .push_work = __WORK_INITIALIZER(nonblocking_pool.push_work,
>   push_to_pool),
>  };
> -- 
> 2.5.0
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/7] A couple of generated files

[Jason Cooper]

On Sat, Nov 07, 2015 at 09:30:36AM -0500, Sandy Harris wrote:
> Signed-off-by: Sandy Harris 
> ---
>  .gitignore | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/.gitignore b/.gitignore
> index fd3a355..dd80bfd 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -112,3 +112,6 @@ all.config
>  
>  # Kdevelop4
>  *.kdev4
> +
> +certs/x509_certificate_list
> +scripts/gen_random

Is there a .gitignore file in scripts/ ?

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 03/18] crypto: marvell: add flag to determine algorithm endianness

[Jason Cooper]

Hey Russell,

On Sun, Oct 18, 2015 at 05:23:40PM +0100, Russell King wrote:
> Rather than determining whether we're using a MD5 hash by looking at
> the digest size, switch to a cleaner solution using a per-request flag
> initialised by the method type.
> 
> Signed-off-by: Russell King 
> ---
>  drivers/crypto/marvell/cesa.h |  1 +
>  drivers/crypto/marvell/hash.c | 17 +
>  2 files changed, 10 insertions(+), 8 deletions(-)
> 
...
> diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
> index f59faabcd34f..aa12274608ab 100644
> --- a/drivers/crypto/marvell/hash.c
> +++ b/drivers/crypto/marvell/hash.c
> @@ -351,7 +351,7 @@ static int mv_cesa_ahash_process(struct 
> crypto_async_request *req, u32 status)
>* Hardware's MD5 digest is in little endian format, but
>* SHA in big endian format
>*/
> - if (digsize == MD5_DIGEST_SIZE) {
> + if (creq->algo_le) {
>   __le32 *result = (void *)ahashreq->result;
>  
>   for (i = 0; i < digsize / 4; i++)
> @@ -407,7 +407,7 @@ static const struct mv_cesa_req_ops mv_cesa_ahash_req_ops 
> = {
>  };
>  
>  static int mv_cesa_ahash_init(struct ahash_request *req,
> -   struct mv_cesa_op_ctx *tmpl)
> +   struct mv_cesa_op_ctx *tmpl, bool algo_le)

nit: Would it make more sense the do bool algo_endian, and then ...

> @@ -861,7 +862,7 @@ static int mv_cesa_md5_init(struct ahash_request *req)
>  
>   mv_cesa_set_op_cfg(, CESA_SA_DESC_CFG_MACM_MD5);
>  
> - mv_cesa_ahash_init(req, );
> + mv_cesa_ahash_init(req, , true);

mv_cesa_ahash_init(req, , ALGO_ENDIAN_LITTLE);

'true' doesn't seem as obvious.  But again, nit-picky.

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 03/18] crypto: marvell: add flag to determine algorithm endianness

[Jason Cooper]

On Mon, Oct 19, 2015 at 04:25:07PM +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 19, 2015 at 03:04:51PM +0000, Jason Cooper wrote:
> > Hey Russell,
> > 
> > On Sun, Oct 18, 2015 at 05:23:40PM +0100, Russell King wrote:
> > >  static int mv_cesa_ahash_init(struct ahash_request *req,
> > > -   struct mv_cesa_op_ctx *tmpl)
> > > +   struct mv_cesa_op_ctx *tmpl, bool algo_le)
> > 
> > nit: Would it make more sense the do bool algo_endian, and then ...
> 
> I don't like "bool"s that don't self-document what they mean.
> What does "if (algo_endian)" mean?  It's pretty clear what

That's where I would go with an enum.  "if (algo_endian ==
ALGO_ENDIAN_LITTLE) ..."

> "if (algo_le)" means in the context of endianness, though I'll
> give you that "if (algo_little_endian)" would be a lot better.

Right, it's really a question of where do we want readability?  I was
focusing on the call site, since the context isn't there for newcomers to
easily grok 'true'.

> > > @@ -861,7 +862,7 @@ static int mv_cesa_md5_init(struct ahash_request *req)
> > >  
> > >   mv_cesa_set_op_cfg(, CESA_SA_DESC_CFG_MACM_MD5);
> > >  
> > > - mv_cesa_ahash_init(req, );
> > > + mv_cesa_ahash_init(req, , true);
> > 
> > mv_cesa_ahash_init(req, , ALGO_ENDIAN_LITTLE);
> > 
> > 'true' doesn't seem as obvious.  But again, nit-picky.
> 
> I did think about:
> 
> enum {
>   ALGO_LITTLE_ENDIAN,
>   ALGO_BIG_ENDIAN,
> };
> 
> and passing an int algo_endian around, but that seemed to be like too
> much bloat... though if you want to insist, I could make that change.

Like I said, it's a nit.  Either a self-documenting bool, or an enum
will work.


thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 16/16] ARM: marvell/dt: add crypto node to kirkwood dtsi

[Jason Cooper]

On Tue, May 26, 2015 at 11:10:51AM +0200, Boris Brezillon wrote:
 On Tue, 26 May 2015 09:06:29 +
 Jason Cooper ja...@lakedaemon.net wrote:
 
  On Mon, May 25, 2015 at 08:43:02PM +0200, Boris Brezillon wrote:
   Jason, Gregory,
   
   On Mon, 25 May 2015 16:46:51 +
   Jason Cooper ja...@lakedaemon.net wrote:
   
On Mon, May 25, 2015 at 05:39:13PM +0200, Gregory CLEMENT wrote:
 Hi Boris, Arnaud,
 
 On 22/05/2015 15:34, Boris Brezillon wrote:
  From: Arnaud Ebalard a...@natisbad.org
  
  Add crypto related nodes to kirkwood.dtsi.
 
 Here you use a new compatible string but with an old binding
 to let the user chose between the old and the new driver. Am I right?
   
   That was not the intention, but you're right, that's exactly what's
   happening here.
   

I thought we had settled on the user choosing by module load/ which 
driver is
compiled in?  The DT should be describing the hardware, not which 
driver the
user chooses to use.
   
   Right, but I didn't want to add new compatible strings to the old
   driver in the first place, neither I wanted to support the new way of
   defining/referencing the crypto SRAMs.
  
  
   ITOH, if we want to benefit from the TDMA optimization on Kirkwood SoCs,
   we have to add a new compatible (unlike Orion SoCs, Kirkwood ones embed
   a TDMA engine).
  
  Ah, there's the HW difference I must have missed in my previous 
  thousand-foot
  overview scans :-/
  
  So marvell,orion-crypto matches IP blocks without the TDMA engine,
  marvell,kirkwood-crypto matches IP blocks *with* the TDMA engine.
  
   This leaves the following solutions:
- avoid changing the compatible in existing orion and kirkwood dtsi
  files
  
  no, in light of the above HW difference, it makes sense to change these.
  
- adding kirkwood compatible string support to the existing CESA
  driver (and I think supporting the new approach to retrieve SRAM
  memory region would make sense too)
  
  Or, old driver matches marvell,orion-crypto, and the new driver matches
  either compatible string.  If dt has marvell,kirkwood-crypto then new 
  driver
  enables TDMA with the provided properties.
  
  We then update the dtsi for all but orion to marvell,kirkwood-crypto.
  
  This may be what you are already doing.  If so, please ignore my rambling. 
  ;-)
 
 Yes, that's what I'm doing :-). But this means we're forcing kirkwood
 users to switch to the new driver, which is not really what you
 suggested in the first place.

well, I suppose I'm still clinging to the DT-as-stable-abi fantasy where
the dtb isn't locked to the kernel version.  :-P  If you're comfortable
with the change adding marvell,kirkwood-crypto to the old driver, then
go ahead.  It would indeed make everyone's lives easier.

thx,

Jason.


 
 
 -- 
 Boris Brezillon, Free Electrons
 Embedded Linux and Kernel engineering
 http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 16/16] ARM: marvell/dt: add crypto node to kirkwood dtsi

[Jason Cooper]

On Mon, May 25, 2015 at 08:43:02PM +0200, Boris Brezillon wrote:
 Jason, Gregory,
 
 On Mon, 25 May 2015 16:46:51 +
 Jason Cooper ja...@lakedaemon.net wrote:
 
  On Mon, May 25, 2015 at 05:39:13PM +0200, Gregory CLEMENT wrote:
   Hi Boris, Arnaud,
   
   On 22/05/2015 15:34, Boris Brezillon wrote:
From: Arnaud Ebalard a...@natisbad.org

Add crypto related nodes to kirkwood.dtsi.
   
   Here you use a new compatible string but with an old binding
   to let the user chose between the old and the new driver. Am I right?
 
 That was not the intention, but you're right, that's exactly what's
 happening here.
 
  
  I thought we had settled on the user choosing by module load/ which driver 
  is
  compiled in?  The DT should be describing the hardware, not which driver the
  user chooses to use.
 
 Right, but I didn't want to add new compatible strings to the old
 driver in the first place, neither I wanted to support the new way of
 defining/referencing the crypto SRAMs.


 ITOH, if we want to benefit from the TDMA optimization on Kirkwood SoCs,
 we have to add a new compatible (unlike Orion SoCs, Kirkwood ones embed
 a TDMA engine).

Ah, there's the HW difference I must have missed in my previous thousand-foot
overview scans :-/

So marvell,orion-crypto matches IP blocks without the TDMA engine,
marvell,kirkwood-crypto matches IP blocks *with* the TDMA engine.

 This leaves the following solutions:
  - avoid changing the compatible in existing orion and kirkwood dtsi
files

no, in light of the above HW difference, it makes sense to change these.

  - adding kirkwood compatible string support to the existing CESA
driver (and I think supporting the new approach to retrieve SRAM
memory region would make sense too)

Or, old driver matches marvell,orion-crypto, and the new driver matches
either compatible string.  If dt has marvell,kirkwood-crypto then new driver
enables TDMA with the provided properties.

We then update the dtsi for all but orion to marvell,kirkwood-crypto.

This may be what you are already doing.  If so, please ignore my rambling. ;-)

thx,

Jason.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 16/16] ARM: marvell/dt: add crypto node to kirkwood dtsi

[Jason Cooper]

On Mon, May 25, 2015 at 05:39:13PM +0200, Gregory CLEMENT wrote:
 Hi Boris, Arnaud,
 
 On 22/05/2015 15:34, Boris Brezillon wrote:
  From: Arnaud Ebalard a...@natisbad.org
  
  Add crypto related nodes to kirkwood.dtsi.
 
 Here you use a new compatible string but with an old binding
 to let the user chose between the old and the new driver. Am I right?

I thought we had settled on the user choosing by module load/ which driver is
compiled in?  The DT should be describing the hardware, not which driver the
user chooses to use.

thx,

Jason.

  Signed-off-by: Arnaud Ebalard a...@natisbad.org
  Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
  ---
   arch/arm/boot/dts/kirkwood.dtsi | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
  
  diff --git a/arch/arm/boot/dts/kirkwood.dtsi 
  b/arch/arm/boot/dts/kirkwood.dtsi
  index 464f09a..1700b2b 100644
  --- a/arch/arm/boot/dts/kirkwood.dtsi
  +++ b/arch/arm/boot/dts/kirkwood.dtsi
  @@ -41,7 +41,7 @@
  pcie-io-aperture  = 0xf200 0x10;   /*   1 MiBI/O 
  space */
   
  cesa: crypto@0301 {
  -   compatible = marvell,orion-crypto;
  +   compatible = marvell,kirkwood-crypto;
  reg = MBUS_ID(0xf0, 0x01) 0x3 0x1,
MBUS_ID(0x03, 0x01) 0 0x800;
  reg-names = regs, sram;
  
 
 
 -- 
 Gregory Clement, Free Electrons
 Kernel, drivers, real-time and embedded Linux
 development, consulting, training and support.
 http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/2] crypto: add a new driver for Marvell's CESA

[Jason Cooper]

+ Jason Gunthorpe, he may be interested in this.

On Fri, May 22, 2015 at 03:33:46PM +0200, Boris Brezillon wrote:
 Hello,
 
 This patch series adds a new driver supporting Marvell's CESA IP.
 This driver addresses some limitations of the existing one.
 From a performance and CPU load point of view the most important
 limitation in the existing driver is the lack of DMA support, thus
 preventing us from chaining crypto operations.
 
 I know we usually try to adapt existing drivers instead of replacing them
 by new ones, but after trying to refactor the mv_cesa driver I realized it
 would take longer than writing an new one from scratch.
 
 Here are the main features brought by this new driver:
 - support for armada SoCs (up to 38x) while keeping support for older ones
   (Orion and Kirkwood). Note that old DT bindings (those used on Orion and
   Kirkwood platforms) are supported, or IOTW, old DTs are compatible with
   this new driver.
 - DMA mode to offload the CPU in case of intensive crypto usage
 - new algorithms: SHA256, DES and 3DES
 
 In addition to this driver comes a bunch of DT updates adding crypto device
 nodes to several Marvell SoCs (those are only the tested ones, others might
 be added later).
 
 I'd like to thank Arnaud, who has carefully reviewed several iterations of
 this driver, helped me improved my implementation, provided support for
 several crypto algorithms, provided support for armada-370 and tested
 the driver on different platforms, hence the SoB and dual MODULE_AUTHOR
 in the driver code.
 
 Best Regards,
 
 Boris
 
 Changes since v2:
 - fixes in the cipher code (-dst_nents was assigned the -src_nents
   value and CBC state was overwritten by the IV after each chunk
   operation)
 - spit the code as suggested by Sebastian
 
 Changes since v1:
 - (suggested by Jason) kept the existing CESA driver and added a mechanism
   to prevent the new driver from probing devices handled my the existing
   one (Orion and Kirkwood platforms)
 - (reported by Paul) addressed a few Kconfig and module definition issues
 - (suggested by Andrew) added DT changes to the series
 
 Arnaud Ebalard (6):
   crypto: marvell/CESA: add Triple-DES support
   crypto: marvell/CESA: add MD5 support
   crypto: marvell/CESA: add SHA256 support
   crypto: marvell/CESA: add support for Kirkwood SoCs
   ARM: marvell/dt: add crypto node to armada 370 dtsi
   ARM: marvell/dt: add crypto node to kirkwood dtsi
 
 Boris Brezillon (10):
   crypto: mv_cesa: request registers memory region
   crypto: add a new driver for Marvell's CESA
   crypto: marvell/CESA: add TDMA support
   crypto: marvell/CESA: add DES support
   crypto: marvell/CESA: add support for all armada SoCs
   crypto: marvell/CESA: add allhwsupport module parameter
   crypto: marvell/CESA: add support for Orion SoCs
   crypto: marvell/CESA: update DT bindings documentation
   ARM: marvell/dt: add crypto node to armada-xp.dtsi
   ARM: marvell/dt: enable crypto on armada-xp-gp
 
  .../devicetree/bindings/crypto/marvell-cesa.txt|   46 +
  arch/arm/boot/dts/armada-370.dtsi  |   20 +
  arch/arm/boot/dts/armada-xp-gp.dts |4 +-
  arch/arm/boot/dts/armada-xp.dtsi   |   31 +
  arch/arm/boot/dts/kirkwood.dtsi|2 +-
  drivers/crypto/Kconfig |   18 +
  drivers/crypto/Makefile|1 +
  drivers/crypto/marvell/Makefile|2 +
  drivers/crypto/marvell/cesa.c  |  543 
  drivers/crypto/marvell/cesa.h  |  804 
  drivers/crypto/marvell/cipher.c|  769 +++
  drivers/crypto/marvell/hash.c  | 1349 
 
  drivers/crypto/marvell/tdma.c  |  224 
  drivers/crypto/mv_cesa.c   |   13 +-
  14 files changed, 3816 insertions(+), 10 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/crypto/marvell-cesa.txt
  create mode 100644 drivers/crypto/marvell/Makefile
  create mode 100644 drivers/crypto/marvell/cesa.c
  create mode 100644 drivers/crypto/marvell/cesa.h
  create mode 100644 drivers/crypto/marvell/cipher.c
  create mode 100644 drivers/crypto/marvell/hash.c
  create mode 100644 drivers/crypto/marvell/tdma.c
 
 -- 
 1.9.1
 
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] crypto: add new driver for Marvell CESA

[Jason Cooper]

Hey Boris,

On Fri, Apr 17, 2015 at 10:39:46AM +0200, Boris Brezillon wrote:
 On Fri, 17 Apr 2015 10:33:56 +0200 Boris Brezillon 
 boris.brezil...@free-electrons.com wrote:
  On Mon, 13 Apr 2015 20:11:46 + Jason Cooper ja...@lakedaemon.net 
  wrote:

 I'd appreciate if we'd look into it.  I understand from on-list and
 off-list discussion that the rewrite was unavoidable.  So I'm willing 
 to
 concede that.  Giving people time to migrate from old to new while 
 still
 being able to update for other security fixes seems reasonable.

Jason, what do you think of the approach above? 
   
   I say keep it simple.  We shouldn't use the DT changes to trigger one
   vice the other.  We need to be able to build both, but only load one at
   a time.  If that's anything other than simple to do, then we make it a
   Kconfig binary choice and move on.
  
  Actually I was planning to handle it with a Kconfig dependency rule
  (NEW_DRIVER depends on !OLD_DRIVER and OLD_DRIVER depends
  on !NEW_DRIVER).
  I don't know how to make it a runtime check without adding new
  compatible strings for the kirkwood, dove and orion platforms, and I'm
  sure sure this is a good idea.
   ^ not
 
  Do you have any ideas ?

I'm kinda wrapped up with dayjob stuff atm...  But I'd look at the wireless
drivers.  eg b43, b43legacy, brcm80211.  There are devices they overlap for.
So, they need to deconflict in some way.

thx,

Jason.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] crypto: add new driver for Marvell CESA

[Jason Cooper]

Hey Gregory,

On Mon, Apr 13, 2015 at 11:39:16AM +0200, Gregory CLEMENT wrote:
 Hi Jason, Boris,
 
 On 11/04/2015 00:30, Jason Cooper wrote:
  Hey Boris,
  
  On Fri, Apr 10, 2015 at 05:11:48PM +0200, Boris Brezillon wrote:
  On Fri, 10 Apr 2015 13:50:56 + Jason Cooper ja...@lakedaemon.net 
  wrote:
  On Thu, Apr 09, 2015 at 04:58:41PM +0200, Boris Brezillon wrote:
  I know we usually try to adapt existing drivers instead of replacing them
  by new ones, but after trying to refactor the mv_cesa driver I realized 
  it
  would take longer than writing an new one from scratch.
 
  I'm sorry, but this makes me *very* uncomfortable.  Any organization
  worth it's salt will do a very careful audit of code touching
  cryptographic material and sensitive (decrypted) data.  From that point
  on, small audits of the changes to the code allow the organization to
  build a comfort level with kernel updates.  iow, following the git
  history of the driver.
 
  By apply this series, we are basically forcing those organizations to
  either a) stop updating, or b) expend significant resources to do
  another full audit.
 
  In short, this series breaks the audit chain for the mv_cesa driver.
 
  Maybe I'm the only person with this level of paranoia.  If so, I'm sure
  others will override me.
 
  From my POV, it looks like the *only* reason we've chosen this route is
  developer convenience.  I don't think that's sufficient reason to break
  the change history of a driver handling sensitive data.
 
  Well, I understand you concern, but if you read carefully the old and
  new drivers, you'll notice that they are completely different (the only
  thing I kept are the macro definitions).
  
  Yes, that's the worrying part for me. ;-)
 
 I understand the logic behind your concern, but I wonder if it is really
 an issue. My knowledge ans my background around crypto is very limited,
 so I really would like the opinion of other people on the subject.

It's not about the crypto, it's about trust.  imho, one of the most
important security advances in the past 20 years is the default use of
git (or other SCMs) by open source projects.  Now, no one is forced to
trust the authors and maintainers tarball dumps.  Regular code audits
and security updates are *much* more feasible because you can audit
small changes.  It can even be automated to a large extent.

All this means the user has a choice: they can trust the authors and
maintainers, or they can trust their own audits.  Since updates are an
essential part of a security posture, small commits facilitate
maintaining the 'trust in audits'.

It's not about Should you trust free-electrons?  Or, Should you trust
Jason / Herbert / Linus?  It's about Should you have to trust any of
them?

  I really tried to adapt the existing driver to add the missing
  features (especially the support for TDMA), but all my attempts
  ended up introducing hackish code (not even talking about the
  performance penalty of this approach).
  
  Ok, fair enough.  It would be helpful if this account of attempting to
  reconcile the old driver made it into the commit message.  This puts us
  in perfect is the enemy of getting it done territory.
  
  I have another solution though: keep the existing driver for old
  marvell SoCs (orion, kirkwood and dove), and add a new one for modern
  SoCs (armada 370, XP, 375 and 38x), so that users of the mv_cesa driver
  won't have to audit the new code.
  
  A fair proposal, but I'll freely admit the number of people actually 
  auditing
  their code paths is orders of magnitude smaller than the number of users
  of the driver.
  
  There's such a large population of compatible legacy SoCs in the wild,
  adding an artificial boundary doesn't make sense.  Especially since
  we're talking about features everyone would want to use.
  
  Perhaps we should keep both around, and deprecate the legacy driver over
  3 to 4 cycles?
 
 But I guess that some users will want to use the new driver on the old 
 marvell
 SoCs (especially kirkwood and dove).

Yes, despite my arguments, I'm one of those people.  :-P

 If we go to this path, then the best solution would be to still update
 all the the dts, and modifying the old driver to be able to use the
 new binding: for my point of view the only adaptation should be
 related to the SRAM. It will be also needed to find a way to be able
 to load only one driver at a time: either the old or the new, but not
 both.

We can look at how the wireless drivers handle this.  They often have to
choose between multiple drivers (foss, proprietary, ndis-something, etc)
for a given card.  Not much different here.

 However I still wonder if it worth the effort.

I'd appreciate if we'd look into it.  I understand from on-list and
off-list discussion that the rewrite was unavoidable.  So I'm willing to
concede that.  Giving people time to migrate from old to new while still
being able to update for other security fixes seems reasonable.

thx

Re: [PATCH 0/2] crypto: add new driver for Marvell CESA

[Jason Cooper]

Hey Boris,

On Fri, Apr 10, 2015 at 05:11:48PM +0200, Boris Brezillon wrote:
 On Fri, 10 Apr 2015 13:50:56 + Jason Cooper ja...@lakedaemon.net wrote:
  On Thu, Apr 09, 2015 at 04:58:41PM +0200, Boris Brezillon wrote:
   I know we usually try to adapt existing drivers instead of replacing them
   by new ones, but after trying to refactor the mv_cesa driver I realized it
   would take longer than writing an new one from scratch.
  
  I'm sorry, but this makes me *very* uncomfortable.  Any organization
  worth it's salt will do a very careful audit of code touching
  cryptographic material and sensitive (decrypted) data.  From that point
  on, small audits of the changes to the code allow the organization to
  build a comfort level with kernel updates.  iow, following the git
  history of the driver.
  
  By apply this series, we are basically forcing those organizations to
  either a) stop updating, or b) expend significant resources to do
  another full audit.
  
  In short, this series breaks the audit chain for the mv_cesa driver.
  
  Maybe I'm the only person with this level of paranoia.  If so, I'm sure
  others will override me.
  
  From my POV, it looks like the *only* reason we've chosen this route is
  developer convenience.  I don't think that's sufficient reason to break
  the change history of a driver handling sensitive data.
 
 Well, I understand you concern, but if you read carefully the old and
 new drivers, you'll notice that they are completely different (the only
 thing I kept are the macro definitions).

Yes, that's the worrying part for me. ;-)

 I really tried to adapt the existing driver to add the missing
 features (especially the support for TDMA), but all my attempts
 ended up introducing hackish code (not even talking about the
 performance penalty of this approach).

Ok, fair enough.  It would be helpful if this account of attempting to
reconcile the old driver made it into the commit message.  This puts us
in perfect is the enemy of getting it done territory.

 I have another solution though: keep the existing driver for old
 marvell SoCs (orion, kirkwood and dove), and add a new one for modern
 SoCs (armada 370, XP, 375 and 38x), so that users of the mv_cesa driver
 won't have to audit the new code.

A fair proposal, but I'll freely admit the number of people actually auditing
their code paths is orders of magnitude smaller than the number of users
of the driver.

There's such a large population of compatible legacy SoCs in the wild,
adding an artificial boundary doesn't make sense.  Especially since
we're talking about features everyone would want to use.

Perhaps we should keep both around, and deprecate the legacy driver over
3 to 4 cycles?

thx,

Jason.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] staging: crypto: fixed style errors in ablkcipher.c

[Jason Cooper]

Joshua,

Your subject, [PATCH] staging: crypto: fixed style errors in
ablkcipher.c is misleading.  'staging' is a location in the tree,
drivers/staging/, not a separate git tree.  So your subject for this
series should have been [PATCH] crypto: ablkcipher: Cleanup minor
checkpatch error.  More below.

On Fri, Dec 05, 2014 at 02:06:16PM +0900, Joshua I. James wrote:
 From: Joshua I. James jos...@cybercrimetech.com
 
 Fixed style errors reported by checkpatch.
 
 WARNING: Missing a blank line after declarations
 +   u8 *end_page = (u8 *)(((unsigned long)(start + len - 1))  PAGE_MASK);
 +   return max(start, end_page);
 
 WARNING: line over 80 characters
 +   scatterwalk_start(walk-out, 
 scatterwalk_sg_next(walk-out.sg));
 
 WARNING: Missing a blank line after declarations
 +   int err = ablkcipher_copy_iv(walk, tfm, alignmask);
 +   if (err)

While checkpatch is correct with the above, alone they don't justify a
patch.

 ERROR: do not use assignment in if condition
 +   if ((err = crypto_register_instance(tmpl, inst))) {

imho, this one is a good cleanup.  Especially in crypto code.  I would
like to see a comment in this commit message explaining that the code
was reviewed to make sure it wasn't an actual bug, and this is indeed
just a style cleanup.

I would also explain that since it's worth doing a patch for the
checkpatch error, we may as well hit a few warnings while we are here.

 
 Signed-off-by: Joshua I. James jos...@cybercrimetech.com
 ---
  crypto/ablkcipher.c | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)
 
 diff --git a/crypto/ablkcipher.c b/crypto/ablkcipher.c
 index 40886c4..7bbc8b4 100644
 --- a/crypto/ablkcipher.c
 +++ b/crypto/ablkcipher.c
 @@ -69,6 +69,7 @@ static inline void ablkcipher_queue_write(struct 
 ablkcipher_walk *walk,
  static inline u8 *ablkcipher_get_spot(u8 *start, unsigned int len)
  {
   u8 *end_page = (u8 *)(((unsigned long)(start + len - 1))  PAGE_MASK);
 +
   return max(start, end_page);
  }

This one is fine.

  
 @@ -86,7 +87,8 @@ static inline unsigned int ablkcipher_done_slow(struct 
 ablkcipher_walk *walk,
   if (n == len_this_page)
   break;
   n -= len_this_page;
 - scatterwalk_start(walk-out, 
 scatterwalk_sg_next(walk-out.sg));
 + scatterwalk_start(walk-out, scatterwalk_sg_next(
 + walk-out.sg));

nit: I would just ignore this warning.  checkpatch just points you in a
direction, it isn't an enforcer of policy.

Especially here in crypto code, I don't like to see any changes that
make me start counting braces or otherwise looking for tricks.  Because
that means I'm questioning the submitters motivation.  The goal with
checkpatch is to make the code *more* obvious and readable.  The above
change does the opposite.

   }
  
   return bsize;
 @@ -284,6 +286,7 @@ static int ablkcipher_walk_first(struct 
 ablkcipher_request *req,
   walk-iv = req-info;
   if (unlikely(((unsigned long)walk-iv  alignmask))) {
   int err = ablkcipher_copy_iv(walk, tfm, alignmask);
 +
   if (err)
   return err;
   }

No problem here.

 @@ -589,7 +592,8 @@ static int crypto_givcipher_default(struct crypto_alg 
 *alg, u32 type, u32 mask)
   if (IS_ERR(inst))
   goto put_tmpl;
  
 - if ((err = crypto_register_instance(tmpl, inst))) {
 + err = crypto_register_instance(tmpl, inst);
 + if (err) {
   tmpl-free(inst);
   goto put_tmpl;
   }

This is a nice cleanup that justifies doing the patch.  Just mention in
the commit message why this looks like it wasn't a bug (was it supposed
to be '==' ?) and the change makes that clear.  I'm really looking to
see that you are thinking about if the change is appropriate, not just
blindly making checkpatch shut up.

thx,

Jason.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] staging: crypto: fixed style error in aead.c

[Jason Cooper]

Joshua,

On Fri, Dec 05, 2014 at 02:24:44PM +0900, Joshua I. James wrote:
 From: Joshua I. James jos...@cybercrimetech.com
 
 Fixed style error identified by checkpatch.
 
 ERROR: do not use assignment in if condition
 +   if ((err = crypto_register_instance(tmpl, inst))) {

Short comment needed here like I mentioned with the first patch.  Also,
subject line needs corrected as with the first.

 
 Signed-off-by: Joshua I. James jos...@cybercrimetech.com
 ---
  crypto/aead.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
 
 diff --git a/crypto/aead.c b/crypto/aead.c
 index 547491e..710 100644
 --- a/crypto/aead.c
 +++ b/crypto/aead.c
 @@ -448,7 +448,8 @@ static int crypto_nivaead_default(struct crypto_alg *alg, 
 u32 type, u32 mask)
   if (IS_ERR(inst))
   goto put_tmpl;
  
 - if ((err = crypto_register_instance(tmpl, inst))) {
 + err = crypto_register_instance(tmpl, inst);
 + if (err) {
   tmpl-free(inst);
   goto put_tmpl;
   }

I haven't looked at the rest of the series yet, but if they are just
like this one, Herbert may prefer just to put these all in one patch.
I'll add him to the To: and you should wait for his response.

thx,

Jason.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] staging: crypto: fixed style error in af_alg.c

[Jason Cooper]

On Fri, Dec 05, 2014 at 02:38:40PM +0900, Joshua I. James wrote:
 From: Joshua I. James jos...@cybercrimetech.com
 
 Fixed style error identified by checkpatch.
 
 ERROR: space required before the open parenthesis '('
 +   switch(cmsg-cmsg_type) {
 
 Signed-off-by: Joshua I. James jos...@cybercrimetech.com
 ---
  crypto/af_alg.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

Subject line, and this change really doesn't justify a patch by itself.
If Herbert prefers them merged into one, I'd include this change,
otherwise, I'd drop it.

It'd also be a good idea to run ./scripts/get_maintainer.pl on your
patch to determine who to include in the To/Cc on the next version of
this series.

thx,

Jason.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] staging: crypto: fixed style error in ahash.c

[Jason Cooper]

On Fri, Dec 05, 2014 at 02:44:54PM +0900, Joshua I. James wrote:
 From: Joshua I. James jos...@cybercrimetech.com
 
 Fixed style error identified by checkpatch.
 
 WARNING: Missing a blank line after declarations
 +   unsigned int unaligned = alignmask + 1 - (offset  alignmask);
 +   if (nbytes  unaligned)
 
 Signed-off-by: Joshua I. James jos...@cybercrimetech.com
 ---
  crypto/ahash.c | 1 +
  1 file changed, 1 insertion(+)

Same comment as the third patch.

thx,

Jason.

 
 diff --git a/crypto/ahash.c b/crypto/ahash.c
 index f6a36a5..dd28906 100644
 --- a/crypto/ahash.c
 +++ b/crypto/ahash.c
 @@ -55,6 +55,7 @@ static int hash_walk_next(struct crypto_hash_walk *walk)
  
   if (offset  alignmask) {
   unsigned int unaligned = alignmask + 1 - (offset  alignmask);
 +
   if (nbytes  unaligned)
   nbytes = unaligned;
   }
 -- 
 1.9.1
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-crypto in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 01/11] crypto: Documentation - crypto API high level spec

[Jason Cooper]

Stephan,

On Mon, Nov 03, 2014 at 03:18:29PM +0100, Stephan Mueller wrote:
 Am Montag, 3. November 2014, 08:34:39 schrieb Jonathan Corbet:
  These are all useful.  But I wonder if it would be worth the effort to turn
  this inti a proper docbook document that automatically has everything
  together in one place?
 
 How do you suggest that is done? The API comments in the header file follow 
 the Doxygen style. Note, Jason Cooper raised the concern that an API 
 documentation separate from the code will surely deviate from the code 
 relatively fast (although I do not really fear that as the kernel crypto API 
 seems to be quite stable over the last years).

Agreed.  My primary concern was adding it in such a way which
facilitates maintenance and keeping it in sync with the code.  But as
you say, the crypto API doesn't change much.

thx,

Jason.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] kernel crypto API interface specification

[Jason Cooper]

+ Grant, Geert,

Stephan has created some great example code for both the kernel crypto
API and the userspace crypto API.  As examples tend to bitrot, I was
wondering if the code could serve as test code.  Then it would have a
triple role: API regression testing, crypto test suite, and reference
implementation.

Original patch is here:

  https://lkml.kernel.org/r/7502136.9bkwhtz...@myon.chronox.de

On Thu, Oct 16, 2014 at 09:19:08AM +0200, Stephan Mueller wrote:
 Am Mittwoch, 15. Oktober 2014, 13:58:00 schrieb Jason Cooper:
 
 Hi Jason,
 
  Stephan,
  
  Wow.  This is very thorough.  Herbert and others will be making the
  final call on this, but if I may make a suggestion:
 
 Thanks.
  
  On Tue, Oct 14, 2014 at 09:46:50PM +0200, Stephan Mueller wrote:
   The update adds a complete interface documentation of the kernel crypto
   API. All cipher types supported by the kernel crypto API are documented.
   
   In addition, kernel and user space example code is provided. The sample
   code covers synchronous and asynchronous cipher operation, random
   number generation and performing hashing as well as encryption and
   decryption in user space.
  
  This really needs to be split into at least two pieces.  The kernel and
  the userspace API.  I'd venture to say the userspace API portion of this
  document is almost ready.  But I'm not certain that the kernel
  interfaces are best described in a specification.
 
 Good idea, I will split it.
  
  APIs within the kernel are intentionally not nailed down and are very
  fluid.  Any attempt to spell them out in a document would mean either a)
  the document would be out of date quickly, or b) the maintainer now has
  to ask for changes to the docs every time a patch with a kernel API
  change comes in.  Neither scenario is good. :-(
 
 Right, but on the other hand having no documentation at all is also bad. I 
 know first hand how non-straight-forward it is to use the kernel crypto API 
 as 
 I programmed a test kernel module that invokes all cipher types available. 
 Even with the examples in testmgr.c, I had a number of trial and errors. For 
 crypto, this is not good.
 
 Note, the mistakes you make are not easily seen, which is a problem if you 
 want to protect data :-)
 
 The key problem is that the kernel crypto API makes some assumptions on the 
 memory layout and the concept of asymmetric requests. Furthermore, the AEAD 
 definitions require different data types than offered by the API. That means 
 the calling code must first massage the AEAD input data (see CCM IV vs nonce 
 or the CCM/GCM tag handling).
 
 Yet, I also see that a separate documentation may easily deviate from the 
 real 
 code (I know that first hand as I have to document parts of the kernel for 
 some projects :-) ). Therefore I also suggested to take the API call 
 documentation out and put it into the header files where the API calls are 
 specified.
  
  We certainly don't want to lose all of the effort you've put into
  grokking the API, so we need to find a maintainable place to add it.  I
  personally think adding comments above the respective function
  blocks would work well.
 
 Right, as I also suggested in my follow-up email. Yet, I would like to hear 
 an 
 ok from the maintainers that I can touch these files.

That's like asking if you can ask a question.  Just do it.  :-)

  The examples (kernel API) are another matter entirely.  Examples that
  aren't up-to-date and usable as a template aren't helpful to anyone.
  Some would even say detrimental.  And since example code isn't actually
  *used* in the real world, it would be an extra burden keeping it up to
  date.  I think these could best be used as a reference to compare all of
  the current users to.  Anything not up to par would generate a patch.
  The best examples should be the current users in the kernel.
 
 Yes, that is what I also fear. Yet, using the asynchronous API may not be 
 straight forward. Especially AEAD has some non-obvious requirements that may 
 be documented best with an example. Yet, the example may be stripped down 
 drastically to focus on the key aspects.

Perhaps extending testmgr.c with your example code would be the best
answer.  There has been a push recently to have more comprehensive test
suites within the kernel.  If the test code is run often, it would make
a reasonable place for 'reference' implementations.

   Signed-off-by: Stephan Mueller smuel...@chronox.de
   ---
   
Documentation/crypto/crypto-API-spec.txt | 2110
++ 1 file changed, 2110 insertions(+)
create mode 100644 Documentation/crypto/crypto-API-spec.txt
   
   diff --git a/Documentation/crypto/crypto-API-spec.txt
   b/Documentation/crypto/crypto-API-spec.txt new file mode 100644
   index 000..027fd4f
   --- /dev/null
   +++ b/Documentation/crypto/crypto-API-spec.txt
   @@ -0,0 +1,2110 @@
  
  [snip detailed explanation of current kernel API]
  
   +User space API

Re: [PATCH] kernel crypto API interface specification

[Jason Cooper]

On Thu, Oct 16, 2014 at 09:25:01AM -0400, Jason Cooper wrote:
 + Grant, Geert,

oops.  It helps if I actually *add* them.  Sorry for the noise.

 Stephan has created some great example code for both the kernel crypto
 API and the userspace crypto API.  As examples tend to bitrot, I was
 wondering if the code could serve as test code.  Then it would have a
 triple role: API regression testing, crypto test suite, and reference
 implementation.
 
 Original patch is here:
 
   https://lkml.kernel.org/r/7502136.9bkwhtz...@myon.chronox.de
 
 On Thu, Oct 16, 2014 at 09:19:08AM +0200, Stephan Mueller wrote:
  Am Mittwoch, 15. Oktober 2014, 13:58:00 schrieb Jason Cooper:
  
  Hi Jason,
  
   Stephan,
   
   Wow.  This is very thorough.  Herbert and others will be making the
   final call on this, but if I may make a suggestion:
  
  Thanks.
   
   On Tue, Oct 14, 2014 at 09:46:50PM +0200, Stephan Mueller wrote:
The update adds a complete interface documentation of the kernel crypto
API. All cipher types supported by the kernel crypto API are documented.

In addition, kernel and user space example code is provided. The sample
code covers synchronous and asynchronous cipher operation, random
number generation and performing hashing as well as encryption and
decryption in user space.
   
   This really needs to be split into at least two pieces.  The kernel and
   the userspace API.  I'd venture to say the userspace API portion of this
   document is almost ready.  But I'm not certain that the kernel
   interfaces are best described in a specification.
  
  Good idea, I will split it.
   
   APIs within the kernel are intentionally not nailed down and are very
   fluid.  Any attempt to spell them out in a document would mean either a)
   the document would be out of date quickly, or b) the maintainer now has
   to ask for changes to the docs every time a patch with a kernel API
   change comes in.  Neither scenario is good. :-(
  
  Right, but on the other hand having no documentation at all is also bad. I 
  know first hand how non-straight-forward it is to use the kernel crypto API 
  as 
  I programmed a test kernel module that invokes all cipher types available. 
  Even with the examples in testmgr.c, I had a number of trial and errors. 
  For 
  crypto, this is not good.
  
  Note, the mistakes you make are not easily seen, which is a problem if you 
  want to protect data :-)
  
  The key problem is that the kernel crypto API makes some assumptions on the 
  memory layout and the concept of asymmetric requests. Furthermore, the AEAD 
  definitions require different data types than offered by the API. That 
  means 
  the calling code must first massage the AEAD input data (see CCM IV vs 
  nonce 
  or the CCM/GCM tag handling).
  
  Yet, I also see that a separate documentation may easily deviate from the 
  real 
  code (I know that first hand as I have to document parts of the kernel for 
  some projects :-) ). Therefore I also suggested to take the API call 
  documentation out and put it into the header files where the API calls are 
  specified.
   
   We certainly don't want to lose all of the effort you've put into
   grokking the API, so we need to find a maintainable place to add it.  I
   personally think adding comments above the respective function
   blocks would work well.
  
  Right, as I also suggested in my follow-up email. Yet, I would like to hear 
  an 
  ok from the maintainers that I can touch these files.
 
 That's like asking if you can ask a question.  Just do it.  :-)
 
   The examples (kernel API) are another matter entirely.  Examples that
   aren't up-to-date and usable as a template aren't helpful to anyone.
   Some would even say detrimental.  And since example code isn't actually
   *used* in the real world, it would be an extra burden keeping it up to
   date.  I think these could best be used as a reference to compare all of
   the current users to.  Anything not up to par would generate a patch.
   The best examples should be the current users in the kernel.
  
  Yes, that is what I also fear. Yet, using the asynchronous API may not be 
  straight forward. Especially AEAD has some non-obvious requirements that 
  may 
  be documented best with an example. Yet, the example may be stripped down 
  drastically to focus on the key aspects.
 
 Perhaps extending testmgr.c with your example code would be the best
 answer.  There has been a push recently to have more comprehensive test
 suites within the kernel.  If the test code is run often, it would make
 a reasonable place for 'reference' implementations.
 
Signed-off-by: Stephan Mueller smuel...@chronox.de
---

 Documentation/crypto/crypto-API-spec.txt | 2110
 ++ 1 file changed, 2110 insertions(+)
 create mode 100644 Documentation/crypto/crypto-API-spec.txt

diff --git a/Documentation/crypto/crypto-API-spec.txt
b/Documentation/crypto

Re: [PATCH] kernel crypto API interface specification

[Jason Cooper]

On Thu, Oct 16, 2014 at 09:25:01AM -0400, Jason Cooper wrote:
 + Grant, Geert,
 
 Stephan has created some great example code for both the kernel crypto
 API and the userspace crypto API.  As examples tend to bitrot, I was
 wondering if the code could serve as test code.  Then it would have a
 triple role: API regression testing, crypto test suite, and reference
 implementation.
 
 Original patch is here:
 
   https://lkml.kernel.org/r/7502136.9bkwhtz...@myon.chronox.de
 
 On Thu, Oct 16, 2014 at 09:19:08AM +0200, Stephan Mueller wrote:
  Am Mittwoch, 15. Oktober 2014, 13:58:00 schrieb Jason Cooper:
   On Tue, Oct 14, 2014 at 09:46:50PM +0200, Stephan Mueller wrote:
...
   Perhaps the userspace API example should be a separate file with this
   text at the top?  Seems odd having it at the end.  Also, if you copied
   it from cryptsetup, is the copyright info correct?
  
  I did not copy it from cryptsetup. I only used it as a basis, especially 
  with 
  the data structure handling in _kcapi_cipher_crypt. But you are right, I 
  changed the license for the user space by taking the cryptsetup license.
 
 Ok.  It looks like Geert and Grant took part in the kernel test
 unconference, so I'm adding them to the Cc.  I hope they can give us
 some pointers as to where we could hook in this code.  Then we can
 simply refer to it from the userspace API document.

tools/testing/selftests/crypto would be a good location for the example
code in the next version of this patch.  Make sure to take a look at
tools/testing/selftests/README.txt.

thx,

Jason.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] kernel crypto API interface specification

[Jason Cooper]

On Thu, Oct 16, 2014 at 06:50:58PM +0200, Stephan Mueller wrote:
 Am Donnerstag, 16. Oktober 2014, 11:06:05 schrieb Jason Cooper:
 
 Hi Jason,
 
  On Thu, Oct 16, 2014 at 09:25:01AM -0400, Jason Cooper wrote:
   + Grant, Geert,
   
   Stephan has created some great example code for both the kernel crypto
   API and the userspace crypto API.  As examples tend to bitrot, I was
   wondering if the code could serve as test code.  Then it would have a
   triple role: API regression testing, crypto test suite, and reference
   implementation.
   
   Original patch is here:
 https://lkml.kernel.org/r/7502136.9bkwhtz...@myon.chronox.de
   
   On Thu, Oct 16, 2014 at 09:19:08AM +0200, Stephan Mueller wrote:
Am Mittwoch, 15. Oktober 2014, 13:58:00 schrieb Jason Cooper:
 On Tue, Oct 14, 2014 at 09:46:50PM +0200, Stephan Mueller wrote:
  ...
  
 Perhaps the userspace API example should be a separate file with this
 text at the top?  Seems odd having it at the end.  Also, if you copied
 it from cryptsetup, is the copyright info correct?

I did not copy it from cryptsetup. I only used it as a basis, especially
with the data structure handling in _kcapi_cipher_crypt. But you are
right, I changed the license for the user space by taking the
cryptsetup license. 
   Ok.  It looks like Geert and Grant took part in the kernel test
   unconference, so I'm adding them to the Cc.  I hope they can give us
   some pointers as to where we could hook in this code.  Then we can
   simply refer to it from the userspace API document.
  
  tools/testing/selftests/crypto would be a good location for the example
  code in the next version of this patch.  Make sure to take a look at
  tools/testing/selftests/README.txt.
 
 Well, I have written a FIPS 140-2 CAVS test harness covering all ciphers NIST 
 is interested. Maybe this can go there?

Assuming you own the code and are willing to license it under and
compatible license, then yes.  I would keep it a separate test from
other crypto tests, though.

There may be some push back wrt it being FIPS 140-2.  But I think it's
worth considering.

thx,

Jason.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] kernel crypto API interface specification

[Jason Cooper]

Stephan,

Wow.  This is very thorough.  Herbert and others will be making the
final call on this, but if I may make a suggestion:

On Tue, Oct 14, 2014 at 09:46:50PM +0200, Stephan Mueller wrote:
 The update adds a complete interface documentation of the kernel crypto
 API. All cipher types supported by the kernel crypto API are documented.
 
 In addition, kernel and user space example code is provided. The sample
 code covers synchronous and asynchronous cipher operation, random
 number generation and performing hashing as well as encryption and
 decryption in user space.

This really needs to be split into at least two pieces.  The kernel and
the userspace API.  I'd venture to say the userspace API portion of this
document is almost ready.  But I'm not certain that the kernel
interfaces are best described in a specification.

APIs within the kernel are intentionally not nailed down and are very
fluid.  Any attempt to spell them out in a document would mean either a)
the document would be out of date quickly, or b) the maintainer now has
to ask for changes to the docs every time a patch with a kernel API
change comes in.  Neither scenario is good. :-(

We certainly don't want to lose all of the effort you've put into
grokking the API, so we need to find a maintainable place to add it.  I
personally think adding comments above the respective function
blocks would work well.

The examples (kernel API) are another matter entirely.  Examples that
aren't up-to-date and usable as a template aren't helpful to anyone.
Some would even say detrimental.  And since example code isn't actually
*used* in the real world, it would be an extra burden keeping it up to
date.  I think these could best be used as a reference to compare all of
the current users to.  Anything not up to par would generate a patch.
The best examples should be the current users in the kernel.

 Signed-off-by: Stephan Mueller smuel...@chronox.de
 ---
  Documentation/crypto/crypto-API-spec.txt | 2110 
 ++
  1 file changed, 2110 insertions(+)
  create mode 100644 Documentation/crypto/crypto-API-spec.txt
 
 diff --git a/Documentation/crypto/crypto-API-spec.txt 
 b/Documentation/crypto/crypto-API-spec.txt
 new file mode 100644
 index 000..027fd4f
 --- /dev/null
 +++ b/Documentation/crypto/crypto-API-spec.txt
 @@ -0,0 +1,2110 @@

[snip detailed explanation of current kernel API]

 +User space API
 +==
 +
 +The kernel crypto API is accessible from user space. Currently, the following
 +ciphers are accessible:
 +
 + * Message digest including keyed message digest
 +
 + * Symmetric ciphers
 +
 +The interface is provided via Netlink using the type AF_ALG. In addition, the
 +setsockopt option type is SOL_ALG. In case the user space header files do not
 +export these flags yet, use the following macros:
 +
 +#ifndef AF_ALG
 +#define AF_ALG 38
 +#endif
 +#ifndef SOL_ALG
 +#define SOL_ALG 279
 +#endif
 +
 +A cipher is accessed with the same name as done for the in-kernel API calls.

Perhaps a reference here to the final location of the kernel API
explanations?

 +
 +To interact with the kernel crypto API, a Netlink socket must be created by
 +the user space application. User space invokes the cipher operation with the
 +send/write system call family. The result of the cipher operation is obtained
 +with the read/recv system call family.
 +
 +The following API calls assume that the Netlink socket descriptor is already
 +opened by the user space application and discusses only the kernel crypto API
 +specific invocations.
 +
 +Message digest API
 +--
 +
 +The message digest type to be used for the cipher operation is selected when
 +invoking the bind syscall. bind requires the caller to provide a filled
 +struct sockaddr data structure. This data structure must be filled as 
 follows:
 +
 +struct sockaddr_alg sa = {
 + .salg_family = AF_ALG,
 + .salg_type = hash, /* this selects the hash logic in the kernel */
 + .salg_nmae = sha1 /* this is the cipher name */
 +};
 +
 +Using the send() system call, the application provides the data that should 
 be
 +processed with the message digest. The send system call allows the following
 +flags to be specified:
 +
 + * MSG_MORE: If this flag is set, the send system call acts like a
 + message digest update function where the final hash is not
 + yet calculated. If the flag is not set, the send system call
 + calculates the final message digest immediately.
 +
 +With the read() system call, the application can read the message digest from
 +the kernel crypto API. If the buffer is too small for the message digest, the
 +flag MSG_TRUNC is set by the kernel.
 +
 +In order to set a message digest key, the calling application must use the
 +setsockopt() option of ALG_SET_KEY.

What happens if this is omitted?

 +
 +
 +Symmetric cipher API
 +
 +
 +The operation is very similar to 

Re: memset() in crypto code?

[Jason Cooper]

On Sat, Oct 04, 2014 at 11:09:40PM -0400, Sandy Harris wrote:
 There was recently a patch to the random driver to replace memset()
 because, according to the submitter, gcc sometimes optimises memset()
 away which might leave data unnecessarily exposed. The solution
 suggested was a function called memzero_explicit(). There was a fair
 bit of discussion and the patch was accepted.

Do you have a pointer?

 In the crypto directory of the kernel source I have:
 
 $ grep memset *.c | wc -l
 133
 $
 
 I strongly suspect some of these should be fixed.

It seems this is a common topic:

  http://www.daemonology.net/blog/2014-09-04-how-to-zero-a-buffer.html

and part 2:

  
http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-is-insufficient.html

Summary:  It's not just the memory we should be concerned about, there's also
the stack and the registers.

memzero_explicit() is a good start, but I think the articles raise two
important points.  a) register data temporarily stored on the stack via
compiler optimizations, and b) aesni register contents left behind after
use.

I suspect (a) is an unquantified problem on embedded systems, and (b)
may extend to embedded hardware crypto implementations.

thx,

Jason.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: memset() in crypto code?

[Jason Cooper]

On Mon, Oct 06, 2014 at 01:59:06PM -0400, Sandy Harris wrote:
 On Mon, Oct 6, 2014 at 1:44 PM, Jason Cooper ja...@lakedaemon.net wrote:
 
  On Sat, Oct 04, 2014 at 11:09:40PM -0400, Sandy Harris wrote:
  There was recently a patch to the random driver to replace memset()
  because, according to the submitter, gcc sometimes optimises memset()
  away which might leave data unnecessarily exposed. The solution
  suggested was a function called memzero_explicit(). There was a fair
  bit of discussion and the patch was accepted.
 
  Do you have a pointer?
 
 https://lkml.org/lkml/2014/8/25/497

Ok, that was the same thread I found.  I was looking for the 'fair bit
of discussion' part. ;-)

thx,

Jason.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DMA support for mv_cesa

[Jason Cooper]

Muran,

+ free-electron's, mvebu maintainers

On Mon, Jul 28, 2014 at 03:24:43PM +0200, Muran Hrun wrote:
 What is the status of DMA support for mv_cesa? I tried applying the patches at
 git://nwl.cc/~n0-1/linux.git (cesa-dma branch)
 on kernel 3.15.6 but the kernel just crashed on my DNS-320, when
 accessing an encrypted volume. (Kernel 3.5rc2 in the respository did
 not boot at all)
 
 Is DMA support for mv_cesa still developed?

thx,

Jason.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] staging: crypto: skein: depend upon CRYPTO

[Jason Cooper]

Fengguang's randconfig kernel build tester discovered the following
warnings:

warning: (CRYPTO_THREEFISH) selects CRYPTO_ALGAPI which has unmet direct 
dependencies (CRYPTO)
warning: (DM_VERITY  CRYPTO_SKEIN) selects CRYPTO_HASH which has unmet direct 
dependencies (CRYPTO)

Fix this in the Kconfig by depending on CRYPTO.

Reported-by: Fengguang Wu fengguang...@intel.com
Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
 drivers/staging/skein/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/skein/Kconfig b/drivers/staging/skein/Kconfig
index 8f5a72a90ced..b9172bfcdc1b 100644
--- a/drivers/staging/skein/Kconfig
+++ b/drivers/staging/skein/Kconfig
@@ -1,6 +1,6 @@
 config CRYPTO_SKEIN
bool Skein digest algorithm
-   depends on (X86 || UML_X86)  64BIT
+   depends on (X86 || UML_X86)  64BIT  CRYPTO
select CRYPTO_THREEFISH
select CRYPTO_HASH
help
@@ -17,7 +17,7 @@ config CRYPTO_SKEIN
 
 config CRYPTO_THREEFISH
bool Threefish tweakable block cipher
-   depends on (X86 || UML_X86)  64BIT
+   depends on (X86 || UML_X86)  64BIT  CRYPTO
select CRYPTO_ALGAPI
help
  Threefish cipher algorithm is the tweakable block cipher underneath
-- 
1.9.2

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 19/21] staging: crypto: skein: remove braces from single-statement block

[Jason Cooper]

Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
 drivers/staging/skein/skeinApi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/skein/skeinApi.c b/drivers/staging/skein/skeinApi.c
index f0015d5b10f5..dd109bf6f7b9 100644
--- a/drivers/staging/skein/skeinApi.c
+++ b/drivers/staging/skein/skeinApi.c
@@ -188,9 +188,9 @@ int skeinUpdateBits(struct skein_ctx *ctx, const u8 *msg,
msgBitCnt == 0, SKEIN_FAIL);
 
/* if number of bits is a multiple of bytes - that's easy */
-   if ((msgBitCnt  0x7) == 0) {
+   if ((msgBitCnt  0x7) == 0)
return skeinUpdate(ctx, msg, msgBitCnt  3);
-   }
+
skeinUpdate(ctx, msg, (msgBitCnt  3) + 1);
 
/*
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 18/21] staging: crypto: skein: remove externs from .c files

[Jason Cooper]

Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
 drivers/staging/skein/include/skein_block.h | 22 ++
 drivers/staging/skein/skein.c   | 10 +-
 2 files changed, 23 insertions(+), 9 deletions(-)
 create mode 100644 drivers/staging/skein/include/skein_block.h

diff --git a/drivers/staging/skein/include/skein_block.h 
b/drivers/staging/skein/include/skein_block.h
new file mode 100644
index ..b15c079b5bd4
--- /dev/null
+++ b/drivers/staging/skein/include/skein_block.h
@@ -0,0 +1,22 @@
+/***
+**
+** Implementation of the Skein hash function.
+**
+** Source code author: Doug Whiting, 2008.
+**
+** This algorithm and source code is released to the public domain.
+**
+/
+#ifndef _SKEIN_BLOCK_H_
+#define _SKEIN_BLOCK_H_
+
+#include skein.h /* get the Skein API definitions   */
+
+void Skein_256_Process_Block(struct skein_256_ctx *ctx, const u8 *blkPtr,
+   size_t blkCnt, size_t byteCntAdd);
+void Skein_512_Process_Block(struct skein_512_ctx *ctx, const u8 *blkPtr,
+   size_t blkCnt, size_t byteCntAdd);
+void Skein1024_Process_Block(struct skein1024_ctx *ctx, const u8 *blkPtr,
+   size_t blkCnt, size_t byteCntAdd);
+
+#endif
diff --git a/drivers/staging/skein/skein.c b/drivers/staging/skein/skein.c
index 0d8c70c02c6f..096b86bf9430 100644
--- a/drivers/staging/skein/skein.c
+++ b/drivers/staging/skein/skein.c
@@ -13,15 +13,7 @@
 #include linux/string.h   /* get the memcpy/memset functions */
 #include skein.h /* get the Skein API definitions   */
 #include skein_iv.h/* get precomputed IVs */
-
-/*/
-/* External function to process blkCnt (nonzero) full block(s) of data. */
-void Skein_256_Process_Block(struct skein_256_ctx *ctx, const u8 *blkPtr,
-   size_t blkCnt, size_t byteCntAdd);
-void Skein_512_Process_Block(struct skein_512_ctx *ctx, const u8 *blkPtr,
-   size_t blkCnt, size_t byteCntAdd);
-void Skein1024_Process_Block(struct skein1024_ctx *ctx, const u8 *blkPtr,
-   size_t blkCnt, size_t byteCntAdd);
+#include skein_block.h
 
 /*/
 /* 256-bit Skein */
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 09/21] staging: crypto: skein: fixup pointer whitespace

[Jason Cooper]

Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
 drivers/staging/skein/include/skein.h| 18 +-
 drivers/staging/skein/include/skeinApi.h | 10 +-
 drivers/staging/skein/include/threefishApi.h | 22 +++---
 drivers/staging/skein/skeinApi.c | 18 +-
 drivers/staging/skein/threefish1024Block.c   |  4 ++--
 drivers/staging/skein/threefish256Block.c|  4 ++--
 drivers/staging/skein/threefish512Block.c|  4 ++--
 drivers/staging/skein/threefishApi.c | 20 ++--
 8 files changed, 50 insertions(+), 50 deletions(-)

diff --git a/drivers/staging/skein/include/skein.h 
b/drivers/staging/skein/include/skein.h
index 77b712e73253..b7cd6c0cef2f 100644
--- a/drivers/staging/skein/include/skein.h
+++ b/drivers/staging/skein/include/skein.h
@@ -100,9 +100,9 @@ int  Skein_256_Update(struct skein_256_ctx *ctx, const u8 
*msg, size_t msgByteCn
 int  Skein_512_Update(struct skein_512_ctx *ctx, const u8 *msg, size_t 
msgByteCnt);
 int  Skein1024_Update(struct skein1024_ctx *ctx, const u8 *msg, size_t 
msgByteCnt);
 
-int  Skein_256_Final (struct skein_256_ctx *ctx, u8 * hashVal);
-int  Skein_512_Final (struct skein_512_ctx *ctx, u8 * hashVal);
-int  Skein1024_Final (struct skein1024_ctx *ctx, u8 * hashVal);
+int  Skein_256_Final (struct skein_256_ctx *ctx, u8 *hashVal);
+int  Skein_512_Final (struct skein_512_ctx *ctx, u8 *hashVal);
+int  Skein1024_Final (struct skein1024_ctx *ctx, u8 *hashVal);
 
 /*
 **   Skein APIs for extended initialization: MAC keys, tree hashing.
@@ -127,17 +127,17 @@ int  Skein1024_InitExt(struct skein1024_ctx *ctx, size_t 
hashBitLen, u64 treeInf
 **  Final_Pad:  pad, do final block, but no OUTPUT type
 **  Output: do just the output stage
 */
-int  Skein_256_Final_Pad(struct skein_256_ctx *ctx, u8 * hashVal);
-int  Skein_512_Final_Pad(struct skein_512_ctx *ctx, u8 * hashVal);
-int  Skein1024_Final_Pad(struct skein1024_ctx *ctx, u8 * hashVal);
+int  Skein_256_Final_Pad(struct skein_256_ctx *ctx, u8 *hashVal);
+int  Skein_512_Final_Pad(struct skein_512_ctx *ctx, u8 *hashVal);
+int  Skein1024_Final_Pad(struct skein1024_ctx *ctx, u8 *hashVal);
 
 #ifndef SKEIN_TREE_HASH
 #define SKEIN_TREE_HASH (1)
 #endif
 #if  SKEIN_TREE_HASH
-int  Skein_256_Output   (struct skein_256_ctx *ctx, u8 * hashVal);
-int  Skein_512_Output   (struct skein_512_ctx *ctx, u8 * hashVal);
-int  Skein1024_Output   (struct skein1024_ctx *ctx, u8 * hashVal);
+int  Skein_256_Output   (struct skein_256_ctx *ctx, u8 *hashVal);
+int  Skein_512_Output   (struct skein_512_ctx *ctx, u8 *hashVal);
+int  Skein1024_Output   (struct skein1024_ctx *ctx, u8 *hashVal);
 #endif
 
 /*
diff --git a/drivers/staging/skein/include/skeinApi.h 
b/drivers/staging/skein/include/skeinApi.h
index 4ad294f7945d..2c52797918cf 100755
--- a/drivers/staging/skein/include/skeinApi.h
+++ b/drivers/staging/skein/include/skeinApi.h
@@ -123,7 +123,7 @@ OTHER DEALINGS IN THE SOFTWARE.
  * @return
  * SKEIN_SUCESS of SKEIN_FAIL
  */
-int skeinCtxPrepare(struct skein_ctx* ctx, enum skein_size size);
+int skeinCtxPrepare(struct skein_ctx *ctx, enum skein_size size);
 
 /**
  * Initialize a Skein context.
@@ -139,7 +139,7 @@ OTHER DEALINGS IN THE SOFTWARE.
  * SKEIN_SUCESS of SKEIN_FAIL
  * @see skeinReset
  */
-int skeinInit(struct skein_ctx* ctx, size_t hashBitLen);
+int skeinInit(struct skein_ctx *ctx, size_t hashBitLen);
 
 /**
  * Resets a Skein context for further use.
@@ -151,7 +151,7 @@ OTHER DEALINGS IN THE SOFTWARE.
  * @param ctx
  * Pointer to a pre-initialized Skein MAC context
  */
-void skeinReset(struct skein_ctx* ctx);
+void skeinReset(struct skein_ctx *ctx);
 
 /**
  * Initializes a Skein context for MAC usage.
@@ -173,7 +173,7 @@ OTHER DEALINGS IN THE SOFTWARE.
  * @return
  * SKEIN_SUCESS of SKEIN_FAIL
  */
-int skeinMacInit(struct skein_ctx* ctx, const u8 *key, size_t keyLen,
+int skeinMacInit(struct skein_ctx *ctx, const u8 *key, size_t keyLen,
  size_t hashBitLen);
 
 /**
@@ -222,7 +222,7 @@ OTHER DEALINGS IN THE SOFTWARE.
  * Success or error code.
  * @see skeinReset
  */
-int skeinFinal(struct skein_ctx* ctx, u8* hash);
+int skeinFinal(struct skein_ctx *ctx, u8 *hash);
 
 /**
  * @}
diff --git a/drivers/staging/skein/include/threefishApi.h 
b/drivers/staging/skein/include/threefishApi.h
index 194e313b6b62..1f9e6e14f50b 100644
--- a/drivers/staging/skein/include/threefishApi.h
+++ b/drivers/staging/skein/include/threefishApi.h
@@ -72,7 +72,7 @@
  * @param tweak
  * Pointer to the two tweak words (word has 64 bits).
  */
-void threefishSetKey(struct threefish_key* keyCtx, enum threefish_size 
stateSize, u64* keyData, u64* tweak);
+void threefishSetKey(struct threefish_key *keyCtx

[PATCH V2 02/21] staging: crypto: skein: allow building statically

[Jason Cooper]

These are the minimum changes required to get the code to build
statically in the kernel.  It's necessary to do this first so that we
can empirically determine that future cleanup patches aren't changing
the generated object code.

Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
Changes since RFC:

 - rebased onto staging-next caused conflicts in Kconfig and Makefile, fixed.


 drivers/staging/Kconfig  |  2 +
 drivers/staging/Makefile |  1 +
 drivers/staging/skein/CMakeLists.txt | 27 -
 drivers/staging/skein/Kconfig| 32 
 drivers/staging/skein/Makefile   | 13 +++
 drivers/staging/skein/include/brg_types.h| 57 
 drivers/staging/skein/include/skein.h| 10 -
 drivers/staging/skein/include/skeinApi.h |  2 +-
 drivers/staging/skein/include/skein_port.h   | 16 +---
 drivers/staging/skein/include/threefishApi.h |  2 +-
 drivers/staging/skein/skein.c|  2 +-
 drivers/staging/skein/skeinApi.c |  4 +-
 drivers/staging/skein/skeinBlockNo3F.c   |  2 +-
 drivers/staging/skein/skein_block.c  |  2 +-
 drivers/staging/skein/threefish1024Block.c   |  3 +-
 drivers/staging/skein/threefish256Block.c|  3 +-
 drivers/staging/skein/threefish512Block.c|  3 +-
 drivers/staging/skein/threefishApi.c |  3 +-
 18 files changed, 59 insertions(+), 125 deletions(-)
 delete mode 100755 drivers/staging/skein/CMakeLists.txt
 create mode 100644 drivers/staging/skein/Kconfig
 create mode 100644 drivers/staging/skein/Makefile

diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 47cf17543008..b78f669b7ed8 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -144,6 +144,8 @@ source drivers/staging/gs_fpgaboot/Kconfig
 
 source drivers/staging/nokia_h4p/Kconfig
 
+source drivers/staging/skein/Kconfig
+
 source drivers/staging/unisys/Kconfig
 
 endif # STAGING
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index d12f6189db46..eec54a9f53e8 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -64,4 +64,5 @@ obj-$(CONFIG_DGAP)+= dgap/
 obj-$(CONFIG_MTD_SPINAND_MT29F)+= mt29f_spinand/
 obj-$(CONFIG_GS_FPGABOOT)  += gs_fpgaboot/
 obj-$(CONFIG_BT_NOKIA_H4P) += nokia_h4p/
+obj-$(CONFIG_CRYPTO_SKEIN) += skein/
 obj-$(CONFIG_UNISYSSPAR)   += unisys/
diff --git a/drivers/staging/skein/CMakeLists.txt 
b/drivers/staging/skein/CMakeLists.txt
deleted file mode 100755
index 604aaa394cb1..
--- a/drivers/staging/skein/CMakeLists.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-cmake_minimum_required (VERSION 2.6)
-
-include_directories (${CMAKE_CURRENT_SOURCE_DIR}/include)
-
-# set(skeinBlock_src skein_block.c)
-set(skeinBlock_src skeinBlockNo3F.c)
-
-set(skein_src 
-${skeinBlock_src}
-skein.c
-skeinApi.c
-)
-
-set(threefish_src
-threefishApi.c
-threefish256Block.c
-threefish512Block.c
-threefish1024Block.c
-)
-set(s3f_src ${skein_src} ${threefish_src})
-
-add_library(skein3fish SHARED ${s3f_src})
-set_target_properties(skein3fish PROPERTIES VERSION ${VERSION} SOVERSION 
${SOVERSION})
-target_link_libraries(skein3fish ${LIBS})
-
-install(TARGETS skein3fish DESTINATION ${LIBDIRNAME})
-
diff --git a/drivers/staging/skein/Kconfig b/drivers/staging/skein/Kconfig
new file mode 100644
index ..8f5a72a90ced
--- /dev/null
+++ b/drivers/staging/skein/Kconfig
@@ -0,0 +1,32 @@
+config CRYPTO_SKEIN
+   bool Skein digest algorithm
+   depends on (X86 || UML_X86)  64BIT
+   select CRYPTO_THREEFISH
+   select CRYPTO_HASH
+   help
+ Skein secure hash algorithm is one of 5 finalists from the NIST SHA3
+ competition.
+
+ Skein is optimized for modern, 64bit processors and is highly
+ customizable.  See:
+
+ http://www.skein-hash.info/sites/default/files/skein1.3.pdf
+
+ for more information.  This module depends on the threefish block
+ cipher module.
+
+config CRYPTO_THREEFISH
+   bool Threefish tweakable block cipher
+   depends on (X86 || UML_X86)  64BIT
+   select CRYPTO_ALGAPI
+   help
+ Threefish cipher algorithm is the tweakable block cipher underneath
+ the Skein family of secure hash algorithms.  Skein is one of 5
+ finalists from the NIST SHA3 competition.
+
+ Skein is optimized for modern, 64bit processors and is highly
+ customizable.  See:
+
+ http://www.skein-hash.info/sites/default/files/skein1.3.pdf
+
+ for more information.
diff --git a/drivers/staging/skein/Makefile b/drivers/staging/skein/Makefile
new file mode 100644
index ..2bb386e1e58c
--- /dev/null
+++ b/drivers/staging/skein/Makefile
@@ -0,0 +1,13 @@
+#
+# Makefile for the skein secure hash algorithm
+#
+subdir-ccflags-y := -I$(src)/include/
+
+obj-$(CONFIG_CRYPTO_SKEIN

[PATCH V2 13/21] staging: crypto: skein: remove trailing whitespace

[Jason Cooper]

Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
 drivers/staging/skein/include/skein.h| 16 +-
 drivers/staging/skein/include/skeinApi.h | 44 ++--
 drivers/staging/skein/include/threefishApi.h | 40 -
 drivers/staging/skein/skeinBlockNo3F.c   |  6 ++--
 drivers/staging/skein/skein_block.c  | 20 ++---
 5 files changed, 63 insertions(+), 63 deletions(-)

diff --git a/drivers/staging/skein/include/skein.h 
b/drivers/staging/skein/include/skein.h
index 906bcee41c39..dd9a210cf5dd 100644
--- a/drivers/staging/skein/include/skein.h
+++ b/drivers/staging/skein/include/skein.h
@@ -9,7 +9,7 @@
 ** This algorithm and source code is released to the public domain.
 **
 ***
-** 
+**
 ** The following compile-time switches may be defined to control some
 ** tradeoffs between speed, code size, error checking, and security.
 **
@@ -20,8 +20,8 @@
 **[default: no callouts (no overhead)]
 **
 **  SKEIN_ERR_CHECK-- how error checking is handled inside Skein
-**code. If not defined, most error checking 
-**is disabled (for performance). Otherwise, 
+**code. If not defined, most error checking
+**is disabled (for performance). Otherwise,
 **the switch value is interpreted as:
 **0: use assert()  to flag errors
 **1: return SKEIN_FAIL to flag errors
@@ -109,12 +109,12 @@ int  Skein1024_Final(struct skein1024_ctx *ctx, u8 
*hashVal);
 **   After an InitExt() call, just use Update/Final calls as with Init().
 **
 **   Notes: Same parameters as _Init() calls, plus treeInfo/key/keyBytes.
-**  When keyBytes == 0 and treeInfo == SKEIN_SEQUENTIAL, 
+**  When keyBytes == 0 and treeInfo == SKEIN_SEQUENTIAL,
 **  the results of InitExt() are identical to calling Init().
 **  The function Init() may be called once to precompute the IV for
 **  a given hashBitLen value, then by saving a copy of the context
 **  the IV computation may be avoided in later calls.
-**  Similarly, the function InitExt() may be called once per MAC key 
+**  Similarly, the function InitExt() may be called once per MAC key
 **  to precompute the MAC IV, then a copy of the context saved and
 **  reused for each new MAC computation.
 **/
@@ -142,7 +142,7 @@ int  Skein1024_Output(struct skein1024_ctx *ctx, u8 
*hashVal);
 
 /*
 ** Internal Skein definitions
-**-- not needed for sequential hashing API, but will be 
+**-- not needed for sequential hashing API, but will be
 **   helpful for other uses of Skein (e.g., tree hash mode).
 **-- included here so that they can be shared between
 **   reference and optimized code.
@@ -269,8 +269,8 @@ int  Skein1024_Output(struct skein1024_ctx *ctx, u8 
*hashVal);
 /*
 ** Skein block function constants (shared across Ref and Opt code)
 **/
-enum
-   {   
+enum
+   {
/* Skein_256 round rotation constants */
R_256_0_0 = 14, R_256_0_1 = 16,
R_256_1_0 = 52, R_256_1_1 = 57,
diff --git a/drivers/staging/skein/include/skeinApi.h 
b/drivers/staging/skein/include/skeinApi.h
index 0d7d59eff460..ace931a67c23 100644
--- a/drivers/staging/skein/include/skeinApi.h
+++ b/drivers/staging/skein/include/skeinApi.h
@@ -36,46 +36,46 @@ OTHER DEALINGS IN THE SOFTWARE.
  * of Skein. The design and the way to use the functions follow the openSSL
  * design but at the same time take care of some Skein specific behaviour
  * and possibilities.
- * 
+ *
  * The functions enable applications to create a normal Skein hashes and
  * message authentication codes (MAC).
- * 
+ *
  * Using these functions is simple and straight forward:
- * 
+ *
  * @code
- * 
+ *
  * #include skeinApi.h
- * 
+ *
  * ...
  * struct skein_ctx ctx; // a Skein hash or MAC context
- * 
+ *
  * // prepare context, here for a Skein with a state size of 512 bits.
  * skeinCtxPrepare(ctx, Skein512);
- * 
+ *
  * // Initialize the context to set the requested hash length in bits
  * // here request a output hash size of 31 bits (Skein supports variable
  * // output sizes even very strange sizes)
  * skeinInit(ctx, 31);
- * 
+ *
  * // Now update Skein with any number of message bits. A function that
  * // takes a number of bytes is also available.
  * skeinUpdateBits(ctx, message, msgLength);
- * 
+ *
  * // Now get the result of the Skein hash. The output buffer must be
  * // large enough to hold the request number

[PATCH V2 04/21] staging: crypto: skein: remove skein_port.h

[Jason Cooper]

Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
 drivers/staging/skein/include/skein.h  |  14 +++-
 drivers/staging/skein/include/skein_port.h | 108 -
 drivers/staging/skein/skein.c  |  21 --
 3 files changed, 13 insertions(+), 130 deletions(-)
 delete mode 100644 drivers/staging/skein/include/skein_port.h

diff --git a/drivers/staging/skein/include/skein.h 
b/drivers/staging/skein/include/skein.h
index 315cdcd14413..211aca1b1036 100644
--- a/drivers/staging/skein/include/skein.h
+++ b/drivers/staging/skein/include/skein.h
@@ -33,7 +33,19 @@ extern C
 #endif
 
 #include stddef.h  /* get size_t definition */
-#include skein_port.h   /* get platform-specific definitions */
+
+typedef unsigned intuint_t; /* native unsigned integer */
+typedef uint8_t u08b_t; /*  8-bit unsigned integer */
+typedef uint64_tu64b_t; /* 64-bit unsigned integer */
+
+#ifndef RotL_64
+#define RotL_64(x,N)(((x)  (N)) | ((x)  (64-(N
+#endif
+
+/* below two prototype assume we are handed aligned data */
+#define Skein_Put64_LSB_First(dst08,src64,bCnt) memcpy(dst08,src64,bCnt)
+#define Skein_Get64_LSB_First(dst64,src08,wCnt) memcpy(dst64,src08,8*(wCnt))
+#define Skein_Swap64(w64)  (w64)
 
 enum
 {
diff --git a/drivers/staging/skein/include/skein_port.h 
b/drivers/staging/skein/include/skein_port.h
deleted file mode 100644
index e78c976dccc5..
--- a/drivers/staging/skein/include/skein_port.h
+++ /dev/null
@@ -1,108 +0,0 @@
-#ifndef _SKEIN_PORT_H_
-#define _SKEIN_PORT_H_
-/***
-**
-** Platform-specific definitions for Skein hash function.
-**
-** Source code author: Doug Whiting, 2008.
-**
-** This algorithm and source code is released to the public domain.
-**
-** Many thanks to Brian Gladman for his portable header files.
-**
-** To port Skein to an unsupported platform, change the definitions
-** in this file appropriately.
-** 
-/
-
-typedef unsigned intuint_t; /* native unsigned integer */
-typedef uint8_t u08b_t; /*  8-bit unsigned integer */
-typedef uint64_tu64b_t; /* 64-bit unsigned integer */
-
-#ifndef RotL_64
-#define RotL_64(x,N)(((x)  (N)) | ((x)  (64-(N
-#endif
-
-/*
- * Skein is natively little-endian (unlike SHA-xxx), for optimal
- * performance on x86 CPUs.  The Skein code requires the following
- * definitions for dealing with endianness:
- *
- *SKEIN_NEED_SWAP:  0 for little-endian, 1 for big-endian
- *Skein_Put64_LSB_First
- *Skein_Get64_LSB_First
- *Skein_Swap64
- *
- * If SKEIN_NEED_SWAP is defined at compile time, it is used here
- * along with the portable versions of Put64/Get64/Swap64, which 
- * are slow in general.
- *
- * Otherwise, an auto-detect of endianness is attempted below.
- * If the default handling doesn't work well, the user may insert
- * platform-specific code instead (e.g., for big-endian CPUs).
- *
- */
-#define SKEIN_NEED_SWAP   (0)
-/* below two prototype assume we are handed aligned data */
-#define Skein_Put64_LSB_First(dst08,src64,bCnt) memcpy(dst08,src64,bCnt)
-#define Skein_Get64_LSB_First(dst64,src08,wCnt) memcpy(dst64,src08,8*(wCnt))
-
-/*
- **
- *  Provide any definitions still needed.
- **
- */
-#ifndef Skein_Swap64  /* swap for big-endian, nop for little-endian */
-#if SKEIN_NEED_SWAP
-#define Skein_Swap64(w64)   \
-  ( (( ((u64b_t)(w64))0xFF)  56) |   \
-(u64b_t)(w64))  8)  0xFF)  48) |   \
-(u64b_t)(w64)) 16)  0xFF)  40) |   \
-(u64b_t)(w64)) 24)  0xFF)  32) |   \
-(u64b_t)(w64)) 32)  0xFF)  24) |   \
-(u64b_t)(w64)) 40)  0xFF)  16) |   \
-(u64b_t)(w64)) 48)  0xFF)   8) |   \
-(u64b_t)(w64)) 56)  0xFF)  ) )
-#else
-#define Skein_Swap64(w64)  (w64)
-#endif
-#endif  /* ifndef Skein_Swap64 */
-
-
-#ifndef Skein_Put64_LSB_First
-voidSkein_Put64_LSB_First(u08b_t *dst,const u64b_t *src,size_t bCnt)
-#ifdef  SKEIN_PORT_CODE /* instantiate the function code here? */
-{ /* this version is fully portable (big-endian or little-endian), but 
slow */
-size_t n;
-
-for (n=0;nbCnt;n++)
-dst[n] = (u08b_t) (src[n3]  (8*(n7)));
-}
-#else
-;/* output only the function prototype */
-#endif
-#endif   /* ifndef Skein_Put64_LSB_First */
-
-
-#ifndef Skein_Get64_LSB_First
-voidSkein_Get64_LSB_First(u64b_t *dst,const u08b_t *src,size_t wCnt)
-#ifdef  SKEIN_PORT_CODE /* instantiate the function code here? */
-{ /* this version is fully portable (big-endian or little-endian), but 
slow */
-size_t n;
-
-for (n=0;n8*wCnt;n+=8)
-dst[n/8] = (((u64b_t) src[n

[PATCH V2 06/21] staging: crypto: skein: remove unneeded typedefs

[Jason Cooper]

Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
 drivers/staging/skein/include/skein.h| 73 ++---
 drivers/staging/skein/include/skeinApi.h |  4 +-
 drivers/staging/skein/include/skein_iv.h | 26 
 drivers/staging/skein/include/threefishApi.h |  6 +-
 drivers/staging/skein/skein.c| 96 ++--
 drivers/staging/skein/skeinApi.c | 24 +++
 drivers/staging/skein/skeinBlockNo3F.c   | 30 -
 drivers/staging/skein/skein_block.c  | 54 
 drivers/staging/skein/threefishApi.c |  8 +--
 9 files changed, 159 insertions(+), 162 deletions(-)

diff --git a/drivers/staging/skein/include/skein.h 
b/drivers/staging/skein/include/skein.h
index b1e55b08d150..12c5c8d612b0 100644
--- a/drivers/staging/skein/include/skein.h
+++ b/drivers/staging/skein/include/skein.h
@@ -27,9 +27,6 @@
 **1: return SKEIN_FAIL to flag errors
 **
 ***/
-typedef unsigned intuint_t; /* native unsigned integer */
-typedef uint8_t u08b_t; /*  8-bit unsigned integer */
-typedef uint64_tu64b_t; /* 64-bit unsigned integer */
 
 #ifndef RotL_64
 #define RotL_64(x,N)(((x)  (N)) | ((x)  (64-(N
@@ -70,28 +67,28 @@ typedef struct
 {
 size_t  hashBitLen;  /* size of hash result, in bits */
 size_t  bCnt;/* current byte count in buffer 
b[] */
-u64b_t  T[SKEIN_MODIFIER_WORDS]; /* tweak words: T[0]=byte cnt, 
T[1]=flags */
+u64  T[SKEIN_MODIFIER_WORDS]; /* tweak words: T[0]=byte cnt, 
T[1]=flags */
 } Skein_Ctxt_Hdr_t;
 
 typedef struct   /*  256-bit Skein hash context 
structure */
 {
 Skein_Ctxt_Hdr_t h;  /* common header context 
variables */
-u64b_t  X[SKEIN_256_STATE_WORDS];/* chaining variables */
-u08b_t  b[SKEIN_256_BLOCK_BYTES];/* partial block buffer (8-byte 
aligned) */
+u64  X[SKEIN_256_STATE_WORDS];/* chaining variables */
+u8  b[SKEIN_256_BLOCK_BYTES];/* partial block buffer (8-byte 
aligned) */
 } Skein_256_Ctxt_t;
 
 typedef struct   /*  512-bit Skein hash context 
structure */
 {
 Skein_Ctxt_Hdr_t h;  /* common header context 
variables */
-u64b_t  X[SKEIN_512_STATE_WORDS];/* chaining variables */
-u08b_t  b[SKEIN_512_BLOCK_BYTES];/* partial block buffer (8-byte 
aligned) */
+u64  X[SKEIN_512_STATE_WORDS];/* chaining variables */
+u8  b[SKEIN_512_BLOCK_BYTES];/* partial block buffer (8-byte 
aligned) */
 } Skein_512_Ctxt_t;
 
 typedef struct   /* 1024-bit Skein hash context 
structure */
 {
 Skein_Ctxt_Hdr_t h;  /* common header context 
variables */
-u64b_t  X[SKEIN1024_STATE_WORDS];/* chaining variables */
-u08b_t  b[SKEIN1024_BLOCK_BYTES];/* partial block buffer (8-byte 
aligned) */
+u64  X[SKEIN1024_STATE_WORDS];/* chaining variables */
+u8  b[SKEIN1024_BLOCK_BYTES];/* partial block buffer (8-byte 
aligned) */
 } Skein1024_Ctxt_t;
 
 /*   Skein APIs for (incremental) straight hashing */
@@ -99,13 +96,13 @@ int  Skein_256_Init  (Skein_256_Ctxt_t *ctx, size_t 
hashBitLen);
 int  Skein_512_Init  (Skein_512_Ctxt_t *ctx, size_t hashBitLen);
 int  Skein1024_Init  (Skein1024_Ctxt_t *ctx, size_t hashBitLen);
 
-int  Skein_256_Update(Skein_256_Ctxt_t *ctx, const u08b_t *msg, size_t 
msgByteCnt);
-int  Skein_512_Update(Skein_512_Ctxt_t *ctx, const u08b_t *msg, size_t 
msgByteCnt);
-int  Skein1024_Update(Skein1024_Ctxt_t *ctx, const u08b_t *msg, size_t 
msgByteCnt);
+int  Skein_256_Update(Skein_256_Ctxt_t *ctx, const u8 *msg, size_t msgByteCnt);
+int  Skein_512_Update(Skein_512_Ctxt_t *ctx, const u8 *msg, size_t msgByteCnt);
+int  Skein1024_Update(Skein1024_Ctxt_t *ctx, const u8 *msg, size_t msgByteCnt);
 
-int  Skein_256_Final (Skein_256_Ctxt_t *ctx, u08b_t * hashVal);
-int  Skein_512_Final (Skein_512_Ctxt_t *ctx, u08b_t * hashVal);
-int  Skein1024_Final (Skein1024_Ctxt_t *ctx, u08b_t * hashVal);
+int  Skein_256_Final (Skein_256_Ctxt_t *ctx, u8 * hashVal);
+int  Skein_512_Final (Skein_512_Ctxt_t *ctx, u8 * hashVal);
+int  Skein1024_Final (Skein1024_Ctxt_t *ctx, u8 * hashVal);
 
 /*
 **   Skein APIs for extended initialization: MAC keys, tree hashing.
@@ -121,26 +118,26 @@ int  Skein1024_Final (Skein1024_Ctxt_t *ctx, u08b_t * 
hashVal);
 **  to precompute the MAC IV, then a copy of the context saved and
 **  reused for each new MAC computation.
 **/
-int  Skein_256_InitExt(Skein_256_Ctxt_t *ctx, size_t hashBitLen, u64b_t 
treeInfo, const u08b_t *key, size_t keyBytes);
-int  Skein_512_InitExt(Skein_512_Ctxt_t *ctx, size_t

[PATCH V2 15/21] staging: crypto: skein: fix do/while brace formatting

[Jason Cooper]

Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
 drivers/staging/skein/skein_block.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/skein/skein_block.c 
b/drivers/staging/skein/skein_block.c
index 780b4936f783..6e0f4a21aae3 100644
--- a/drivers/staging/skein/skein_block.c
+++ b/drivers/staging/skein/skein_block.c
@@ -215,8 +215,7 @@ void Skein_256_Process_Block(struct skein_256_ctx *ctx, 
const u8 *blkPtr,
Skein_Show_Round(BLK_BITS, ctx-h, SKEIN_RND_FEED_FWD, ctx-X);
 
ts[1] = ~SKEIN_T1_FLAG_FIRST;
-   }
-   while (--blkCnt);
+   } while (--blkCnt);
ctx-h.T[0] = ts[0];
ctx-h.T[1] = ts[1];
 }
@@ -434,8 +433,7 @@ void Skein_512_Process_Block(struct skein_512_ctx *ctx, 
const u8 *blkPtr,
Skein_Show_Round(BLK_BITS, ctx-h, SKEIN_RND_FEED_FWD, ctx-X);
 
ts[1] = ~SKEIN_T1_FLAG_FIRST;
-   }
-   while (--blkCnt);
+   } while (--blkCnt);
ctx-h.T[0] = ts[0];
ctx-h.T[1] = ts[1];
 }
@@ -717,8 +715,7 @@ void Skein1024_Process_Block(struct skein1024_ctx *ctx, 
const u8 *blkPtr, \
 
ts[1] = ~SKEIN_T1_FLAG_FIRST;
blkPtr += SKEIN1024_BLOCK_BYTES;
-   }
-   while (--blkCnt);
+   } while (--blkCnt);
ctx-h.T[0] = ts[0];
ctx-h.T[1] = ts[1];
 }
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 21/21] staging: crypto: skein: add TODO file

[Jason Cooper]

Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
 drivers/staging/skein/TODO | 11 +++
 1 file changed, 11 insertions(+)
 create mode 100644 drivers/staging/skein/TODO

diff --git a/drivers/staging/skein/TODO b/drivers/staging/skein/TODO
new file mode 100644
index ..f5c167a305ae
--- /dev/null
+++ b/drivers/staging/skein/TODO
@@ -0,0 +1,11 @@
+skein/threefish TODO
+
+ - rename camelcase vars
+ - rename camelcase functions
+ - rename files
+ - move macros into appropriate header files
+ - add / pass test vectors
+ - module support
+
+Please send patches to Jason Cooper ja...@lakedaemon.net in addition to the
+staging tree mailinglist.
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 05/21] staging: crypto: skein: remove __cplusplus and an unneeded stddef.h

[Jason Cooper]

Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
 drivers/staging/skein/include/skein.h| 11 ---
 drivers/staging/skein/include/skeinApi.h |  9 -
 drivers/staging/skein/include/threefishApi.h |  9 -
 3 files changed, 29 deletions(-)

diff --git a/drivers/staging/skein/include/skein.h 
b/drivers/staging/skein/include/skein.h
index 211aca1b1036..b1e55b08d150 100644
--- a/drivers/staging/skein/include/skein.h
+++ b/drivers/staging/skein/include/skein.h
@@ -27,13 +27,6 @@
 **1: return SKEIN_FAIL to flag errors
 **
 ***/
-#ifdef __cplusplus
-extern C
-{
-#endif
-
-#include stddef.h  /* get size_t definition */
-
 typedef unsigned intuint_t; /* native unsigned integer */
 typedef uint8_t u08b_t; /*  8-bit unsigned integer */
 typedef uint64_tu64b_t; /* 64-bit unsigned integer */
@@ -322,8 +315,4 @@ enum
 #define SKEIN1024_ROUNDS_TOTAL (8*SKEIN_ROUNDS) + 5) % 10) + 5))
 #endif
 
-#ifdef __cplusplus
-}
-#endif
-
 #endif  /* ifndef _SKEIN_H_ */
diff --git a/drivers/staging/skein/include/skeinApi.h 
b/drivers/staging/skein/include/skeinApi.h
index 734d27b79f01..f55c67e81f2b 100755
--- a/drivers/staging/skein/include/skeinApi.h
+++ b/drivers/staging/skein/include/skeinApi.h
@@ -81,11 +81,6 @@ OTHER DEALINGS IN THE SOFTWARE.
 #include linux/types.h
 #include skein.h
 
-#ifdef __cplusplus
-extern C
-{
-#endif
-
 /**
  * Which Skein size to use
  */
@@ -229,10 +224,6 @@ extern C
  */
 int skeinFinal(SkeinCtx_t* ctx, uint8_t* hash);
 
-#ifdef __cplusplus
-}
-#endif
-
 /**
  * @}
  */
diff --git a/drivers/staging/skein/include/threefishApi.h 
b/drivers/staging/skein/include/threefishApi.h
index dae270cf71d3..aaecfe822142 100644
--- a/drivers/staging/skein/include/threefishApi.h
+++ b/drivers/staging/skein/include/threefishApi.h
@@ -33,11 +33,6 @@
 
 #define KeyScheduleConst 0x1BD11BDAA9FC1A22L
 
-#ifdef __cplusplus
-extern C
-{
-#endif
-
 /**
  * Which Threefish size to use
  */
@@ -157,10 +152,6 @@ extern C
 void threefishDecrypt256(ThreefishKey_t* keyCtx, uint64_t* input, 
uint64_t* output);
 void threefishDecrypt512(ThreefishKey_t* keyCtx, uint64_t* input, 
uint64_t* output);
 void threefishDecrypt1024(ThreefishKey_t* keyCtx, uint64_t* input, 
uint64_t* output);
-#ifdef __cplusplus
-}
-#endif
-
 /**
  * @}
  */
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 00/21] staging: add skein/threefish crypto algos

[Jason Cooper]

Greg, all,

Changes from RFC:

 - dropped scripts/objdiff patch to be submitted separately

 - rebased onto staging-next and resolved conflicts

-- updated original text to reflect the above --

Attached is a series I've sat on for the past month and a half.

I'm hoping that by posting it in it's incomplete state, it will either a)
motivate me to finish hooking into the crypto API, or b) motivate someone else
to pitch in. ;-)

From patch 2, all commits build successfully.  In addition, using the script
I've submitted separately (objdiff), I can confirm that no object code was
harmed in this process.

I'm under no time crunch with this, and I add to it as I find time.  If Greg
wants to take it for v3.15, great.  Otherwise is fine as well.

Barring a few false-positives, this series makes the code checkpatch-clean, but
it is not ready for mainline as yet.  In particular, I really don't like the
adhoc macro definitions, nor the camelCase.

The plan is to get skein and threefish registered into the crypto API, build as
modules, and then move it to crypto/.

thx,

Jason.


Jason Cooper (21):
  staging: crypto: skein: import code from Skein3Fish.git
  staging: crypto: skein: allow building statically
  staging: crypto: skein: remove brg_*.h includes
  staging: crypto: skein: remove skein_port.h
  staging: crypto: skein: remove __cplusplus and an unneeded stddef.h
  staging: crypto: skein: remove unneeded typedefs
  staging: crypto: skein: remove all typedef {struct,enum}
  staging: crypto: skein: use u8, u64 vice uint*_t
  staging: crypto: skein: fixup pointer whitespace
  staging: crypto: skein: cleanup whitespace around operators/punc.
  staging: crypto: skein: dos2unix, remove executable perms
  staging: crypto: skein: fix leading whitespace
  staging: crypto: skein: remove trailing whitespace
  staging: crypto: skein: cleanup 80 character lines
  staging: crypto: skein: fix do/while brace formatting
  staging: crypto: skein: fix brace placement errors
  staging: crypto: skein: wrap multi-line macros in do-while loops
  staging: crypto: skein: remove externs from .c files
  staging: crypto: skein: remove braces from single-statement block
  staging: crypto: skein: remove unnecessary line continuation
  staging: crypto: skein: add TODO file

 drivers/staging/Kconfig  |2 +
 drivers/staging/Makefile |1 +
 drivers/staging/skein/Kconfig|   32 +
 drivers/staging/skein/Makefile   |   13 +
 drivers/staging/skein/TODO   |   11 +
 drivers/staging/skein/include/skein.h|  344 ++
 drivers/staging/skein/include/skeinApi.h |  230 ++
 drivers/staging/skein/include/skein_block.h  |   22 +
 drivers/staging/skein/include/skein_iv.h |  186 +
 drivers/staging/skein/include/threefishApi.h |  164 +
 drivers/staging/skein/skein.c|  880 +
 drivers/staging/skein/skeinApi.c |  237 ++
 drivers/staging/skein/skeinBlockNo3F.c   |  175 +
 drivers/staging/skein/skein_block.c  |  770 
 drivers/staging/skein/threefish1024Block.c   | 4900 ++
 drivers/staging/skein/threefish256Block.c| 1137 ++
 drivers/staging/skein/threefish512Block.c| 2223 
 drivers/staging/skein/threefishApi.c |   79 +
 18 files changed, 11406 insertions(+)
 create mode 100644 drivers/staging/skein/Kconfig
 create mode 100644 drivers/staging/skein/Makefile
 create mode 100644 drivers/staging/skein/TODO
 create mode 100644 drivers/staging/skein/include/skein.h
 create mode 100644 drivers/staging/skein/include/skeinApi.h
 create mode 100644 drivers/staging/skein/include/skein_block.h
 create mode 100644 drivers/staging/skein/include/skein_iv.h
 create mode 100644 drivers/staging/skein/include/threefishApi.h
 create mode 100644 drivers/staging/skein/skein.c
 create mode 100644 drivers/staging/skein/skeinApi.c
 create mode 100644 drivers/staging/skein/skeinBlockNo3F.c
 create mode 100644 drivers/staging/skein/skein_block.c
 create mode 100644 drivers/staging/skein/threefish1024Block.c
 create mode 100644 drivers/staging/skein/threefish256Block.c
 create mode 100644 drivers/staging/skein/threefish512Block.c
 create mode 100644 drivers/staging/skein/threefishApi.c

-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 03/21] staging: crypto: skein: remove brg_*.h includes

[Jason Cooper]

Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
 drivers/staging/skein/include/brg_endian.h | 148 -
 drivers/staging/skein/include/brg_types.h  | 131 -
 drivers/staging/skein/include/skein_port.h |   6 +-
 3 files changed, 2 insertions(+), 283 deletions(-)
 delete mode 100644 drivers/staging/skein/include/brg_endian.h
 delete mode 100644 drivers/staging/skein/include/brg_types.h

diff --git a/drivers/staging/skein/include/brg_endian.h 
b/drivers/staging/skein/include/brg_endian.h
deleted file mode 100644
index c03c7c5d1eb4..
--- a/drivers/staging/skein/include/brg_endian.h
+++ /dev/null
@@ -1,148 +0,0 @@
-/*
- ---
- Copyright (c) 2003, Dr Brian Gladman, Worcester, UK.   All rights reserved.
-
- LICENSE TERMS
-
- The free distribution and use of this software in both source and binary
- form is allowed (with or without changes) provided that:
-
-   1. distributions of this source code include the above copyright
-  notice, this list of conditions and the following disclaimer;
-
-   2. distributions in binary form include the above copyright
-  notice, this list of conditions and the following disclaimer
-  in the documentation and/or other associated materials;
-
-   3. the copyright holder's name is not used to endorse products
-  built using this software without specific written permission.
-
- ALTERNATIVELY, provided that this notice is retained in full, this product
- may be distributed under the terms of the GNU General Public License (GPL),
- in which case the provisions of the GPL apply INSTEAD OF those given above.
-
- DISCLAIMER
-
- This software is provided 'as is' with no explicit or implied warranties
- in respect of its properties, including, but not limited to, correctness
- and/or fitness for purpose.
- ---
- Issue 20/10/2006
-*/
-
-#ifndef BRG_ENDIAN_H
-#define BRG_ENDIAN_H
-
-#define IS_BIG_ENDIAN  4321 /* byte 0 is most significant (mc68k) */
-#define IS_LITTLE_ENDIAN   1234 /* byte 0 is least significant (i386) */
-
-/* Include files where endian defines and byteswap functions may reside */
-#if defined( __FreeBSD__ ) || defined( __OpenBSD__ ) || defined( __NetBSD__ )
-#  include sys/endian.h
-#elif defined( BSD )  ( BSD = 199103 ) || defined( __APPLE__ ) || \
-  defined( __CYGWIN32__ ) || defined( __DJGPP__ ) || defined( __osf__ )
-#  include machine/endian.h
-#elif defined( __linux__ ) || defined( __GNUC__ ) || defined( __GNU_LIBRARY__ )
-#  if !defined( __MINGW32__ )  !defined(AVR)
-#include endian.h
-#if !defined( __BEOS__ )
-#  include byteswap.h
-#endif
-#  endif
-#endif
-
-/* Now attempt to set the define for platform byte order using any  */
-/* of the four forms SYMBOL, _SYMBOL, __SYMBOL  __SYMBOL__, which  */
-/* seem to encompass most endian symbol definitions */
-
-#if defined( BIG_ENDIAN )  defined( LITTLE_ENDIAN )
-#  if defined( BYTE_ORDER )  BYTE_ORDER == BIG_ENDIAN
-#define PLATFORM_BYTE_ORDER IS_BIG_ENDIAN
-#  elif defined( BYTE_ORDER )  BYTE_ORDER == LITTLE_ENDIAN
-#define PLATFORM_BYTE_ORDER IS_LITTLE_ENDIAN
-#  endif
-#elif defined( BIG_ENDIAN )
-#  define PLATFORM_BYTE_ORDER IS_BIG_ENDIAN
-#elif defined( LITTLE_ENDIAN )
-#  define PLATFORM_BYTE_ORDER IS_LITTLE_ENDIAN
-#endif
-
-#if defined( _BIG_ENDIAN )  defined( _LITTLE_ENDIAN )
-#  if defined( _BYTE_ORDER )  _BYTE_ORDER == _BIG_ENDIAN
-#define PLATFORM_BYTE_ORDER IS_BIG_ENDIAN
-#  elif defined( _BYTE_ORDER )  _BYTE_ORDER == _LITTLE_ENDIAN
-#define PLATFORM_BYTE_ORDER IS_LITTLE_ENDIAN
-#  endif
-#elif defined( _BIG_ENDIAN )
-#  define PLATFORM_BYTE_ORDER IS_BIG_ENDIAN
-#elif defined( _LITTLE_ENDIAN )
-#  define PLATFORM_BYTE_ORDER IS_LITTLE_ENDIAN
-#endif
-
-#if defined( __BIG_ENDIAN )  defined( __LITTLE_ENDIAN )
-#  if defined( __BYTE_ORDER )  __BYTE_ORDER == __BIG_ENDIAN
-#define PLATFORM_BYTE_ORDER IS_BIG_ENDIAN
-#  elif defined( __BYTE_ORDER )  __BYTE_ORDER == __LITTLE_ENDIAN
-#define PLATFORM_BYTE_ORDER IS_LITTLE_ENDIAN
-#  endif
-#elif defined( __BIG_ENDIAN )
-#  define PLATFORM_BYTE_ORDER IS_BIG_ENDIAN
-#elif defined( __LITTLE_ENDIAN )
-#  define PLATFORM_BYTE_ORDER IS_LITTLE_ENDIAN
-#endif
-
-#if defined( __BIG_ENDIAN__ )  defined( __LITTLE_ENDIAN__ )
-#  if defined( __BYTE_ORDER__ )  __BYTE_ORDER__ == __BIG_ENDIAN__
-#define PLATFORM_BYTE_ORDER IS_BIG_ENDIAN
-#  elif defined( __BYTE_ORDER__ )  __BYTE_ORDER__ == __LITTLE_ENDIAN__
-#define PLATFORM_BYTE_ORDER IS_LITTLE_ENDIAN
-#  endif
-#elif defined( __BIG_ENDIAN__ )
-#  define PLATFORM_BYTE_ORDER IS_BIG_ENDIAN
-#elif defined( __LITTLE_ENDIAN__ )
-#  define PLATFORM_BYTE_ORDER IS_LITTLE_ENDIAN
-#endif
-
-/*  if the platform byte order could not be determined, then try to */
-/*  set this define using common machine defines*/
-#if !defined

[PATCH V2 17/21] staging: crypto: skein: wrap multi-line macros in do-while loops

[Jason Cooper]

Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
 drivers/staging/skein/skein_block.c | 66 -
 1 file changed, 51 insertions(+), 15 deletions(-)

diff --git a/drivers/staging/skein/skein_block.c 
b/drivers/staging/skein/skein_block.c
index 6e0f4a21aae3..707a21ae53c6 100644
--- a/drivers/staging/skein/skein_block.c
+++ b/drivers/staging/skein/skein_block.c
@@ -107,27 +107,36 @@ void Skein_256_Process_Block(struct skein_256_ctx *ctx, 
const u8 *blkPtr,
/* run the rounds */
 
 #define Round256(p0, p1, p2, p3, ROT, rNum)  \
+do { \
X##p0 += X##p1; X##p1 = RotL_64(X##p1, ROT##_0); X##p1 ^= X##p0; \
X##p2 += X##p3; X##p3 = RotL_64(X##p3, ROT##_1); X##p3 ^= X##p2; \
+} while (0)
 
 #if SKEIN_UNROLL_256 == 0
 #define R256(p0, p1, p2, p3, ROT, rNum) /* fully unrolled */ \
+do { \
Round256(p0, p1, p2, p3, ROT, rNum) \
-   Skein_Show_R_Ptr(BLK_BITS, ctx-h, rNum, Xptr);
+   Skein_Show_R_Ptr(BLK_BITS, ctx-h, rNum, Xptr); \
+} while (0)
 
 #define I256(R) \
+do { \
/* inject the key schedule value */ \
X0   += ks[((R)+1) % 5]; \
X1   += ks[((R)+2) % 5] + ts[((R)+1) % 3]; \
X2   += ks[((R)+3) % 5] + ts[((R)+2) % 3]; \
X3   += ks[((R)+4) % 5] + (R)+1;   \
-   Skein_Show_R_Ptr(BLK_BITS, ctx-h, SKEIN_RND_KEY_INJECT, Xptr);
+   Skein_Show_R_Ptr(BLK_BITS, ctx-h, SKEIN_RND_KEY_INJECT, Xptr); \
+} while (0)
 #else /* looping version */
 #define R256(p0, p1, p2, p3, ROT, rNum) \
+do { \
Round256(p0, p1, p2, p3, ROT, rNum) \
-   Skein_Show_R_Ptr(BLK_BITS, ctx-h, 4 * (r - 1) + rNum, Xptr);
+   Skein_Show_R_Ptr(BLK_BITS, ctx-h, 4 * (r - 1) + rNum, Xptr); \
+} while (0)
 
 #define I256(R) \
+do { \
/* inject the key schedule value */ \
X0   += ks[r+(R)+0]; \
X1   += ks[r+(R)+1] + ts[r+(R)+0]; \
@@ -136,12 +145,14 @@ void Skein_256_Process_Block(struct skein_256_ctx *ctx, 
const u8 *blkPtr,
/* rotate key schedule */ \
ks[r + (R) + 4]   = ks[r + (R) - 1]; \
ts[r + (R) + 2]   = ts[r + (R) - 1]; \
-   Skein_Show_R_Ptr(BLK_BITS, ctx-h, SKEIN_RND_KEY_INJECT, Xptr);
+   Skein_Show_R_Ptr(BLK_BITS, ctx-h, SKEIN_RND_KEY_INJECT, Xptr); \
+} while (0)
 
for (r = 1; r  2 * RCNT; r += 2 * SKEIN_UNROLL_256)
 #endif
{
 #define R256_8_rounds(R)  \
+do { \
R256(0, 1, 2, 3, R_256_0, 8 * (R) + 1);  \
R256(0, 3, 2, 1, R_256_1, 8 * (R) + 2);  \
R256(0, 1, 2, 3, R_256_2, 8 * (R) + 3);  \
@@ -151,7 +162,8 @@ void Skein_256_Process_Block(struct skein_256_ctx *ctx, 
const u8 *blkPtr,
R256(0, 3, 2, 1, R_256_5, 8 * (R) + 6);  \
R256(0, 1, 2, 3, R_256_6, 8 * (R) + 7);  \
R256(0, 3, 2, 1, R_256_7, 8 * (R) + 8);  \
-   I256(2 * (R) + 1);
+   I256(2 * (R) + 1); \
+} while (0)
 
R256_8_rounds(0);
 
@@ -311,17 +323,22 @@ void Skein_512_Process_Block(struct skein_512_ctx *ctx, 
const u8 *blkPtr,
 Xptr);
/* run the rounds */
 #define Round512(p0, p1, p2, p3, p4, p5, p6, p7, ROT, rNum) \
+do { \
X##p0 += X##p1; X##p1 = RotL_64(X##p1, ROT##_0); X##p1 ^= X##p0; \
X##p2 += X##p3; X##p3 = RotL_64(X##p3, ROT##_1); X##p3 ^= X##p2; \
X##p4 += X##p5; X##p5 = RotL_64(X##p5, ROT##_2); X##p5 ^= X##p4; \
X##p6 += X##p7; X##p7 = RotL_64(X##p7, ROT##_3); X##p7 ^= X##p6; \
+} while (0)
 
 #if SKEIN_UNROLL_512 == 0
 #define R512(p0, p1, p2, p3, p4, p5, p6, p7, ROT, rNum) /* unrolled */ \
+do { \
Round512(p0, p1, p2, p3, p4, p5, p6, p7, ROT, rNum) \
-   Skein_Show_R_Ptr(BLK_BITS, ctx-h, rNum, Xptr);
+   Skein_Show_R_Ptr(BLK_BITS, ctx-h, rNum, Xptr); \
+} while (0)
 
 #define I512(R) \
+do { \
/* inject the key schedule value */ \
X0   += ks[((R) + 1) % 9]; \
X1   += ks[((R) + 2) % 9]; \
@@ -331,13 +348,17 @@ void Skein_512_Process_Block(struct skein_512_ctx *ctx, 
const u8 *blkPtr,
X5   += ks[((R) + 6) % 9] + ts[((R) + 1) % 3]; \
X6   += ks[((R) + 7) % 9] + ts[((R) + 2) % 3]; \
X7   += ks[((R) + 8) % 9] + (R) + 1;   \
-   Skein_Show_R_Ptr(BLK_BITS, ctx-h, SKEIN_RND_KEY_INJECT, Xptr);
+   Skein_Show_R_Ptr(BLK_BITS, ctx-h, SKEIN_RND_KEY_INJECT, Xptr); \
+} while (0)
 #else /* looping version */
 #define R512(p0, p1, p2, p3, p4, p5, p6, p7, ROT, rNum) \
+do { \
Round512(p0, p1, p2, p3, p4, p5, p6, p7, ROT, rNum) \
-   Skein_Show_R_Ptr(BLK_BITS, ctx-h, 4 * (r - 1) + rNum, Xptr);
+   Skein_Show_R_Ptr(BLK_BITS, ctx-h, 4 * (r - 1) + rNum, Xptr); \
+} while (0)
 
 #define I512(R) \
+do { \
/* inject the key schedule value */ \
X0   += ks[r + (R) + 0]; \
X1   += ks[r + (R) + 1]; \
@@ -350,12 +371,14 @@ void Skein_512_Process_Block(struct skein_512_ctx *ctx, 
const u8 *blkPtr

[PATCH V2 16/21] staging: crypto: skein: fix brace placement errors

[Jason Cooper]

Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
 drivers/staging/skein/include/skein.h|  30 -
 drivers/staging/skein/include/skein_iv.h |  65 --
 drivers/staging/skein/skein.c| 111 ++-
 3 files changed, 74 insertions(+), 132 deletions(-)

diff --git a/drivers/staging/skein/include/skein.h 
b/drivers/staging/skein/include/skein.h
index f92dc40711d1..0a2abcecd2f7 100644
--- a/drivers/staging/skein/include/skein.h
+++ b/drivers/staging/skein/include/skein.h
@@ -37,12 +37,11 @@
 #define Skein_Get64_LSB_First(dst64, src08, wCnt) memcpy(dst64, src08, 
8*(wCnt))
 #define Skein_Swap64(w64)  (w64)
 
-enum
-   {
+enum {
SKEIN_SUCCESS =  0, /* return codes from Skein calls */
SKEIN_FAIL=  1,
SKEIN_BAD_HASHLEN =  2
-   };
+};
 
 #define  SKEIN_MODIFIER_WORDS   (2) /* number of modifier (tweak) words */
 
@@ -63,33 +62,29 @@ enum
 #define  SKEIN_512_BLOCK_BYTES  (8*SKEIN_512_STATE_WORDS)
 #define  SKEIN1024_BLOCK_BYTES  (8*SKEIN1024_STATE_WORDS)
 
-struct skein_ctx_hdr
-   {
+struct skein_ctx_hdr {
size_t  hashBitLen; /* size of hash result, in bits */
size_t  bCnt;   /* current byte count in buffer b[] */
u64  T[SKEIN_MODIFIER_WORDS];   /* tweak: T[0]=byte cnt, T[1]=flags */
-   };
+};
 
-struct skein_256_ctx /* 256-bit Skein hash context structure */
-   {
+struct skein_256_ctx { /* 256-bit Skein hash context structure */
struct skein_ctx_hdr h; /* common header context variables */
u64  X[SKEIN_256_STATE_WORDS];  /* chaining variables */
u8  b[SKEIN_256_BLOCK_BYTES];   /* partial block buf (8-byte aligned) */
-   };
+};
 
-struct skein_512_ctx /* 512-bit Skein hash context structure */
-   {
+struct skein_512_ctx { /* 512-bit Skein hash context structure */
struct skein_ctx_hdr h; /* common header context variables */
u64  X[SKEIN_512_STATE_WORDS];  /* chaining variables */
u8  b[SKEIN_512_BLOCK_BYTES];   /* partial block buf (8-byte aligned) */
-   };
+};
 
-struct skein1024_ctx /* 1024-bit Skein hash context structure */
-   {
+struct skein1024_ctx { /* 1024-bit Skein hash context structure */
struct skein_ctx_hdr h; /* common header context variables */
u64  X[SKEIN1024_STATE_WORDS];  /* chaining variables */
u8  b[SKEIN1024_BLOCK_BYTES];   /* partial block buf (8-byte aligned) */
-   };
+};
 
 /*   Skein APIs for (incremental) straight hashing */
 int  Skein_256_Init(struct skein_256_ctx *ctx, size_t hashBitLen);
@@ -296,8 +291,7 @@ int  Skein1024_Output(struct skein1024_ctx *ctx, u8 
*hashVal);
 /*
 ** Skein block function constants (shared across Ref and Opt code)
 **/
-enum
-   {
+enum {
/* Skein_256 round rotation constants */
R_256_0_0 = 14, R_256_0_1 = 16,
R_256_1_0 = 52, R_256_1_1 = 57,
@@ -335,7 +329,7 @@ enum
R1024_6_4 = 19, R1024_6_5 = 42, R1024_6_6 = 44, R1024_6_7 = 25,
R1024_7_0 =  9, R1024_7_1 = 48, R1024_7_2 = 35, R1024_7_3 = 52,
R1024_7_4 = 23, R1024_7_5 = 31, R1024_7_6 = 37, R1024_7_7 = 20
-   };
+};
 
 #ifndef SKEIN_ROUNDS
 #define SKEIN_256_ROUNDS_TOTAL (72)/* # rounds for diff block sizes */
diff --git a/drivers/staging/skein/include/skein_iv.h 
b/drivers/staging/skein/include/skein_iv.h
index a77c44d3..8dd5e4d88a1d 100644
--- a/drivers/staging/skein/include/skein_iv.h
+++ b/drivers/staging/skein/include/skein_iv.h
@@ -20,44 +20,39 @@
 #define MK_64 SKEIN_MK_64
 
 /* blkSize =  256 bits. hashSize =  128 bits */
-const u64 SKEIN_256_IV_128[] =
-   {
+const u64 SKEIN_256_IV_128[] = {
MK_64(0xE906, 0x964D7260),
MK_64(0x883DAAA7, 0x7C8D811C),
MK_64(0x10080DF4, 0x91960F7A),
MK_64(0xCCF7DDE5, 0xB45BC1C2)
-   };
+};
 
 /* blkSize =  256 bits. hashSize =  160 bits */
-const u64 SKEIN_256_IV_160[] =
-   {
+const u64 SKEIN_256_IV_160[] = {
MK_64(0x14202314, 0x72825E98),
MK_64(0x2AC4E9A2, 0x5A77E590),
MK_64(0xD47A5856, 0x8838D63E),
MK_64(0x2DD2E496, 0x8586AB7D)
-   };
+};
 
 /* blkSize =  256 bits. hashSize =  224 bits */
-const u64 SKEIN_256_IV_224[] =
-   {
+const u64 SKEIN_256_IV_224[] = {
MK_64(0xC6098A8C, 0x9AE5EA0B),
MK_64(0x876D5686, 0x08C5191C),
MK_64(0x99CB88D7, 0xD7F53884),
MK_64(0x384BDDB1, 0xAEDDB5DE)
-   };
+};
 
 /* blkSize =  256 bits. hashSize =  256 bits */
-const u64 SKEIN_256_IV_256[] =
-   {
+const u64 SKEIN_256_IV_256[] = {
MK_64(0xFC9DA860, 0xD048B449),
MK_64(0x2FCA6647, 0x9FA7D833),
MK_64(0xB33BC389, 0x6656840F),
MK_64(0x6A54E920, 0xFDE8DA69)
-   };
+};
 
 /* blkSize =  512 bits. hashSize =  128 bits */
-const

[PATCH V2 07/21] staging: crypto: skein: remove all typedef {struct,enum}

[Jason Cooper]

Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
 drivers/staging/skein/include/skein.h| 58 ++--
 drivers/staging/skein/include/skeinApi.h | 32 +++
 drivers/staging/skein/include/threefishApi.h | 32 +++
 drivers/staging/skein/skein.c| 42 ++--
 drivers/staging/skein/skeinApi.c | 16 
 drivers/staging/skein/skeinBlockNo3F.c   | 12 +++---
 drivers/staging/skein/skein_block.c  |  6 +--
 drivers/staging/skein/threefish1024Block.c   |  4 +-
 drivers/staging/skein/threefish256Block.c|  4 +-
 drivers/staging/skein/threefish512Block.c|  4 +-
 drivers/staging/skein/threefishApi.c | 10 ++---
 11 files changed, 110 insertions(+), 110 deletions(-)

diff --git a/drivers/staging/skein/include/skein.h 
b/drivers/staging/skein/include/skein.h
index 12c5c8d612b0..77b712e73253 100644
--- a/drivers/staging/skein/include/skein.h
+++ b/drivers/staging/skein/include/skein.h
@@ -63,46 +63,46 @@ enum
 #define  SKEIN_512_BLOCK_BYTES ( 8*SKEIN_512_STATE_WORDS)
 #define  SKEIN1024_BLOCK_BYTES ( 8*SKEIN1024_STATE_WORDS)
 
-typedef struct
+struct skein_ctx_hdr
 {
 size_t  hashBitLen;  /* size of hash result, in bits */
 size_t  bCnt;/* current byte count in buffer 
b[] */
 u64  T[SKEIN_MODIFIER_WORDS]; /* tweak words: T[0]=byte cnt, 
T[1]=flags */
-} Skein_Ctxt_Hdr_t;
+};
 
-typedef struct   /*  256-bit Skein hash context 
structure */
+struct skein_256_ctx   /*  256-bit Skein hash 
context structure */
 {
-Skein_Ctxt_Hdr_t h;  /* common header context 
variables */
+struct skein_ctx_hdr h;  /* common header context 
variables */
 u64  X[SKEIN_256_STATE_WORDS];/* chaining variables */
 u8  b[SKEIN_256_BLOCK_BYTES];/* partial block buffer (8-byte 
aligned) */
-} Skein_256_Ctxt_t;
+};
 
-typedef struct   /*  512-bit Skein hash context 
structure */
+struct skein_512_ctx /*  512-bit Skein hash 
context structure */
 {
-Skein_Ctxt_Hdr_t h;  /* common header context 
variables */
+struct skein_ctx_hdr h;  /* common header context 
variables */
 u64  X[SKEIN_512_STATE_WORDS];/* chaining variables */
 u8  b[SKEIN_512_BLOCK_BYTES];/* partial block buffer (8-byte 
aligned) */
-} Skein_512_Ctxt_t;
+};
 
-typedef struct   /* 1024-bit Skein hash context 
structure */
+struct skein1024_ctx  /* 1024-bit Skein hash 
context structure */
 {
-Skein_Ctxt_Hdr_t h;  /* common header context 
variables */
+struct skein_ctx_hdr h;  /* common header context 
variables */
 u64  X[SKEIN1024_STATE_WORDS];/* chaining variables */
 u8  b[SKEIN1024_BLOCK_BYTES];/* partial block buffer (8-byte 
aligned) */
-} Skein1024_Ctxt_t;
+};
 
 /*   Skein APIs for (incremental) straight hashing */
-int  Skein_256_Init  (Skein_256_Ctxt_t *ctx, size_t hashBitLen);
-int  Skein_512_Init  (Skein_512_Ctxt_t *ctx, size_t hashBitLen);
-int  Skein1024_Init  (Skein1024_Ctxt_t *ctx, size_t hashBitLen);
+int  Skein_256_Init  (struct skein_256_ctx *ctx, size_t hashBitLen);
+int  Skein_512_Init  (struct skein_512_ctx *ctx, size_t hashBitLen);
+int  Skein1024_Init  (struct skein1024_ctx *ctx, size_t hashBitLen);
 
-int  Skein_256_Update(Skein_256_Ctxt_t *ctx, const u8 *msg, size_t msgByteCnt);
-int  Skein_512_Update(Skein_512_Ctxt_t *ctx, const u8 *msg, size_t msgByteCnt);
-int  Skein1024_Update(Skein1024_Ctxt_t *ctx, const u8 *msg, size_t msgByteCnt);
+int  Skein_256_Update(struct skein_256_ctx *ctx, const u8 *msg, size_t 
msgByteCnt);
+int  Skein_512_Update(struct skein_512_ctx *ctx, const u8 *msg, size_t 
msgByteCnt);
+int  Skein1024_Update(struct skein1024_ctx *ctx, const u8 *msg, size_t 
msgByteCnt);
 
-int  Skein_256_Final (Skein_256_Ctxt_t *ctx, u8 * hashVal);
-int  Skein_512_Final (Skein_512_Ctxt_t *ctx, u8 * hashVal);
-int  Skein1024_Final (Skein1024_Ctxt_t *ctx, u8 * hashVal);
+int  Skein_256_Final (struct skein_256_ctx *ctx, u8 * hashVal);
+int  Skein_512_Final (struct skein_512_ctx *ctx, u8 * hashVal);
+int  Skein1024_Final (struct skein1024_ctx *ctx, u8 * hashVal);
 
 /*
 **   Skein APIs for extended initialization: MAC keys, tree hashing.
@@ -118,26 +118,26 @@ int  Skein1024_Final (Skein1024_Ctxt_t *ctx, u8 * 
hashVal);
 **  to precompute the MAC IV, then a copy of the context saved and
 **  reused for each new MAC computation.
 **/
-int  Skein_256_InitExt(Skein_256_Ctxt_t *ctx, size_t hashBitLen, u64 treeInfo, 
const u8 *key, size_t keyBytes);
-int  Skein_512_InitExt(Skein_512_Ctxt_t *ctx, size_t hashBitLen, u64 treeInfo

[PATCH V2 08/21] staging: crypto: skein: use u8, u64 vice uint*_t

[Jason Cooper]

Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
 drivers/staging/skein/include/skeinApi.h |  8 
 drivers/staging/skein/include/threefishApi.h | 22 +++---
 drivers/staging/skein/skeinApi.c | 22 +++---
 drivers/staging/skein/threefish1024Block.c   | 18 +-
 drivers/staging/skein/threefish256Block.c| 18 +-
 drivers/staging/skein/threefish512Block.c| 18 +-
 drivers/staging/skein/threefishApi.c | 20 ++--
 7 files changed, 63 insertions(+), 63 deletions(-)

diff --git a/drivers/staging/skein/include/skeinApi.h 
b/drivers/staging/skein/include/skeinApi.h
index 548c639431de..4ad294f7945d 100755
--- a/drivers/staging/skein/include/skeinApi.h
+++ b/drivers/staging/skein/include/skeinApi.h
@@ -173,7 +173,7 @@ OTHER DEALINGS IN THE SOFTWARE.
  * @return
  * SKEIN_SUCESS of SKEIN_FAIL
  */
-int skeinMacInit(struct skein_ctx* ctx, const uint8_t *key, size_t keyLen,
+int skeinMacInit(struct skein_ctx* ctx, const u8 *key, size_t keyLen,
  size_t hashBitLen);
 
 /**
@@ -188,7 +188,7 @@ OTHER DEALINGS IN THE SOFTWARE.
  * @return
  * Success or error code.
  */
-int skeinUpdate(struct skein_ctx *ctx, const uint8_t *msg,
+int skeinUpdate(struct skein_ctx *ctx, const u8 *msg,
 size_t msgByteCnt);
 
 /**
@@ -204,7 +204,7 @@ OTHER DEALINGS IN THE SOFTWARE.
  * @param msgBitCnt
  * Length of the message in @b bits.
  */
-int skeinUpdateBits(struct skein_ctx *ctx, const uint8_t *msg,
+int skeinUpdateBits(struct skein_ctx *ctx, const u8 *msg,
 size_t msgBitCnt);
 
 /**
@@ -222,7 +222,7 @@ OTHER DEALINGS IN THE SOFTWARE.
  * Success or error code.
  * @see skeinReset
  */
-int skeinFinal(struct skein_ctx* ctx, uint8_t* hash);
+int skeinFinal(struct skein_ctx* ctx, u8* hash);
 
 /**
  * @}
diff --git a/drivers/staging/skein/include/threefishApi.h 
b/drivers/staging/skein/include/threefishApi.h
index 4c1cd81f30c4..194e313b6b62 100644
--- a/drivers/staging/skein/include/threefishApi.h
+++ b/drivers/staging/skein/include/threefishApi.h
@@ -72,7 +72,7 @@
  * @param tweak
  * Pointer to the two tweak words (word has 64 bits).
  */
-void threefishSetKey(struct threefish_key* keyCtx, enum threefish_size 
stateSize, uint64_t* keyData, uint64_t* tweak);
+void threefishSetKey(struct threefish_key* keyCtx, enum threefish_size 
stateSize, u64* keyData, u64* tweak);
 
 /**
  * Encrypt Threefisch block (bytes).
@@ -89,7 +89,7 @@
  * @param out
  * Pointer to cipher buffer.
  */
-void threefishEncryptBlockBytes(struct threefish_key* keyCtx, uint8_t* in, 
uint8_t* out);
+void threefishEncryptBlockBytes(struct threefish_key* keyCtx, u8* in, u8* 
out);
 
 /**
  * Encrypt Threefisch block (words).
@@ -108,7 +108,7 @@
  * @param out
  * Pointer to cipher buffer.
  */
-void threefishEncryptBlockWords(struct threefish_key* keyCtx, uint64_t* 
in, uint64_t* out);
+void threefishEncryptBlockWords(struct threefish_key* keyCtx, u64* in, 
u64* out);
 
 /**
  * Decrypt Threefisch block (bytes).
@@ -125,7 +125,7 @@
  * @param out
  * Pointer to plaintext buffer.
  */
-void threefishDecryptBlockBytes(struct threefish_key* keyCtx, uint8_t* in, 
uint8_t* out);
+void threefishDecryptBlockBytes(struct threefish_key* keyCtx, u8* in, u8* 
out);
 
 /**
  * Decrypt Threefisch block (words).
@@ -144,14 +144,14 @@
  * @param out
  * Pointer to plaintext buffer.
  */
-void threefishDecryptBlockWords(struct threefish_key* keyCtx, uint64_t* 
in, uint64_t* out);
+void threefishDecryptBlockWords(struct threefish_key* keyCtx, u64* in, 
u64* out);
 
-void threefishEncrypt256(struct threefish_key* keyCtx, uint64_t* input, 
uint64_t* output);
-void threefishEncrypt512(struct threefish_key* keyCtx, uint64_t* input, 
uint64_t* output);
-void threefishEncrypt1024(struct threefish_key* keyCtx, uint64_t* input, 
uint64_t* output);
-void threefishDecrypt256(struct threefish_key* keyCtx, uint64_t* input, 
uint64_t* output);
-void threefishDecrypt512(struct threefish_key* keyCtx, uint64_t* input, 
uint64_t* output);
-void threefishDecrypt1024(struct threefish_key* keyCtx, uint64_t* input, 
uint64_t* output);
+void threefishEncrypt256(struct threefish_key* keyCtx, u64* input, u64* 
output);
+void threefishEncrypt512(struct threefish_key* keyCtx, u64* input, u64* 
output);
+void threefishEncrypt1024(struct threefish_key* keyCtx, u64* input, u64* 
output);
+void threefishDecrypt256(struct threefish_key* keyCtx, u64* input, u64* 
output);
+void threefishDecrypt512(struct threefish_key* keyCtx, u64* input, u64* 
output);
+void threefishDecrypt1024(struct threefish_key* keyCtx, u64

Re: [RFC PATCH 03/22] staging: crypto: skein: allow building statically

[Jason Cooper]

On Tue, Mar 18, 2014 at 02:28:20PM +, Greg KH wrote:
 On Tue, Mar 18, 2014 at 08:58:49AM -0400, Jason Cooper wrote:
  On Mon, Mar 17, 2014 at 02:52:52PM -0700, Greg KH wrote:
   On Tue, Mar 11, 2014 at 09:32:35PM +, Jason Cooper wrote:
These are the minimum changes required to get the code to build
statically in the kernel.  It's necessary to do this first so that we
can empirically determine that future cleanup patches aren't changing
the generated object code.

Signed-off-by: Jason Cooper ja...@lakedaemon.net
   
   This doesn't apply to my latest tree :(
  
  Ah, ok.  I'll rebase this series on the staging tree.

Done, submitted.

--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -65,3 +65,4 @@ obj-$(CONFIG_XILLYBUS)+= xillybus/
 obj-$(CONFIG_DGNC) += dgnc/
 obj-$(CONFIG_DGAP) += dgap/
 obj-$(CONFIG_MTD_SPINAND_MT29F)+= mt29f_spinand/
+obj-$(CONFIG_CRYPTO_SKEIN) += skein/
   
   Care to align these up with the way this file is formatted?
  
  Of course, not sure what happened there (well, other than the obvious
  :-P)

dabbit.  I thought I remembered everything.  I'll do a V3 of this patch.

   And I have no objection to taking the drivers/staging/ patches, the
   script looks useful, but I can't take it through the staging tree,
   sorry.
  
  Ok, I'll pull that out as a separate branch.

s/branch/patch/.  Done.

thx,

Jason.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V3 02/21] staging: crypto: skein: allow building statically

[Jason Cooper]

These are the minimum changes required to get the code to build
statically in the kernel.  It's necessary to do this first so that we
can empirically determine that future cleanup patches aren't changing
the generated object code.

Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
Changes since V2:

 - fixed whitespace in staging/Makefile (gregkh)

Changes since RFC:

 - rebased onto staging-next caused conflicts in Kconfig and Makefile, fixed.


 drivers/staging/Kconfig  |  2 +
 drivers/staging/Makefile |  1 +
 drivers/staging/skein/CMakeLists.txt | 27 -
 drivers/staging/skein/Kconfig| 32 
 drivers/staging/skein/Makefile   | 13 +++
 drivers/staging/skein/include/brg_types.h| 57 
 drivers/staging/skein/include/skein.h| 10 -
 drivers/staging/skein/include/skeinApi.h |  2 +-
 drivers/staging/skein/include/skein_port.h   | 16 +---
 drivers/staging/skein/include/threefishApi.h |  2 +-
 drivers/staging/skein/skein.c|  2 +-
 drivers/staging/skein/skeinApi.c |  4 +-
 drivers/staging/skein/skeinBlockNo3F.c   |  2 +-
 drivers/staging/skein/skein_block.c  |  2 +-
 drivers/staging/skein/threefish1024Block.c   |  3 +-
 drivers/staging/skein/threefish256Block.c|  3 +-
 drivers/staging/skein/threefish512Block.c|  3 +-
 drivers/staging/skein/threefishApi.c |  3 +-
 18 files changed, 59 insertions(+), 125 deletions(-)
 delete mode 100755 drivers/staging/skein/CMakeLists.txt
 create mode 100644 drivers/staging/skein/Kconfig
 create mode 100644 drivers/staging/skein/Makefile

diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 47cf17543008..b78f669b7ed8 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -144,6 +144,8 @@ source drivers/staging/gs_fpgaboot/Kconfig
 
 source drivers/staging/nokia_h4p/Kconfig
 
+source drivers/staging/skein/Kconfig
+
 source drivers/staging/unisys/Kconfig
 
 endif # STAGING
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index d12f6189db46..fc05783bb7da 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -64,4 +64,5 @@ obj-$(CONFIG_DGAP)+= dgap/
 obj-$(CONFIG_MTD_SPINAND_MT29F)+= mt29f_spinand/
 obj-$(CONFIG_GS_FPGABOOT)  += gs_fpgaboot/
 obj-$(CONFIG_BT_NOKIA_H4P) += nokia_h4p/
+obj-$(CONFIG_CRYPTO_SKEIN) += skein/
 obj-$(CONFIG_UNISYSSPAR)   += unisys/
diff --git a/drivers/staging/skein/CMakeLists.txt 
b/drivers/staging/skein/CMakeLists.txt
deleted file mode 100755
index 604aaa394cb1..
--- a/drivers/staging/skein/CMakeLists.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-cmake_minimum_required (VERSION 2.6)
-
-include_directories (${CMAKE_CURRENT_SOURCE_DIR}/include)
-
-# set(skeinBlock_src skein_block.c)
-set(skeinBlock_src skeinBlockNo3F.c)
-
-set(skein_src 
-${skeinBlock_src}
-skein.c
-skeinApi.c
-)
-
-set(threefish_src
-threefishApi.c
-threefish256Block.c
-threefish512Block.c
-threefish1024Block.c
-)
-set(s3f_src ${skein_src} ${threefish_src})
-
-add_library(skein3fish SHARED ${s3f_src})
-set_target_properties(skein3fish PROPERTIES VERSION ${VERSION} SOVERSION 
${SOVERSION})
-target_link_libraries(skein3fish ${LIBS})
-
-install(TARGETS skein3fish DESTINATION ${LIBDIRNAME})
-
diff --git a/drivers/staging/skein/Kconfig b/drivers/staging/skein/Kconfig
new file mode 100644
index ..8f5a72a90ced
--- /dev/null
+++ b/drivers/staging/skein/Kconfig
@@ -0,0 +1,32 @@
+config CRYPTO_SKEIN
+   bool Skein digest algorithm
+   depends on (X86 || UML_X86)  64BIT
+   select CRYPTO_THREEFISH
+   select CRYPTO_HASH
+   help
+ Skein secure hash algorithm is one of 5 finalists from the NIST SHA3
+ competition.
+
+ Skein is optimized for modern, 64bit processors and is highly
+ customizable.  See:
+
+ http://www.skein-hash.info/sites/default/files/skein1.3.pdf
+
+ for more information.  This module depends on the threefish block
+ cipher module.
+
+config CRYPTO_THREEFISH
+   bool Threefish tweakable block cipher
+   depends on (X86 || UML_X86)  64BIT
+   select CRYPTO_ALGAPI
+   help
+ Threefish cipher algorithm is the tweakable block cipher underneath
+ the Skein family of secure hash algorithms.  Skein is one of 5
+ finalists from the NIST SHA3 competition.
+
+ Skein is optimized for modern, 64bit processors and is highly
+ customizable.  See:
+
+ http://www.skein-hash.info/sites/default/files/skein1.3.pdf
+
+ for more information.
diff --git a/drivers/staging/skein/Makefile b/drivers/staging/skein/Makefile
new file mode 100644
index ..2bb386e1e58c
--- /dev/null
+++ b/drivers/staging/skein/Makefile
@@ -0,0 +1,13 @@
+#
+# Makefile for the skein secure hash algorithm

Re: [RFC PATCH 03/22] staging: crypto: skein: allow building statically

[Jason Cooper]

On Mon, Mar 17, 2014 at 02:52:52PM -0700, Greg KH wrote:
 On Tue, Mar 11, 2014 at 09:32:35PM +, Jason Cooper wrote:
  These are the minimum changes required to get the code to build
  statically in the kernel.  It's necessary to do this first so that we
  can empirically determine that future cleanup patches aren't changing
  the generated object code.
  
  Signed-off-by: Jason Cooper ja...@lakedaemon.net
 
 This doesn't apply to my latest tree :(

Ah, ok.  I'll rebase this series on the staging tree.

  --- a/drivers/staging/Makefile
  +++ b/drivers/staging/Makefile
  @@ -65,3 +65,4 @@ obj-$(CONFIG_XILLYBUS)+= xillybus/
   obj-$(CONFIG_DGNC) += dgnc/
   obj-$(CONFIG_DGAP) += dgap/
   obj-$(CONFIG_MTD_SPINAND_MT29F)+= mt29f_spinand/
  +obj-$(CONFIG_CRYPTO_SKEIN) += skein/
 
 Care to align these up with the way this file is formatted?

Of course, not sure what happened there (well, other than the obvious
:-P)

 And I have no objection to taking the drivers/staging/ patches, the
 script looks useful, but I can't take it through the staging tree,
 sorry.

Ok, I'll pull that out as a separate branch.  Do you mind taking a
series that depends on a topic branch from another tree?  We do it a lot
in arm-soc, but I'm not sure how popular that is elsewhere.

It's purely an audit/testing dependency, but it would be nice to have it
available in the history if someone wants to audit the changes.

I have one change I'd like to do to the objdiff script.  I'd like it to
assume 'HEAD^ HEAD' when the user executes './scripts/objdiff diff'.

I'll respin both and submit a v1.

Thanks for the review.

thx,

Jason.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 00/22] staging: add skein/threefish crypto algos

[Jason Cooper]

On Tue, Mar 11, 2014 at 09:32:32PM +, Jason Cooper wrote:
 To facilitate tinkering with this, One can pull from the following:
 
   git://git.infradead.org/users/jcooper/linux.git tags/staging-skein-3.14-rc1
 
 This is based on v3.14-rc1, and is prone to rebasing based on comments.

Hmmm, apparently, I forgot to tell you *how* to tinker with this :)

Once you've pulled in the series,

$ make ARCH=x86_64 defconfig

enable CRYPTO_SKEIN (implies CRYPTO_THREEFISH) under drivers/staging.

$ git rebase -i v3.14-rc1

In the rebase config file:

###
pick cc77327 scripts: objdiff: detect object code changes between two commits
pick bdb4dad staging: crypto: skein: import code from Skein3Fish.git
pick e3d822c staging: crypto: skein: allow building statically
x kbuild.sh none
x ./scripts/objdiff record drivers/staging/skein/*.o

pick 227c819 staging: crypto: skein: remove brg_*.h includes
x kbuild.sh none
x ./scripts/objdiff record drivers/staging/skein/*.o
x ./scripts/objdiff diff HEAD^ HEAD

pick c175303 staging: crypto: skein: remove skein_port.h
x kbuild.sh none
x ./scripts/objdiff record drivers/staging/skein/*.o
x ./scripts/objdiff diff HEAD^ HEAD

pick a612f45 staging: crypto: skein: remove __cplusplus and an unneeded stddef.h
x kbuild.sh none
x ./scripts/objdiff record drivers/staging/skein/*.o
x ./scripts/objdiff diff HEAD^ HEAD

... lather, rinse, repeat ...

pick 4438372 staging: crypto: skein: remove unnecessary line continuation
x kbuild.sh none
x ./scripts/objdiff record drivers/staging/skein/*.o
x ./scripts/objdiff diff HEAD^ HEAD

pick 641f05d staging: crypto: skein: add TODO file
x kbuild.sh none
x ./scripts/objdiff record drivers/staging/skein/*.o
x ./scripts/objdiff diff HEAD^ HEAD

...
###

Save, quit, let it run (kbuild.sh is my local script for building the
kernel)

If it makes it to the end, then the object code never changed.  Well, it
works here. ;-)

Once you're finished poking around (objdump output in is
/tmp/objdiff-commit/):

$ ./scripts/objdiff clean all

Also, it looks like linux-crypto dropped several of the patches for
being too large.  Here's a link to the top of the series (choose the
linuxdriverproject archive):

https://lkml.kernel.org/r/cover.1394570067.git.ja...@lakedaemon.net

hth,

Jason.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 00/22] staging: add skein/threefish crypto algos

[Jason Cooper]

Greg, all,

Attached is a series I've sat on for the past month and a half.

I'm hoping that by posting it in it's incomplete state, it will either a)
motivate me to finish hooking into the crypto API, or b) motivate someone else
to pitch in. ;-)

From patch 3, all commits build successfully.  In addition, using the script I
added in patch 1, I can confirm that no object code was harmed in this process.

I'm under no time crunch with this, and I add to it as I find time.  If Greg
wants to take it for v3.15, great.  Otherwise is fine as well.  It's been a
while since I watched the inner workings of the staging tree, so I'm not
familiar with how strict it is recently.

Barring a few false-positives, this series makes the code checkpatch-clean, but
it is not ready for mainline as yet.  In particular, I really don't like the
adhoc macro definitions, nor the camelCase.

The plan is to get skein and threefish registered into the crypto API, build as
modules, and then move it to crypto/.

To facilitate tinkering with this, One can pull from the following:

  git://git.infradead.org/users/jcooper/linux.git tags/staging-skein-3.14-rc1

This is based on v3.14-rc1, and is prone to rebasing based on comments.

thx,

Jason.

Jason Cooper (22):
  scripts: objdiff: detect object code changes between two commits
  staging: crypto: skein: import code from Skein3Fish.git
  staging: crypto: skein: allow building statically
  staging: crypto: skein: remove brg_*.h includes
  staging: crypto: skein: remove skein_port.h
  staging: crypto: skein: remove __cplusplus and an unneeded stddef.h
  staging: crypto: skein: remove unneeded typedefs
  staging: crypto: skein: remove all typedef {struct,enum}
  staging: crypto: skein: use u8, u64 vice uint*_t
  staging: crypto: skein: fixup pointer whitespace
  staging: crypto: skein: cleanup whitespace around operators/punc.
  staging: crypto: skein: dos2unix, remove executable perms
  staging: crypto: skein: fix leading whitespace
  staging: crypto: skein: remove trailing whitespace
  staging: crypto: skein: cleanup 80 character lines
  staging: crypto: skein: fix do/while brace formatting
  staging: crypto: skein: fix brace placement errors
  staging: crypto: skein: wrap multi-line macros in do-while loops
  staging: crypto: skein: remove externs from .c files
  staging: crypto: skein: remove braces from single-statement block
  staging: crypto: skein: remove unnecessary line continuation
  staging: crypto: skein: add TODO file

 drivers/staging/Kconfig  |2 +
 drivers/staging/Makefile |1 +
 drivers/staging/skein/Kconfig|   32 +
 drivers/staging/skein/Makefile   |   13 +
 drivers/staging/skein/TODO   |   11 +
 drivers/staging/skein/include/skein.h|  344 ++
 drivers/staging/skein/include/skeinApi.h |  230 ++
 drivers/staging/skein/include/skein_block.h  |   22 +
 drivers/staging/skein/include/skein_iv.h |  186 +
 drivers/staging/skein/include/threefishApi.h |  164 +
 drivers/staging/skein/skein.c|  880 +
 drivers/staging/skein/skeinApi.c |  237 ++
 drivers/staging/skein/skeinBlockNo3F.c   |  175 +
 drivers/staging/skein/skein_block.c  |  770 
 drivers/staging/skein/threefish1024Block.c   | 4900 ++
 drivers/staging/skein/threefish256Block.c| 1137 ++
 drivers/staging/skein/threefish512Block.c| 2223 
 drivers/staging/skein/threefishApi.c |   79 +
 scripts/objdiff  |  126 +
 19 files changed, 11532 insertions(+)
 create mode 100644 drivers/staging/skein/Kconfig
 create mode 100644 drivers/staging/skein/Makefile
 create mode 100644 drivers/staging/skein/TODO
 create mode 100644 drivers/staging/skein/include/skein.h
 create mode 100644 drivers/staging/skein/include/skeinApi.h
 create mode 100644 drivers/staging/skein/include/skein_block.h
 create mode 100644 drivers/staging/skein/include/skein_iv.h
 create mode 100644 drivers/staging/skein/include/threefishApi.h
 create mode 100644 drivers/staging/skein/skein.c
 create mode 100644 drivers/staging/skein/skeinApi.c
 create mode 100644 drivers/staging/skein/skeinBlockNo3F.c
 create mode 100644 drivers/staging/skein/skein_block.c
 create mode 100644 drivers/staging/skein/threefish1024Block.c
 create mode 100644 drivers/staging/skein/threefish256Block.c
 create mode 100644 drivers/staging/skein/threefish512Block.c
 create mode 100644 drivers/staging/skein/threefishApi.c
 create mode 100755 scripts/objdiff

-- 
1.9.0

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 01/22] scripts: objdiff: detect object code changes between two commits

[Jason Cooper]

objdiff is useful when doing large code cleanups.  For example, when
removing checkpatch warnings and errors from new drivers in the staging
tree.

objdiff can be used in conjunction with a git rebase to confirm that
each commit made no changes to the resulting object code.  It has the
same return values as diff(1).

This was written specifically to support adding the skein and threefish
cryto drivers to the staging tree.  I needed a programmatic way to
confirm that commits changing 90% of the lines didn't inadvertently
change the code.

Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
 scripts/objdiff | 126 
 1 file changed, 126 insertions(+)
 create mode 100755 scripts/objdiff

diff --git a/scripts/objdiff b/scripts/objdiff
new file mode 100755
index ..9e1ad8df2d07
--- /dev/null
+++ b/scripts/objdiff
@@ -0,0 +1,126 @@
+#!/bin/bash
+
+# objdiff - a small script for validating that a commit or series of commits
+# didn't change object code.
+#
+# Copyright 2014, Jason Cooper ja...@lakedaemon.net
+#
+# Licensed under the terms of the GNU GPL version 2
+
+# usage example:
+#
+# $ git checkout COMMIT_A
+# $ your fancy build command here
+# $ ./scripts/objdiff record path/to/*.o
+#
+# $ git checkout COMMIT_B
+# $ your fancy build command here
+# $ ./scripts/objdiff record path/to/*.o
+#
+# $ ./scripts/objdiff diff COMMIT_A COMMIT_B
+# $
+
+# And to clean up (everything is in /tmp/objdiff-*)
+# $ ./scripts/objdiff clean all
+
+usage() {
+   echo Usage: $0 command args
+   echo   recordlist of object files
+   echo   diff  commitA commitB
+   echo   clean all | commit
+   exit 1
+}
+
+dorecord() {
+   [ $# -eq 0 ]  usage
+
+   FILES=$*
+
+   CMT=`git rev-parse --short HEAD`
+
+   OBJDUMP=${CROSS_COMPILE}objdump
+   OBJDIFFD=/tmp/objdiff-$CMT
+
+   [ ! -d $OBJDIFFD ]  mkdir -p $OBJDIFFD
+
+   for f in $FILES; do
+   dn=${f%/*}
+   bn=${f##*/}
+
+   [ ! -d $OBJDIFFD/$dn ]  mkdir -p $OBJDIFFD/$dn
+
+   # remove addresses for a more clear diff
+   # 
http://dummdida.tumblr.com/post/60924060451/binary-diff-between-libc-from-scientificlinux-and
+   $OBJDUMP -D $f | sed s/^[[:space:]]\+[0-9a-f]\+// \
+   $OBJDIFFD/$dn/$bn
+
+   # force rebuild
+   rm -f $f
+   done
+}
+
+dodiff() {
+   [ $# -ne 2 ]  usage
+
+   SRC=`git rev-parse --short $1`
+   DST=`git rev-parse --short $2`
+
+   DIFF=`which colordiff`
+
+   if [ ${#DIFF} -eq 0 ] || [ ! -x $DIFF ]; then
+   DIFF=`which diff`
+   fi
+
+   SRCD=/tmp/objdiff-$SRC
+   DSTD=/tmp/objdiff-$DST
+
+   if [ ! -d $SRCD ]; then
+   echo ERROR: $SRCD doesn't exist
+   exit 1
+   fi
+
+   if [ ! -d $DSTD ]; then
+   echo ERROR: $DSTD doesn't exist
+   exit 1
+   fi
+
+   $DIFF -Nurd $SRCD $DSTD
+}
+
+doclean() {
+   [ $# -eq 0 ]  usage
+   [ $# -gt 1 ]  usage
+
+   if [ x$1 = xall ]; then
+   rm -rf /tmp/objdiff-*
+   else
+   CMT=`git rev-parse --short $1`
+
+   if [ -d /tmp/objdiff-$CMT ]; then
+   rm -rf /tmp/objdiff-$CMT
+   else
+   echo $CMT not found
+   fi
+   fi
+}
+
+[ $# -eq 0 ] usage
+
+case $1 in
+   record)
+   shift
+   dorecord $*
+   ;;
+   diff)
+   shift
+   dodiff $*
+   ;;
+   clean)
+   shift
+   doclean $*
+   ;;
+   *)
+   echo Unrecognized command '$1'
+   exit 1
+   ;;
+esac
-- 
1.9.0

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 03/22] staging: crypto: skein: allow building statically

[Jason Cooper]

These are the minimum changes required to get the code to build
statically in the kernel.  It's necessary to do this first so that we
can empirically determine that future cleanup patches aren't changing
the generated object code.

Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
 drivers/staging/Kconfig  |  2 +
 drivers/staging/Makefile |  1 +
 drivers/staging/skein/CMakeLists.txt | 27 -
 drivers/staging/skein/Kconfig| 32 
 drivers/staging/skein/Makefile   | 13 +++
 drivers/staging/skein/include/brg_types.h| 57 
 drivers/staging/skein/include/skein.h| 10 -
 drivers/staging/skein/include/skeinApi.h |  2 +-
 drivers/staging/skein/include/skein_port.h   | 16 +---
 drivers/staging/skein/include/threefishApi.h |  2 +-
 drivers/staging/skein/skein.c|  2 +-
 drivers/staging/skein/skeinApi.c |  4 +-
 drivers/staging/skein/skeinBlockNo3F.c   |  2 +-
 drivers/staging/skein/skein_block.c  |  2 +-
 drivers/staging/skein/threefish1024Block.c   |  3 +-
 drivers/staging/skein/threefish256Block.c|  3 +-
 drivers/staging/skein/threefish512Block.c|  3 +-
 drivers/staging/skein/threefishApi.c |  3 +-
 18 files changed, 59 insertions(+), 125 deletions(-)
 delete mode 100755 drivers/staging/skein/CMakeLists.txt
 create mode 100644 drivers/staging/skein/Kconfig
 create mode 100644 drivers/staging/skein/Makefile

diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 99375f0a9440..fbcbe833dc89 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -146,4 +146,6 @@ source drivers/staging/dgnc/Kconfig
 
 source drivers/staging/dgap/Kconfig
 
+source drivers/staging/skein/Kconfig
+
 endif # STAGING
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index ddc3c4a5d39d..2dee51d1a483 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -65,3 +65,4 @@ obj-$(CONFIG_XILLYBUS)+= xillybus/
 obj-$(CONFIG_DGNC) += dgnc/
 obj-$(CONFIG_DGAP) += dgap/
 obj-$(CONFIG_MTD_SPINAND_MT29F)+= mt29f_spinand/
+obj-$(CONFIG_CRYPTO_SKEIN) += skein/
diff --git a/drivers/staging/skein/CMakeLists.txt 
b/drivers/staging/skein/CMakeLists.txt
deleted file mode 100755
index 604aaa394cb1..
--- a/drivers/staging/skein/CMakeLists.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-cmake_minimum_required (VERSION 2.6)
-
-include_directories (${CMAKE_CURRENT_SOURCE_DIR}/include)
-
-# set(skeinBlock_src skein_block.c)
-set(skeinBlock_src skeinBlockNo3F.c)
-
-set(skein_src 
-${skeinBlock_src}
-skein.c
-skeinApi.c
-)
-
-set(threefish_src
-threefishApi.c
-threefish256Block.c
-threefish512Block.c
-threefish1024Block.c
-)
-set(s3f_src ${skein_src} ${threefish_src})
-
-add_library(skein3fish SHARED ${s3f_src})
-set_target_properties(skein3fish PROPERTIES VERSION ${VERSION} SOVERSION 
${SOVERSION})
-target_link_libraries(skein3fish ${LIBS})
-
-install(TARGETS skein3fish DESTINATION ${LIBDIRNAME})
-
diff --git a/drivers/staging/skein/Kconfig b/drivers/staging/skein/Kconfig
new file mode 100644
index ..8f5a72a90ced
--- /dev/null
+++ b/drivers/staging/skein/Kconfig
@@ -0,0 +1,32 @@
+config CRYPTO_SKEIN
+   bool Skein digest algorithm
+   depends on (X86 || UML_X86)  64BIT
+   select CRYPTO_THREEFISH
+   select CRYPTO_HASH
+   help
+ Skein secure hash algorithm is one of 5 finalists from the NIST SHA3
+ competition.
+
+ Skein is optimized for modern, 64bit processors and is highly
+ customizable.  See:
+
+ http://www.skein-hash.info/sites/default/files/skein1.3.pdf
+
+ for more information.  This module depends on the threefish block
+ cipher module.
+
+config CRYPTO_THREEFISH
+   bool Threefish tweakable block cipher
+   depends on (X86 || UML_X86)  64BIT
+   select CRYPTO_ALGAPI
+   help
+ Threefish cipher algorithm is the tweakable block cipher underneath
+ the Skein family of secure hash algorithms.  Skein is one of 5
+ finalists from the NIST SHA3 competition.
+
+ Skein is optimized for modern, 64bit processors and is highly
+ customizable.  See:
+
+ http://www.skein-hash.info/sites/default/files/skein1.3.pdf
+
+ for more information.
diff --git a/drivers/staging/skein/Makefile b/drivers/staging/skein/Makefile
new file mode 100644
index ..2bb386e1e58c
--- /dev/null
+++ b/drivers/staging/skein/Makefile
@@ -0,0 +1,13 @@
+#
+# Makefile for the skein secure hash algorithm
+#
+subdir-ccflags-y := -I$(src)/include/
+
+obj-$(CONFIG_CRYPTO_SKEIN) +=   skein.o \
+   skeinApi.o \
+   skein_block.o
+
+obj-$(CONFIG_CRYPTO_THREEFISH) += threefish1024Block.o

[RFC PATCH 16/22] staging: crypto: skein: fix do/while brace formatting

[Jason Cooper]

Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
 drivers/staging/skein/skein_block.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/skein/skein_block.c 
b/drivers/staging/skein/skein_block.c
index 780b4936f783..6e0f4a21aae3 100644
--- a/drivers/staging/skein/skein_block.c
+++ b/drivers/staging/skein/skein_block.c
@@ -215,8 +215,7 @@ void Skein_256_Process_Block(struct skein_256_ctx *ctx, 
const u8 *blkPtr,
Skein_Show_Round(BLK_BITS, ctx-h, SKEIN_RND_FEED_FWD, ctx-X);
 
ts[1] = ~SKEIN_T1_FLAG_FIRST;
-   }
-   while (--blkCnt);
+   } while (--blkCnt);
ctx-h.T[0] = ts[0];
ctx-h.T[1] = ts[1];
 }
@@ -434,8 +433,7 @@ void Skein_512_Process_Block(struct skein_512_ctx *ctx, 
const u8 *blkPtr,
Skein_Show_Round(BLK_BITS, ctx-h, SKEIN_RND_FEED_FWD, ctx-X);
 
ts[1] = ~SKEIN_T1_FLAG_FIRST;
-   }
-   while (--blkCnt);
+   } while (--blkCnt);
ctx-h.T[0] = ts[0];
ctx-h.T[1] = ts[1];
 }
@@ -717,8 +715,7 @@ void Skein1024_Process_Block(struct skein1024_ctx *ctx, 
const u8 *blkPtr, \
 
ts[1] = ~SKEIN_T1_FLAG_FIRST;
blkPtr += SKEIN1024_BLOCK_BYTES;
-   }
-   while (--blkCnt);
+   } while (--blkCnt);
ctx-h.T[0] = ts[0];
ctx-h.T[1] = ts[1];
 }
-- 
1.9.0

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 18/22] staging: crypto: skein: wrap multi-line macros in do-while loops

[Jason Cooper]

Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
 drivers/staging/skein/skein_block.c | 66 -
 1 file changed, 51 insertions(+), 15 deletions(-)

diff --git a/drivers/staging/skein/skein_block.c 
b/drivers/staging/skein/skein_block.c
index 6e0f4a21aae3..707a21ae53c6 100644
--- a/drivers/staging/skein/skein_block.c
+++ b/drivers/staging/skein/skein_block.c
@@ -107,27 +107,36 @@ void Skein_256_Process_Block(struct skein_256_ctx *ctx, 
const u8 *blkPtr,
/* run the rounds */
 
 #define Round256(p0, p1, p2, p3, ROT, rNum)  \
+do { \
X##p0 += X##p1; X##p1 = RotL_64(X##p1, ROT##_0); X##p1 ^= X##p0; \
X##p2 += X##p3; X##p3 = RotL_64(X##p3, ROT##_1); X##p3 ^= X##p2; \
+} while (0)
 
 #if SKEIN_UNROLL_256 == 0
 #define R256(p0, p1, p2, p3, ROT, rNum) /* fully unrolled */ \
+do { \
Round256(p0, p1, p2, p3, ROT, rNum) \
-   Skein_Show_R_Ptr(BLK_BITS, ctx-h, rNum, Xptr);
+   Skein_Show_R_Ptr(BLK_BITS, ctx-h, rNum, Xptr); \
+} while (0)
 
 #define I256(R) \
+do { \
/* inject the key schedule value */ \
X0   += ks[((R)+1) % 5]; \
X1   += ks[((R)+2) % 5] + ts[((R)+1) % 3]; \
X2   += ks[((R)+3) % 5] + ts[((R)+2) % 3]; \
X3   += ks[((R)+4) % 5] + (R)+1;   \
-   Skein_Show_R_Ptr(BLK_BITS, ctx-h, SKEIN_RND_KEY_INJECT, Xptr);
+   Skein_Show_R_Ptr(BLK_BITS, ctx-h, SKEIN_RND_KEY_INJECT, Xptr); \
+} while (0)
 #else /* looping version */
 #define R256(p0, p1, p2, p3, ROT, rNum) \
+do { \
Round256(p0, p1, p2, p3, ROT, rNum) \
-   Skein_Show_R_Ptr(BLK_BITS, ctx-h, 4 * (r - 1) + rNum, Xptr);
+   Skein_Show_R_Ptr(BLK_BITS, ctx-h, 4 * (r - 1) + rNum, Xptr); \
+} while (0)
 
 #define I256(R) \
+do { \
/* inject the key schedule value */ \
X0   += ks[r+(R)+0]; \
X1   += ks[r+(R)+1] + ts[r+(R)+0]; \
@@ -136,12 +145,14 @@ void Skein_256_Process_Block(struct skein_256_ctx *ctx, 
const u8 *blkPtr,
/* rotate key schedule */ \
ks[r + (R) + 4]   = ks[r + (R) - 1]; \
ts[r + (R) + 2]   = ts[r + (R) - 1]; \
-   Skein_Show_R_Ptr(BLK_BITS, ctx-h, SKEIN_RND_KEY_INJECT, Xptr);
+   Skein_Show_R_Ptr(BLK_BITS, ctx-h, SKEIN_RND_KEY_INJECT, Xptr); \
+} while (0)
 
for (r = 1; r  2 * RCNT; r += 2 * SKEIN_UNROLL_256)
 #endif
{
 #define R256_8_rounds(R)  \
+do { \
R256(0, 1, 2, 3, R_256_0, 8 * (R) + 1);  \
R256(0, 3, 2, 1, R_256_1, 8 * (R) + 2);  \
R256(0, 1, 2, 3, R_256_2, 8 * (R) + 3);  \
@@ -151,7 +162,8 @@ void Skein_256_Process_Block(struct skein_256_ctx *ctx, 
const u8 *blkPtr,
R256(0, 3, 2, 1, R_256_5, 8 * (R) + 6);  \
R256(0, 1, 2, 3, R_256_6, 8 * (R) + 7);  \
R256(0, 3, 2, 1, R_256_7, 8 * (R) + 8);  \
-   I256(2 * (R) + 1);
+   I256(2 * (R) + 1); \
+} while (0)
 
R256_8_rounds(0);
 
@@ -311,17 +323,22 @@ void Skein_512_Process_Block(struct skein_512_ctx *ctx, 
const u8 *blkPtr,
 Xptr);
/* run the rounds */
 #define Round512(p0, p1, p2, p3, p4, p5, p6, p7, ROT, rNum) \
+do { \
X##p0 += X##p1; X##p1 = RotL_64(X##p1, ROT##_0); X##p1 ^= X##p0; \
X##p2 += X##p3; X##p3 = RotL_64(X##p3, ROT##_1); X##p3 ^= X##p2; \
X##p4 += X##p5; X##p5 = RotL_64(X##p5, ROT##_2); X##p5 ^= X##p4; \
X##p6 += X##p7; X##p7 = RotL_64(X##p7, ROT##_3); X##p7 ^= X##p6; \
+} while (0)
 
 #if SKEIN_UNROLL_512 == 0
 #define R512(p0, p1, p2, p3, p4, p5, p6, p7, ROT, rNum) /* unrolled */ \
+do { \
Round512(p0, p1, p2, p3, p4, p5, p6, p7, ROT, rNum) \
-   Skein_Show_R_Ptr(BLK_BITS, ctx-h, rNum, Xptr);
+   Skein_Show_R_Ptr(BLK_BITS, ctx-h, rNum, Xptr); \
+} while (0)
 
 #define I512(R) \
+do { \
/* inject the key schedule value */ \
X0   += ks[((R) + 1) % 9]; \
X1   += ks[((R) + 2) % 9]; \
@@ -331,13 +348,17 @@ void Skein_512_Process_Block(struct skein_512_ctx *ctx, 
const u8 *blkPtr,
X5   += ks[((R) + 6) % 9] + ts[((R) + 1) % 3]; \
X6   += ks[((R) + 7) % 9] + ts[((R) + 2) % 3]; \
X7   += ks[((R) + 8) % 9] + (R) + 1;   \
-   Skein_Show_R_Ptr(BLK_BITS, ctx-h, SKEIN_RND_KEY_INJECT, Xptr);
+   Skein_Show_R_Ptr(BLK_BITS, ctx-h, SKEIN_RND_KEY_INJECT, Xptr); \
+} while (0)
 #else /* looping version */
 #define R512(p0, p1, p2, p3, p4, p5, p6, p7, ROT, rNum) \
+do { \
Round512(p0, p1, p2, p3, p4, p5, p6, p7, ROT, rNum) \
-   Skein_Show_R_Ptr(BLK_BITS, ctx-h, 4 * (r - 1) + rNum, Xptr);
+   Skein_Show_R_Ptr(BLK_BITS, ctx-h, 4 * (r - 1) + rNum, Xptr); \
+} while (0)
 
 #define I512(R) \
+do { \
/* inject the key schedule value */ \
X0   += ks[r + (R) + 0]; \
X1   += ks[r + (R) + 1]; \
@@ -350,12 +371,14 @@ void Skein_512_Process_Block(struct skein_512_ctx *ctx, 
const u8 *blkPtr

[RFC PATCH 17/22] staging: crypto: skein: fix brace placement errors

[Jason Cooper]

Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
 drivers/staging/skein/include/skein.h|  30 -
 drivers/staging/skein/include/skein_iv.h |  65 --
 drivers/staging/skein/skein.c| 111 ++-
 3 files changed, 74 insertions(+), 132 deletions(-)

diff --git a/drivers/staging/skein/include/skein.h 
b/drivers/staging/skein/include/skein.h
index f92dc40711d1..0a2abcecd2f7 100644
--- a/drivers/staging/skein/include/skein.h
+++ b/drivers/staging/skein/include/skein.h
@@ -37,12 +37,11 @@
 #define Skein_Get64_LSB_First(dst64, src08, wCnt) memcpy(dst64, src08, 
8*(wCnt))
 #define Skein_Swap64(w64)  (w64)
 
-enum
-   {
+enum {
SKEIN_SUCCESS =  0, /* return codes from Skein calls */
SKEIN_FAIL=  1,
SKEIN_BAD_HASHLEN =  2
-   };
+};
 
 #define  SKEIN_MODIFIER_WORDS   (2) /* number of modifier (tweak) words */
 
@@ -63,33 +62,29 @@ enum
 #define  SKEIN_512_BLOCK_BYTES  (8*SKEIN_512_STATE_WORDS)
 #define  SKEIN1024_BLOCK_BYTES  (8*SKEIN1024_STATE_WORDS)
 
-struct skein_ctx_hdr
-   {
+struct skein_ctx_hdr {
size_t  hashBitLen; /* size of hash result, in bits */
size_t  bCnt;   /* current byte count in buffer b[] */
u64  T[SKEIN_MODIFIER_WORDS];   /* tweak: T[0]=byte cnt, T[1]=flags */
-   };
+};
 
-struct skein_256_ctx /* 256-bit Skein hash context structure */
-   {
+struct skein_256_ctx { /* 256-bit Skein hash context structure */
struct skein_ctx_hdr h; /* common header context variables */
u64  X[SKEIN_256_STATE_WORDS];  /* chaining variables */
u8  b[SKEIN_256_BLOCK_BYTES];   /* partial block buf (8-byte aligned) */
-   };
+};
 
-struct skein_512_ctx /* 512-bit Skein hash context structure */
-   {
+struct skein_512_ctx { /* 512-bit Skein hash context structure */
struct skein_ctx_hdr h; /* common header context variables */
u64  X[SKEIN_512_STATE_WORDS];  /* chaining variables */
u8  b[SKEIN_512_BLOCK_BYTES];   /* partial block buf (8-byte aligned) */
-   };
+};
 
-struct skein1024_ctx /* 1024-bit Skein hash context structure */
-   {
+struct skein1024_ctx { /* 1024-bit Skein hash context structure */
struct skein_ctx_hdr h; /* common header context variables */
u64  X[SKEIN1024_STATE_WORDS];  /* chaining variables */
u8  b[SKEIN1024_BLOCK_BYTES];   /* partial block buf (8-byte aligned) */
-   };
+};
 
 /*   Skein APIs for (incremental) straight hashing */
 int  Skein_256_Init(struct skein_256_ctx *ctx, size_t hashBitLen);
@@ -296,8 +291,7 @@ int  Skein1024_Output(struct skein1024_ctx *ctx, u8 
*hashVal);
 /*
 ** Skein block function constants (shared across Ref and Opt code)
 **/
-enum
-   {
+enum {
/* Skein_256 round rotation constants */
R_256_0_0 = 14, R_256_0_1 = 16,
R_256_1_0 = 52, R_256_1_1 = 57,
@@ -335,7 +329,7 @@ enum
R1024_6_4 = 19, R1024_6_5 = 42, R1024_6_6 = 44, R1024_6_7 = 25,
R1024_7_0 =  9, R1024_7_1 = 48, R1024_7_2 = 35, R1024_7_3 = 52,
R1024_7_4 = 23, R1024_7_5 = 31, R1024_7_6 = 37, R1024_7_7 = 20
-   };
+};
 
 #ifndef SKEIN_ROUNDS
 #define SKEIN_256_ROUNDS_TOTAL (72)/* # rounds for diff block sizes */
diff --git a/drivers/staging/skein/include/skein_iv.h 
b/drivers/staging/skein/include/skein_iv.h
index a77c44d3..8dd5e4d88a1d 100644
--- a/drivers/staging/skein/include/skein_iv.h
+++ b/drivers/staging/skein/include/skein_iv.h
@@ -20,44 +20,39 @@
 #define MK_64 SKEIN_MK_64
 
 /* blkSize =  256 bits. hashSize =  128 bits */
-const u64 SKEIN_256_IV_128[] =
-   {
+const u64 SKEIN_256_IV_128[] = {
MK_64(0xE906, 0x964D7260),
MK_64(0x883DAAA7, 0x7C8D811C),
MK_64(0x10080DF4, 0x91960F7A),
MK_64(0xCCF7DDE5, 0xB45BC1C2)
-   };
+};
 
 /* blkSize =  256 bits. hashSize =  160 bits */
-const u64 SKEIN_256_IV_160[] =
-   {
+const u64 SKEIN_256_IV_160[] = {
MK_64(0x14202314, 0x72825E98),
MK_64(0x2AC4E9A2, 0x5A77E590),
MK_64(0xD47A5856, 0x8838D63E),
MK_64(0x2DD2E496, 0x8586AB7D)
-   };
+};
 
 /* blkSize =  256 bits. hashSize =  224 bits */
-const u64 SKEIN_256_IV_224[] =
-   {
+const u64 SKEIN_256_IV_224[] = {
MK_64(0xC6098A8C, 0x9AE5EA0B),
MK_64(0x876D5686, 0x08C5191C),
MK_64(0x99CB88D7, 0xD7F53884),
MK_64(0x384BDDB1, 0xAEDDB5DE)
-   };
+};
 
 /* blkSize =  256 bits. hashSize =  256 bits */
-const u64 SKEIN_256_IV_256[] =
-   {
+const u64 SKEIN_256_IV_256[] = {
MK_64(0xFC9DA860, 0xD048B449),
MK_64(0x2FCA6647, 0x9FA7D833),
MK_64(0xB33BC389, 0x6656840F),
MK_64(0x6A54E920, 0xFDE8DA69)
-   };
+};
 
 /* blkSize =  512 bits. hashSize =  128 bits */
-const

[RFC PATCH 10/22] staging: crypto: skein: fixup pointer whitespace

[Jason Cooper]

Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
 drivers/staging/skein/include/skein.h| 18 +-
 drivers/staging/skein/include/skeinApi.h | 10 +-
 drivers/staging/skein/include/threefishApi.h | 22 +++---
 drivers/staging/skein/skeinApi.c | 18 +-
 drivers/staging/skein/threefish1024Block.c   |  4 ++--
 drivers/staging/skein/threefish256Block.c|  4 ++--
 drivers/staging/skein/threefish512Block.c|  4 ++--
 drivers/staging/skein/threefishApi.c | 20 ++--
 8 files changed, 50 insertions(+), 50 deletions(-)

diff --git a/drivers/staging/skein/include/skein.h 
b/drivers/staging/skein/include/skein.h
index 77b712e73253..b7cd6c0cef2f 100644
--- a/drivers/staging/skein/include/skein.h
+++ b/drivers/staging/skein/include/skein.h
@@ -100,9 +100,9 @@ int  Skein_256_Update(struct skein_256_ctx *ctx, const u8 
*msg, size_t msgByteCn
 int  Skein_512_Update(struct skein_512_ctx *ctx, const u8 *msg, size_t 
msgByteCnt);
 int  Skein1024_Update(struct skein1024_ctx *ctx, const u8 *msg, size_t 
msgByteCnt);
 
-int  Skein_256_Final (struct skein_256_ctx *ctx, u8 * hashVal);
-int  Skein_512_Final (struct skein_512_ctx *ctx, u8 * hashVal);
-int  Skein1024_Final (struct skein1024_ctx *ctx, u8 * hashVal);
+int  Skein_256_Final (struct skein_256_ctx *ctx, u8 *hashVal);
+int  Skein_512_Final (struct skein_512_ctx *ctx, u8 *hashVal);
+int  Skein1024_Final (struct skein1024_ctx *ctx, u8 *hashVal);
 
 /*
 **   Skein APIs for extended initialization: MAC keys, tree hashing.
@@ -127,17 +127,17 @@ int  Skein1024_InitExt(struct skein1024_ctx *ctx, size_t 
hashBitLen, u64 treeInf
 **  Final_Pad:  pad, do final block, but no OUTPUT type
 **  Output: do just the output stage
 */
-int  Skein_256_Final_Pad(struct skein_256_ctx *ctx, u8 * hashVal);
-int  Skein_512_Final_Pad(struct skein_512_ctx *ctx, u8 * hashVal);
-int  Skein1024_Final_Pad(struct skein1024_ctx *ctx, u8 * hashVal);
+int  Skein_256_Final_Pad(struct skein_256_ctx *ctx, u8 *hashVal);
+int  Skein_512_Final_Pad(struct skein_512_ctx *ctx, u8 *hashVal);
+int  Skein1024_Final_Pad(struct skein1024_ctx *ctx, u8 *hashVal);
 
 #ifndef SKEIN_TREE_HASH
 #define SKEIN_TREE_HASH (1)
 #endif
 #if  SKEIN_TREE_HASH
-int  Skein_256_Output   (struct skein_256_ctx *ctx, u8 * hashVal);
-int  Skein_512_Output   (struct skein_512_ctx *ctx, u8 * hashVal);
-int  Skein1024_Output   (struct skein1024_ctx *ctx, u8 * hashVal);
+int  Skein_256_Output   (struct skein_256_ctx *ctx, u8 *hashVal);
+int  Skein_512_Output   (struct skein_512_ctx *ctx, u8 *hashVal);
+int  Skein1024_Output   (struct skein1024_ctx *ctx, u8 *hashVal);
 #endif
 
 /*
diff --git a/drivers/staging/skein/include/skeinApi.h 
b/drivers/staging/skein/include/skeinApi.h
index 4ad294f7945d..2c52797918cf 100755
--- a/drivers/staging/skein/include/skeinApi.h
+++ b/drivers/staging/skein/include/skeinApi.h
@@ -123,7 +123,7 @@ OTHER DEALINGS IN THE SOFTWARE.
  * @return
  * SKEIN_SUCESS of SKEIN_FAIL
  */
-int skeinCtxPrepare(struct skein_ctx* ctx, enum skein_size size);
+int skeinCtxPrepare(struct skein_ctx *ctx, enum skein_size size);
 
 /**
  * Initialize a Skein context.
@@ -139,7 +139,7 @@ OTHER DEALINGS IN THE SOFTWARE.
  * SKEIN_SUCESS of SKEIN_FAIL
  * @see skeinReset
  */
-int skeinInit(struct skein_ctx* ctx, size_t hashBitLen);
+int skeinInit(struct skein_ctx *ctx, size_t hashBitLen);
 
 /**
  * Resets a Skein context for further use.
@@ -151,7 +151,7 @@ OTHER DEALINGS IN THE SOFTWARE.
  * @param ctx
  * Pointer to a pre-initialized Skein MAC context
  */
-void skeinReset(struct skein_ctx* ctx);
+void skeinReset(struct skein_ctx *ctx);
 
 /**
  * Initializes a Skein context for MAC usage.
@@ -173,7 +173,7 @@ OTHER DEALINGS IN THE SOFTWARE.
  * @return
  * SKEIN_SUCESS of SKEIN_FAIL
  */
-int skeinMacInit(struct skein_ctx* ctx, const u8 *key, size_t keyLen,
+int skeinMacInit(struct skein_ctx *ctx, const u8 *key, size_t keyLen,
  size_t hashBitLen);
 
 /**
@@ -222,7 +222,7 @@ OTHER DEALINGS IN THE SOFTWARE.
  * Success or error code.
  * @see skeinReset
  */
-int skeinFinal(struct skein_ctx* ctx, u8* hash);
+int skeinFinal(struct skein_ctx *ctx, u8 *hash);
 
 /**
  * @}
diff --git a/drivers/staging/skein/include/threefishApi.h 
b/drivers/staging/skein/include/threefishApi.h
index 194e313b6b62..1f9e6e14f50b 100644
--- a/drivers/staging/skein/include/threefishApi.h
+++ b/drivers/staging/skein/include/threefishApi.h
@@ -72,7 +72,7 @@
  * @param tweak
  * Pointer to the two tweak words (word has 64 bits).
  */
-void threefishSetKey(struct threefish_key* keyCtx, enum threefish_size 
stateSize, u64* keyData, u64* tweak);
+void threefishSetKey(struct threefish_key *keyCtx

[RFC PATCH 22/22] staging: crypto: skein: add TODO file

[Jason Cooper]

Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
 drivers/staging/skein/TODO | 11 +++
 1 file changed, 11 insertions(+)
 create mode 100644 drivers/staging/skein/TODO

diff --git a/drivers/staging/skein/TODO b/drivers/staging/skein/TODO
new file mode 100644
index ..f5c167a305ae
--- /dev/null
+++ b/drivers/staging/skein/TODO
@@ -0,0 +1,11 @@
+skein/threefish TODO
+
+ - rename camelcase vars
+ - rename camelcase functions
+ - rename files
+ - move macros into appropriate header files
+ - add / pass test vectors
+ - module support
+
+Please send patches to Jason Cooper ja...@lakedaemon.net in addition to the
+staging tree mailinglist.
-- 
1.9.0

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 07/22] staging: crypto: skein: remove unneeded typedefs

[Jason Cooper]

Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
 drivers/staging/skein/include/skein.h| 73 ++---
 drivers/staging/skein/include/skeinApi.h |  4 +-
 drivers/staging/skein/include/skein_iv.h | 26 
 drivers/staging/skein/include/threefishApi.h |  6 +-
 drivers/staging/skein/skein.c| 96 ++--
 drivers/staging/skein/skeinApi.c | 24 +++
 drivers/staging/skein/skeinBlockNo3F.c   | 30 -
 drivers/staging/skein/skein_block.c  | 54 
 drivers/staging/skein/threefishApi.c |  8 +--
 9 files changed, 159 insertions(+), 162 deletions(-)

diff --git a/drivers/staging/skein/include/skein.h 
b/drivers/staging/skein/include/skein.h
index b1e55b08d150..12c5c8d612b0 100644
--- a/drivers/staging/skein/include/skein.h
+++ b/drivers/staging/skein/include/skein.h
@@ -27,9 +27,6 @@
 **1: return SKEIN_FAIL to flag errors
 **
 ***/
-typedef unsigned intuint_t; /* native unsigned integer */
-typedef uint8_t u08b_t; /*  8-bit unsigned integer */
-typedef uint64_tu64b_t; /* 64-bit unsigned integer */
 
 #ifndef RotL_64
 #define RotL_64(x,N)(((x)  (N)) | ((x)  (64-(N
@@ -70,28 +67,28 @@ typedef struct
 {
 size_t  hashBitLen;  /* size of hash result, in bits */
 size_t  bCnt;/* current byte count in buffer 
b[] */
-u64b_t  T[SKEIN_MODIFIER_WORDS]; /* tweak words: T[0]=byte cnt, 
T[1]=flags */
+u64  T[SKEIN_MODIFIER_WORDS]; /* tweak words: T[0]=byte cnt, 
T[1]=flags */
 } Skein_Ctxt_Hdr_t;
 
 typedef struct   /*  256-bit Skein hash context 
structure */
 {
 Skein_Ctxt_Hdr_t h;  /* common header context 
variables */
-u64b_t  X[SKEIN_256_STATE_WORDS];/* chaining variables */
-u08b_t  b[SKEIN_256_BLOCK_BYTES];/* partial block buffer (8-byte 
aligned) */
+u64  X[SKEIN_256_STATE_WORDS];/* chaining variables */
+u8  b[SKEIN_256_BLOCK_BYTES];/* partial block buffer (8-byte 
aligned) */
 } Skein_256_Ctxt_t;
 
 typedef struct   /*  512-bit Skein hash context 
structure */
 {
 Skein_Ctxt_Hdr_t h;  /* common header context 
variables */
-u64b_t  X[SKEIN_512_STATE_WORDS];/* chaining variables */
-u08b_t  b[SKEIN_512_BLOCK_BYTES];/* partial block buffer (8-byte 
aligned) */
+u64  X[SKEIN_512_STATE_WORDS];/* chaining variables */
+u8  b[SKEIN_512_BLOCK_BYTES];/* partial block buffer (8-byte 
aligned) */
 } Skein_512_Ctxt_t;
 
 typedef struct   /* 1024-bit Skein hash context 
structure */
 {
 Skein_Ctxt_Hdr_t h;  /* common header context 
variables */
-u64b_t  X[SKEIN1024_STATE_WORDS];/* chaining variables */
-u08b_t  b[SKEIN1024_BLOCK_BYTES];/* partial block buffer (8-byte 
aligned) */
+u64  X[SKEIN1024_STATE_WORDS];/* chaining variables */
+u8  b[SKEIN1024_BLOCK_BYTES];/* partial block buffer (8-byte 
aligned) */
 } Skein1024_Ctxt_t;
 
 /*   Skein APIs for (incremental) straight hashing */
@@ -99,13 +96,13 @@ int  Skein_256_Init  (Skein_256_Ctxt_t *ctx, size_t 
hashBitLen);
 int  Skein_512_Init  (Skein_512_Ctxt_t *ctx, size_t hashBitLen);
 int  Skein1024_Init  (Skein1024_Ctxt_t *ctx, size_t hashBitLen);
 
-int  Skein_256_Update(Skein_256_Ctxt_t *ctx, const u08b_t *msg, size_t 
msgByteCnt);
-int  Skein_512_Update(Skein_512_Ctxt_t *ctx, const u08b_t *msg, size_t 
msgByteCnt);
-int  Skein1024_Update(Skein1024_Ctxt_t *ctx, const u08b_t *msg, size_t 
msgByteCnt);
+int  Skein_256_Update(Skein_256_Ctxt_t *ctx, const u8 *msg, size_t msgByteCnt);
+int  Skein_512_Update(Skein_512_Ctxt_t *ctx, const u8 *msg, size_t msgByteCnt);
+int  Skein1024_Update(Skein1024_Ctxt_t *ctx, const u8 *msg, size_t msgByteCnt);
 
-int  Skein_256_Final (Skein_256_Ctxt_t *ctx, u08b_t * hashVal);
-int  Skein_512_Final (Skein_512_Ctxt_t *ctx, u08b_t * hashVal);
-int  Skein1024_Final (Skein1024_Ctxt_t *ctx, u08b_t * hashVal);
+int  Skein_256_Final (Skein_256_Ctxt_t *ctx, u8 * hashVal);
+int  Skein_512_Final (Skein_512_Ctxt_t *ctx, u8 * hashVal);
+int  Skein1024_Final (Skein1024_Ctxt_t *ctx, u8 * hashVal);
 
 /*
 **   Skein APIs for extended initialization: MAC keys, tree hashing.
@@ -121,26 +118,26 @@ int  Skein1024_Final (Skein1024_Ctxt_t *ctx, u08b_t * 
hashVal);
 **  to precompute the MAC IV, then a copy of the context saved and
 **  reused for each new MAC computation.
 **/
-int  Skein_256_InitExt(Skein_256_Ctxt_t *ctx, size_t hashBitLen, u64b_t 
treeInfo, const u08b_t *key, size_t keyBytes);
-int  Skein_512_InitExt(Skein_512_Ctxt_t *ctx, size_t

[RFC PATCH 04/22] staging: crypto: skein: remove brg_*.h includes

[Jason Cooper]

Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
 drivers/staging/skein/include/brg_endian.h | 148 -
 drivers/staging/skein/include/brg_types.h  | 131 -
 drivers/staging/skein/include/skein_port.h |   6 +-
 3 files changed, 2 insertions(+), 283 deletions(-)
 delete mode 100644 drivers/staging/skein/include/brg_endian.h
 delete mode 100644 drivers/staging/skein/include/brg_types.h

diff --git a/drivers/staging/skein/include/brg_endian.h 
b/drivers/staging/skein/include/brg_endian.h
deleted file mode 100644
index c03c7c5d1eb4..
--- a/drivers/staging/skein/include/brg_endian.h
+++ /dev/null
@@ -1,148 +0,0 @@
-/*
- ---
- Copyright (c) 2003, Dr Brian Gladman, Worcester, UK.   All rights reserved.
-
- LICENSE TERMS
-
- The free distribution and use of this software in both source and binary
- form is allowed (with or without changes) provided that:
-
-   1. distributions of this source code include the above copyright
-  notice, this list of conditions and the following disclaimer;
-
-   2. distributions in binary form include the above copyright
-  notice, this list of conditions and the following disclaimer
-  in the documentation and/or other associated materials;
-
-   3. the copyright holder's name is not used to endorse products
-  built using this software without specific written permission.
-
- ALTERNATIVELY, provided that this notice is retained in full, this product
- may be distributed under the terms of the GNU General Public License (GPL),
- in which case the provisions of the GPL apply INSTEAD OF those given above.
-
- DISCLAIMER
-
- This software is provided 'as is' with no explicit or implied warranties
- in respect of its properties, including, but not limited to, correctness
- and/or fitness for purpose.
- ---
- Issue 20/10/2006
-*/
-
-#ifndef BRG_ENDIAN_H
-#define BRG_ENDIAN_H
-
-#define IS_BIG_ENDIAN  4321 /* byte 0 is most significant (mc68k) */
-#define IS_LITTLE_ENDIAN   1234 /* byte 0 is least significant (i386) */
-
-/* Include files where endian defines and byteswap functions may reside */
-#if defined( __FreeBSD__ ) || defined( __OpenBSD__ ) || defined( __NetBSD__ )
-#  include sys/endian.h
-#elif defined( BSD )  ( BSD = 199103 ) || defined( __APPLE__ ) || \
-  defined( __CYGWIN32__ ) || defined( __DJGPP__ ) || defined( __osf__ )
-#  include machine/endian.h
-#elif defined( __linux__ ) || defined( __GNUC__ ) || defined( __GNU_LIBRARY__ )
-#  if !defined( __MINGW32__ )  !defined(AVR)
-#include endian.h
-#if !defined( __BEOS__ )
-#  include byteswap.h
-#endif
-#  endif
-#endif
-
-/* Now attempt to set the define for platform byte order using any  */
-/* of the four forms SYMBOL, _SYMBOL, __SYMBOL  __SYMBOL__, which  */
-/* seem to encompass most endian symbol definitions */
-
-#if defined( BIG_ENDIAN )  defined( LITTLE_ENDIAN )
-#  if defined( BYTE_ORDER )  BYTE_ORDER == BIG_ENDIAN
-#define PLATFORM_BYTE_ORDER IS_BIG_ENDIAN
-#  elif defined( BYTE_ORDER )  BYTE_ORDER == LITTLE_ENDIAN
-#define PLATFORM_BYTE_ORDER IS_LITTLE_ENDIAN
-#  endif
-#elif defined( BIG_ENDIAN )
-#  define PLATFORM_BYTE_ORDER IS_BIG_ENDIAN
-#elif defined( LITTLE_ENDIAN )
-#  define PLATFORM_BYTE_ORDER IS_LITTLE_ENDIAN
-#endif
-
-#if defined( _BIG_ENDIAN )  defined( _LITTLE_ENDIAN )
-#  if defined( _BYTE_ORDER )  _BYTE_ORDER == _BIG_ENDIAN
-#define PLATFORM_BYTE_ORDER IS_BIG_ENDIAN
-#  elif defined( _BYTE_ORDER )  _BYTE_ORDER == _LITTLE_ENDIAN
-#define PLATFORM_BYTE_ORDER IS_LITTLE_ENDIAN
-#  endif
-#elif defined( _BIG_ENDIAN )
-#  define PLATFORM_BYTE_ORDER IS_BIG_ENDIAN
-#elif defined( _LITTLE_ENDIAN )
-#  define PLATFORM_BYTE_ORDER IS_LITTLE_ENDIAN
-#endif
-
-#if defined( __BIG_ENDIAN )  defined( __LITTLE_ENDIAN )
-#  if defined( __BYTE_ORDER )  __BYTE_ORDER == __BIG_ENDIAN
-#define PLATFORM_BYTE_ORDER IS_BIG_ENDIAN
-#  elif defined( __BYTE_ORDER )  __BYTE_ORDER == __LITTLE_ENDIAN
-#define PLATFORM_BYTE_ORDER IS_LITTLE_ENDIAN
-#  endif
-#elif defined( __BIG_ENDIAN )
-#  define PLATFORM_BYTE_ORDER IS_BIG_ENDIAN
-#elif defined( __LITTLE_ENDIAN )
-#  define PLATFORM_BYTE_ORDER IS_LITTLE_ENDIAN
-#endif
-
-#if defined( __BIG_ENDIAN__ )  defined( __LITTLE_ENDIAN__ )
-#  if defined( __BYTE_ORDER__ )  __BYTE_ORDER__ == __BIG_ENDIAN__
-#define PLATFORM_BYTE_ORDER IS_BIG_ENDIAN
-#  elif defined( __BYTE_ORDER__ )  __BYTE_ORDER__ == __LITTLE_ENDIAN__
-#define PLATFORM_BYTE_ORDER IS_LITTLE_ENDIAN
-#  endif
-#elif defined( __BIG_ENDIAN__ )
-#  define PLATFORM_BYTE_ORDER IS_BIG_ENDIAN
-#elif defined( __LITTLE_ENDIAN__ )
-#  define PLATFORM_BYTE_ORDER IS_LITTLE_ENDIAN
-#endif
-
-/*  if the platform byte order could not be determined, then try to */
-/*  set this define using common machine defines*/
-#if !defined

[RFC PATCH 08/22] staging: crypto: skein: remove all typedef {struct,enum}

[Jason Cooper]

Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
 drivers/staging/skein/include/skein.h| 58 ++--
 drivers/staging/skein/include/skeinApi.h | 32 +++
 drivers/staging/skein/include/threefishApi.h | 32 +++
 drivers/staging/skein/skein.c| 42 ++--
 drivers/staging/skein/skeinApi.c | 16 
 drivers/staging/skein/skeinBlockNo3F.c   | 12 +++---
 drivers/staging/skein/skein_block.c  |  6 +--
 drivers/staging/skein/threefish1024Block.c   |  4 +-
 drivers/staging/skein/threefish256Block.c|  4 +-
 drivers/staging/skein/threefish512Block.c|  4 +-
 drivers/staging/skein/threefishApi.c | 10 ++---
 11 files changed, 110 insertions(+), 110 deletions(-)

diff --git a/drivers/staging/skein/include/skein.h 
b/drivers/staging/skein/include/skein.h
index 12c5c8d612b0..77b712e73253 100644
--- a/drivers/staging/skein/include/skein.h
+++ b/drivers/staging/skein/include/skein.h
@@ -63,46 +63,46 @@ enum
 #define  SKEIN_512_BLOCK_BYTES ( 8*SKEIN_512_STATE_WORDS)
 #define  SKEIN1024_BLOCK_BYTES ( 8*SKEIN1024_STATE_WORDS)
 
-typedef struct
+struct skein_ctx_hdr
 {
 size_t  hashBitLen;  /* size of hash result, in bits */
 size_t  bCnt;/* current byte count in buffer 
b[] */
 u64  T[SKEIN_MODIFIER_WORDS]; /* tweak words: T[0]=byte cnt, 
T[1]=flags */
-} Skein_Ctxt_Hdr_t;
+};
 
-typedef struct   /*  256-bit Skein hash context 
structure */
+struct skein_256_ctx   /*  256-bit Skein hash 
context structure */
 {
-Skein_Ctxt_Hdr_t h;  /* common header context 
variables */
+struct skein_ctx_hdr h;  /* common header context 
variables */
 u64  X[SKEIN_256_STATE_WORDS];/* chaining variables */
 u8  b[SKEIN_256_BLOCK_BYTES];/* partial block buffer (8-byte 
aligned) */
-} Skein_256_Ctxt_t;
+};
 
-typedef struct   /*  512-bit Skein hash context 
structure */
+struct skein_512_ctx /*  512-bit Skein hash 
context structure */
 {
-Skein_Ctxt_Hdr_t h;  /* common header context 
variables */
+struct skein_ctx_hdr h;  /* common header context 
variables */
 u64  X[SKEIN_512_STATE_WORDS];/* chaining variables */
 u8  b[SKEIN_512_BLOCK_BYTES];/* partial block buffer (8-byte 
aligned) */
-} Skein_512_Ctxt_t;
+};
 
-typedef struct   /* 1024-bit Skein hash context 
structure */
+struct skein1024_ctx  /* 1024-bit Skein hash 
context structure */
 {
-Skein_Ctxt_Hdr_t h;  /* common header context 
variables */
+struct skein_ctx_hdr h;  /* common header context 
variables */
 u64  X[SKEIN1024_STATE_WORDS];/* chaining variables */
 u8  b[SKEIN1024_BLOCK_BYTES];/* partial block buffer (8-byte 
aligned) */
-} Skein1024_Ctxt_t;
+};
 
 /*   Skein APIs for (incremental) straight hashing */
-int  Skein_256_Init  (Skein_256_Ctxt_t *ctx, size_t hashBitLen);
-int  Skein_512_Init  (Skein_512_Ctxt_t *ctx, size_t hashBitLen);
-int  Skein1024_Init  (Skein1024_Ctxt_t *ctx, size_t hashBitLen);
+int  Skein_256_Init  (struct skein_256_ctx *ctx, size_t hashBitLen);
+int  Skein_512_Init  (struct skein_512_ctx *ctx, size_t hashBitLen);
+int  Skein1024_Init  (struct skein1024_ctx *ctx, size_t hashBitLen);
 
-int  Skein_256_Update(Skein_256_Ctxt_t *ctx, const u8 *msg, size_t msgByteCnt);
-int  Skein_512_Update(Skein_512_Ctxt_t *ctx, const u8 *msg, size_t msgByteCnt);
-int  Skein1024_Update(Skein1024_Ctxt_t *ctx, const u8 *msg, size_t msgByteCnt);
+int  Skein_256_Update(struct skein_256_ctx *ctx, const u8 *msg, size_t 
msgByteCnt);
+int  Skein_512_Update(struct skein_512_ctx *ctx, const u8 *msg, size_t 
msgByteCnt);
+int  Skein1024_Update(struct skein1024_ctx *ctx, const u8 *msg, size_t 
msgByteCnt);
 
-int  Skein_256_Final (Skein_256_Ctxt_t *ctx, u8 * hashVal);
-int  Skein_512_Final (Skein_512_Ctxt_t *ctx, u8 * hashVal);
-int  Skein1024_Final (Skein1024_Ctxt_t *ctx, u8 * hashVal);
+int  Skein_256_Final (struct skein_256_ctx *ctx, u8 * hashVal);
+int  Skein_512_Final (struct skein_512_ctx *ctx, u8 * hashVal);
+int  Skein1024_Final (struct skein1024_ctx *ctx, u8 * hashVal);
 
 /*
 **   Skein APIs for extended initialization: MAC keys, tree hashing.
@@ -118,26 +118,26 @@ int  Skein1024_Final (Skein1024_Ctxt_t *ctx, u8 * 
hashVal);
 **  to precompute the MAC IV, then a copy of the context saved and
 **  reused for each new MAC computation.
 **/
-int  Skein_256_InitExt(Skein_256_Ctxt_t *ctx, size_t hashBitLen, u64 treeInfo, 
const u8 *key, size_t keyBytes);
-int  Skein_512_InitExt(Skein_512_Ctxt_t *ctx, size_t hashBitLen, u64 treeInfo

[RFC PATCH 06/22] staging: crypto: skein: remove __cplusplus and an unneeded stddef.h

[Jason Cooper]

Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
 drivers/staging/skein/include/skein.h| 11 ---
 drivers/staging/skein/include/skeinApi.h |  9 -
 drivers/staging/skein/include/threefishApi.h |  9 -
 3 files changed, 29 deletions(-)

diff --git a/drivers/staging/skein/include/skein.h 
b/drivers/staging/skein/include/skein.h
index 211aca1b1036..b1e55b08d150 100644
--- a/drivers/staging/skein/include/skein.h
+++ b/drivers/staging/skein/include/skein.h
@@ -27,13 +27,6 @@
 **1: return SKEIN_FAIL to flag errors
 **
 ***/
-#ifdef __cplusplus
-extern C
-{
-#endif
-
-#include stddef.h  /* get size_t definition */
-
 typedef unsigned intuint_t; /* native unsigned integer */
 typedef uint8_t u08b_t; /*  8-bit unsigned integer */
 typedef uint64_tu64b_t; /* 64-bit unsigned integer */
@@ -322,8 +315,4 @@ enum
 #define SKEIN1024_ROUNDS_TOTAL (8*SKEIN_ROUNDS) + 5) % 10) + 5))
 #endif
 
-#ifdef __cplusplus
-}
-#endif
-
 #endif  /* ifndef _SKEIN_H_ */
diff --git a/drivers/staging/skein/include/skeinApi.h 
b/drivers/staging/skein/include/skeinApi.h
index 734d27b79f01..f55c67e81f2b 100755
--- a/drivers/staging/skein/include/skeinApi.h
+++ b/drivers/staging/skein/include/skeinApi.h
@@ -81,11 +81,6 @@ OTHER DEALINGS IN THE SOFTWARE.
 #include linux/types.h
 #include skein.h
 
-#ifdef __cplusplus
-extern C
-{
-#endif
-
 /**
  * Which Skein size to use
  */
@@ -229,10 +224,6 @@ extern C
  */
 int skeinFinal(SkeinCtx_t* ctx, uint8_t* hash);
 
-#ifdef __cplusplus
-}
-#endif
-
 /**
  * @}
  */
diff --git a/drivers/staging/skein/include/threefishApi.h 
b/drivers/staging/skein/include/threefishApi.h
index dae270cf71d3..aaecfe822142 100644
--- a/drivers/staging/skein/include/threefishApi.h
+++ b/drivers/staging/skein/include/threefishApi.h
@@ -33,11 +33,6 @@
 
 #define KeyScheduleConst 0x1BD11BDAA9FC1A22L
 
-#ifdef __cplusplus
-extern C
-{
-#endif
-
 /**
  * Which Threefish size to use
  */
@@ -157,10 +152,6 @@ extern C
 void threefishDecrypt256(ThreefishKey_t* keyCtx, uint64_t* input, 
uint64_t* output);
 void threefishDecrypt512(ThreefishKey_t* keyCtx, uint64_t* input, 
uint64_t* output);
 void threefishDecrypt1024(ThreefishKey_t* keyCtx, uint64_t* input, 
uint64_t* output);
-#ifdef __cplusplus
-}
-#endif
-
 /**
  * @}
  */
-- 
1.9.0

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 05/22] staging: crypto: skein: remove skein_port.h

[Jason Cooper]

Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
 drivers/staging/skein/include/skein.h  |  14 +++-
 drivers/staging/skein/include/skein_port.h | 108 -
 drivers/staging/skein/skein.c  |  21 --
 3 files changed, 13 insertions(+), 130 deletions(-)
 delete mode 100644 drivers/staging/skein/include/skein_port.h

diff --git a/drivers/staging/skein/include/skein.h 
b/drivers/staging/skein/include/skein.h
index 315cdcd14413..211aca1b1036 100644
--- a/drivers/staging/skein/include/skein.h
+++ b/drivers/staging/skein/include/skein.h
@@ -33,7 +33,19 @@ extern C
 #endif
 
 #include stddef.h  /* get size_t definition */
-#include skein_port.h   /* get platform-specific definitions */
+
+typedef unsigned intuint_t; /* native unsigned integer */
+typedef uint8_t u08b_t; /*  8-bit unsigned integer */
+typedef uint64_tu64b_t; /* 64-bit unsigned integer */
+
+#ifndef RotL_64
+#define RotL_64(x,N)(((x)  (N)) | ((x)  (64-(N
+#endif
+
+/* below two prototype assume we are handed aligned data */
+#define Skein_Put64_LSB_First(dst08,src64,bCnt) memcpy(dst08,src64,bCnt)
+#define Skein_Get64_LSB_First(dst64,src08,wCnt) memcpy(dst64,src08,8*(wCnt))
+#define Skein_Swap64(w64)  (w64)
 
 enum
 {
diff --git a/drivers/staging/skein/include/skein_port.h 
b/drivers/staging/skein/include/skein_port.h
deleted file mode 100644
index e78c976dccc5..
--- a/drivers/staging/skein/include/skein_port.h
+++ /dev/null
@@ -1,108 +0,0 @@
-#ifndef _SKEIN_PORT_H_
-#define _SKEIN_PORT_H_
-/***
-**
-** Platform-specific definitions for Skein hash function.
-**
-** Source code author: Doug Whiting, 2008.
-**
-** This algorithm and source code is released to the public domain.
-**
-** Many thanks to Brian Gladman for his portable header files.
-**
-** To port Skein to an unsupported platform, change the definitions
-** in this file appropriately.
-** 
-/
-
-typedef unsigned intuint_t; /* native unsigned integer */
-typedef uint8_t u08b_t; /*  8-bit unsigned integer */
-typedef uint64_tu64b_t; /* 64-bit unsigned integer */
-
-#ifndef RotL_64
-#define RotL_64(x,N)(((x)  (N)) | ((x)  (64-(N
-#endif
-
-/*
- * Skein is natively little-endian (unlike SHA-xxx), for optimal
- * performance on x86 CPUs.  The Skein code requires the following
- * definitions for dealing with endianness:
- *
- *SKEIN_NEED_SWAP:  0 for little-endian, 1 for big-endian
- *Skein_Put64_LSB_First
- *Skein_Get64_LSB_First
- *Skein_Swap64
- *
- * If SKEIN_NEED_SWAP is defined at compile time, it is used here
- * along with the portable versions of Put64/Get64/Swap64, which 
- * are slow in general.
- *
- * Otherwise, an auto-detect of endianness is attempted below.
- * If the default handling doesn't work well, the user may insert
- * platform-specific code instead (e.g., for big-endian CPUs).
- *
- */
-#define SKEIN_NEED_SWAP   (0)
-/* below two prototype assume we are handed aligned data */
-#define Skein_Put64_LSB_First(dst08,src64,bCnt) memcpy(dst08,src64,bCnt)
-#define Skein_Get64_LSB_First(dst64,src08,wCnt) memcpy(dst64,src08,8*(wCnt))
-
-/*
- **
- *  Provide any definitions still needed.
- **
- */
-#ifndef Skein_Swap64  /* swap for big-endian, nop for little-endian */
-#if SKEIN_NEED_SWAP
-#define Skein_Swap64(w64)   \
-  ( (( ((u64b_t)(w64))0xFF)  56) |   \
-(u64b_t)(w64))  8)  0xFF)  48) |   \
-(u64b_t)(w64)) 16)  0xFF)  40) |   \
-(u64b_t)(w64)) 24)  0xFF)  32) |   \
-(u64b_t)(w64)) 32)  0xFF)  24) |   \
-(u64b_t)(w64)) 40)  0xFF)  16) |   \
-(u64b_t)(w64)) 48)  0xFF)   8) |   \
-(u64b_t)(w64)) 56)  0xFF)  ) )
-#else
-#define Skein_Swap64(w64)  (w64)
-#endif
-#endif  /* ifndef Skein_Swap64 */
-
-
-#ifndef Skein_Put64_LSB_First
-voidSkein_Put64_LSB_First(u08b_t *dst,const u64b_t *src,size_t bCnt)
-#ifdef  SKEIN_PORT_CODE /* instantiate the function code here? */
-{ /* this version is fully portable (big-endian or little-endian), but 
slow */
-size_t n;
-
-for (n=0;nbCnt;n++)
-dst[n] = (u08b_t) (src[n3]  (8*(n7)));
-}
-#else
-;/* output only the function prototype */
-#endif
-#endif   /* ifndef Skein_Put64_LSB_First */
-
-
-#ifndef Skein_Get64_LSB_First
-voidSkein_Get64_LSB_First(u64b_t *dst,const u08b_t *src,size_t wCnt)
-#ifdef  SKEIN_PORT_CODE /* instantiate the function code here? */
-{ /* this version is fully portable (big-endian or little-endian), but 
slow */
-size_t n;
-
-for (n=0;n8*wCnt;n+=8)
-dst[n/8] = (((u64b_t) src[n

[RFC PATCH 14/22] staging: crypto: skein: remove trailing whitespace

[Jason Cooper]

Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
 drivers/staging/skein/include/skein.h| 16 +-
 drivers/staging/skein/include/skeinApi.h | 44 ++--
 drivers/staging/skein/include/threefishApi.h | 40 -
 drivers/staging/skein/skeinBlockNo3F.c   |  6 ++--
 drivers/staging/skein/skein_block.c  | 20 ++---
 5 files changed, 63 insertions(+), 63 deletions(-)

diff --git a/drivers/staging/skein/include/skein.h 
b/drivers/staging/skein/include/skein.h
index 906bcee41c39..dd9a210cf5dd 100644
--- a/drivers/staging/skein/include/skein.h
+++ b/drivers/staging/skein/include/skein.h
@@ -9,7 +9,7 @@
 ** This algorithm and source code is released to the public domain.
 **
 ***
-** 
+**
 ** The following compile-time switches may be defined to control some
 ** tradeoffs between speed, code size, error checking, and security.
 **
@@ -20,8 +20,8 @@
 **[default: no callouts (no overhead)]
 **
 **  SKEIN_ERR_CHECK-- how error checking is handled inside Skein
-**code. If not defined, most error checking 
-**is disabled (for performance). Otherwise, 
+**code. If not defined, most error checking
+**is disabled (for performance). Otherwise,
 **the switch value is interpreted as:
 **0: use assert()  to flag errors
 **1: return SKEIN_FAIL to flag errors
@@ -109,12 +109,12 @@ int  Skein1024_Final(struct skein1024_ctx *ctx, u8 
*hashVal);
 **   After an InitExt() call, just use Update/Final calls as with Init().
 **
 **   Notes: Same parameters as _Init() calls, plus treeInfo/key/keyBytes.
-**  When keyBytes == 0 and treeInfo == SKEIN_SEQUENTIAL, 
+**  When keyBytes == 0 and treeInfo == SKEIN_SEQUENTIAL,
 **  the results of InitExt() are identical to calling Init().
 **  The function Init() may be called once to precompute the IV for
 **  a given hashBitLen value, then by saving a copy of the context
 **  the IV computation may be avoided in later calls.
-**  Similarly, the function InitExt() may be called once per MAC key 
+**  Similarly, the function InitExt() may be called once per MAC key
 **  to precompute the MAC IV, then a copy of the context saved and
 **  reused for each new MAC computation.
 **/
@@ -142,7 +142,7 @@ int  Skein1024_Output(struct skein1024_ctx *ctx, u8 
*hashVal);
 
 /*
 ** Internal Skein definitions
-**-- not needed for sequential hashing API, but will be 
+**-- not needed for sequential hashing API, but will be
 **   helpful for other uses of Skein (e.g., tree hash mode).
 **-- included here so that they can be shared between
 **   reference and optimized code.
@@ -269,8 +269,8 @@ int  Skein1024_Output(struct skein1024_ctx *ctx, u8 
*hashVal);
 /*
 ** Skein block function constants (shared across Ref and Opt code)
 **/
-enum
-   {   
+enum
+   {
/* Skein_256 round rotation constants */
R_256_0_0 = 14, R_256_0_1 = 16,
R_256_1_0 = 52, R_256_1_1 = 57,
diff --git a/drivers/staging/skein/include/skeinApi.h 
b/drivers/staging/skein/include/skeinApi.h
index 0d7d59eff460..ace931a67c23 100644
--- a/drivers/staging/skein/include/skeinApi.h
+++ b/drivers/staging/skein/include/skeinApi.h
@@ -36,46 +36,46 @@ OTHER DEALINGS IN THE SOFTWARE.
  * of Skein. The design and the way to use the functions follow the openSSL
  * design but at the same time take care of some Skein specific behaviour
  * and possibilities.
- * 
+ *
  * The functions enable applications to create a normal Skein hashes and
  * message authentication codes (MAC).
- * 
+ *
  * Using these functions is simple and straight forward:
- * 
+ *
  * @code
- * 
+ *
  * #include skeinApi.h
- * 
+ *
  * ...
  * struct skein_ctx ctx; // a Skein hash or MAC context
- * 
+ *
  * // prepare context, here for a Skein with a state size of 512 bits.
  * skeinCtxPrepare(ctx, Skein512);
- * 
+ *
  * // Initialize the context to set the requested hash length in bits
  * // here request a output hash size of 31 bits (Skein supports variable
  * // output sizes even very strange sizes)
  * skeinInit(ctx, 31);
- * 
+ *
  * // Now update Skein with any number of message bits. A function that
  * // takes a number of bytes is also available.
  * skeinUpdateBits(ctx, message, msgLength);
- * 
+ *
  * // Now get the result of the Skein hash. The output buffer must be
  * // large enough to hold the request number

[RFC PATCH 20/22] staging: crypto: skein: remove braces from single-statement block

[Jason Cooper]

Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
 drivers/staging/skein/skeinApi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/skein/skeinApi.c b/drivers/staging/skein/skeinApi.c
index f0015d5b10f5..dd109bf6f7b9 100644
--- a/drivers/staging/skein/skeinApi.c
+++ b/drivers/staging/skein/skeinApi.c
@@ -188,9 +188,9 @@ int skeinUpdateBits(struct skein_ctx *ctx, const u8 *msg,
msgBitCnt == 0, SKEIN_FAIL);
 
/* if number of bits is a multiple of bytes - that's easy */
-   if ((msgBitCnt  0x7) == 0) {
+   if ((msgBitCnt  0x7) == 0)
return skeinUpdate(ctx, msg, msgBitCnt  3);
-   }
+
skeinUpdate(ctx, msg, (msgBitCnt  3) + 1);
 
/*
-- 
1.9.0

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 19/22] staging: crypto: skein: remove externs from .c files

[Jason Cooper]

Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
 drivers/staging/skein/include/skein_block.h | 22 ++
 drivers/staging/skein/skein.c   | 10 +-
 2 files changed, 23 insertions(+), 9 deletions(-)
 create mode 100644 drivers/staging/skein/include/skein_block.h

diff --git a/drivers/staging/skein/include/skein_block.h 
b/drivers/staging/skein/include/skein_block.h
new file mode 100644
index ..b15c079b5bd4
--- /dev/null
+++ b/drivers/staging/skein/include/skein_block.h
@@ -0,0 +1,22 @@
+/***
+**
+** Implementation of the Skein hash function.
+**
+** Source code author: Doug Whiting, 2008.
+**
+** This algorithm and source code is released to the public domain.
+**
+/
+#ifndef _SKEIN_BLOCK_H_
+#define _SKEIN_BLOCK_H_
+
+#include skein.h /* get the Skein API definitions   */
+
+void Skein_256_Process_Block(struct skein_256_ctx *ctx, const u8 *blkPtr,
+   size_t blkCnt, size_t byteCntAdd);
+void Skein_512_Process_Block(struct skein_512_ctx *ctx, const u8 *blkPtr,
+   size_t blkCnt, size_t byteCntAdd);
+void Skein1024_Process_Block(struct skein1024_ctx *ctx, const u8 *blkPtr,
+   size_t blkCnt, size_t byteCntAdd);
+
+#endif
diff --git a/drivers/staging/skein/skein.c b/drivers/staging/skein/skein.c
index 0d8c70c02c6f..096b86bf9430 100644
--- a/drivers/staging/skein/skein.c
+++ b/drivers/staging/skein/skein.c
@@ -13,15 +13,7 @@
 #include linux/string.h   /* get the memcpy/memset functions */
 #include skein.h /* get the Skein API definitions   */
 #include skein_iv.h/* get precomputed IVs */
-
-/*/
-/* External function to process blkCnt (nonzero) full block(s) of data. */
-void Skein_256_Process_Block(struct skein_256_ctx *ctx, const u8 *blkPtr,
-   size_t blkCnt, size_t byteCntAdd);
-void Skein_512_Process_Block(struct skein_512_ctx *ctx, const u8 *blkPtr,
-   size_t blkCnt, size_t byteCntAdd);
-void Skein1024_Process_Block(struct skein1024_ctx *ctx, const u8 *blkPtr,
-   size_t blkCnt, size_t byteCntAdd);
+#include skein_block.h
 
 /*/
 /* 256-bit Skein */
-- 
1.9.0

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 21/22] staging: crypto: skein: remove unnecessary line continuation

[Jason Cooper]

Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
 drivers/staging/skein/skein_block.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/skein/skein_block.c 
b/drivers/staging/skein/skein_block.c
index 707a21ae53c6..fd96ca0ad0ed 100644
--- a/drivers/staging/skein/skein_block.c
+++ b/drivers/staging/skein/skein_block.c
@@ -477,7 +477,7 @@ unsigned int Skein_512_Unroll_Cnt(void)
 
 /*  Skein1024 **/
 #if !(SKEIN_USE_ASM  1024)
-void Skein1024_Process_Block(struct skein1024_ctx *ctx, const u8 *blkPtr, \
+void Skein1024_Process_Block(struct skein1024_ctx *ctx, const u8 *blkPtr,
size_t blkCnt, size_t byteCntAdd)
 { /* do it in C, always looping (unrolled is bigger AND slower!) */
enum {
-- 
1.9.0

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 09/22] staging: crypto: skein: use u8, u64 vice uint*_t

[Jason Cooper]

Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
 drivers/staging/skein/include/skeinApi.h |  8 
 drivers/staging/skein/include/threefishApi.h | 22 +++---
 drivers/staging/skein/skeinApi.c | 22 +++---
 drivers/staging/skein/threefish1024Block.c   | 18 +-
 drivers/staging/skein/threefish256Block.c| 18 +-
 drivers/staging/skein/threefish512Block.c| 18 +-
 drivers/staging/skein/threefishApi.c | 20 ++--
 7 files changed, 63 insertions(+), 63 deletions(-)

diff --git a/drivers/staging/skein/include/skeinApi.h 
b/drivers/staging/skein/include/skeinApi.h
index 548c639431de..4ad294f7945d 100755
--- a/drivers/staging/skein/include/skeinApi.h
+++ b/drivers/staging/skein/include/skeinApi.h
@@ -173,7 +173,7 @@ OTHER DEALINGS IN THE SOFTWARE.
  * @return
  * SKEIN_SUCESS of SKEIN_FAIL
  */
-int skeinMacInit(struct skein_ctx* ctx, const uint8_t *key, size_t keyLen,
+int skeinMacInit(struct skein_ctx* ctx, const u8 *key, size_t keyLen,
  size_t hashBitLen);
 
 /**
@@ -188,7 +188,7 @@ OTHER DEALINGS IN THE SOFTWARE.
  * @return
  * Success or error code.
  */
-int skeinUpdate(struct skein_ctx *ctx, const uint8_t *msg,
+int skeinUpdate(struct skein_ctx *ctx, const u8 *msg,
 size_t msgByteCnt);
 
 /**
@@ -204,7 +204,7 @@ OTHER DEALINGS IN THE SOFTWARE.
  * @param msgBitCnt
  * Length of the message in @b bits.
  */
-int skeinUpdateBits(struct skein_ctx *ctx, const uint8_t *msg,
+int skeinUpdateBits(struct skein_ctx *ctx, const u8 *msg,
 size_t msgBitCnt);
 
 /**
@@ -222,7 +222,7 @@ OTHER DEALINGS IN THE SOFTWARE.
  * Success or error code.
  * @see skeinReset
  */
-int skeinFinal(struct skein_ctx* ctx, uint8_t* hash);
+int skeinFinal(struct skein_ctx* ctx, u8* hash);
 
 /**
  * @}
diff --git a/drivers/staging/skein/include/threefishApi.h 
b/drivers/staging/skein/include/threefishApi.h
index 4c1cd81f30c4..194e313b6b62 100644
--- a/drivers/staging/skein/include/threefishApi.h
+++ b/drivers/staging/skein/include/threefishApi.h
@@ -72,7 +72,7 @@
  * @param tweak
  * Pointer to the two tweak words (word has 64 bits).
  */
-void threefishSetKey(struct threefish_key* keyCtx, enum threefish_size 
stateSize, uint64_t* keyData, uint64_t* tweak);
+void threefishSetKey(struct threefish_key* keyCtx, enum threefish_size 
stateSize, u64* keyData, u64* tweak);
 
 /**
  * Encrypt Threefisch block (bytes).
@@ -89,7 +89,7 @@
  * @param out
  * Pointer to cipher buffer.
  */
-void threefishEncryptBlockBytes(struct threefish_key* keyCtx, uint8_t* in, 
uint8_t* out);
+void threefishEncryptBlockBytes(struct threefish_key* keyCtx, u8* in, u8* 
out);
 
 /**
  * Encrypt Threefisch block (words).
@@ -108,7 +108,7 @@
  * @param out
  * Pointer to cipher buffer.
  */
-void threefishEncryptBlockWords(struct threefish_key* keyCtx, uint64_t* 
in, uint64_t* out);
+void threefishEncryptBlockWords(struct threefish_key* keyCtx, u64* in, 
u64* out);
 
 /**
  * Decrypt Threefisch block (bytes).
@@ -125,7 +125,7 @@
  * @param out
  * Pointer to plaintext buffer.
  */
-void threefishDecryptBlockBytes(struct threefish_key* keyCtx, uint8_t* in, 
uint8_t* out);
+void threefishDecryptBlockBytes(struct threefish_key* keyCtx, u8* in, u8* 
out);
 
 /**
  * Decrypt Threefisch block (words).
@@ -144,14 +144,14 @@
  * @param out
  * Pointer to plaintext buffer.
  */
-void threefishDecryptBlockWords(struct threefish_key* keyCtx, uint64_t* 
in, uint64_t* out);
+void threefishDecryptBlockWords(struct threefish_key* keyCtx, u64* in, 
u64* out);
 
-void threefishEncrypt256(struct threefish_key* keyCtx, uint64_t* input, 
uint64_t* output);
-void threefishEncrypt512(struct threefish_key* keyCtx, uint64_t* input, 
uint64_t* output);
-void threefishEncrypt1024(struct threefish_key* keyCtx, uint64_t* input, 
uint64_t* output);
-void threefishDecrypt256(struct threefish_key* keyCtx, uint64_t* input, 
uint64_t* output);
-void threefishDecrypt512(struct threefish_key* keyCtx, uint64_t* input, 
uint64_t* output);
-void threefishDecrypt1024(struct threefish_key* keyCtx, uint64_t* input, 
uint64_t* output);
+void threefishEncrypt256(struct threefish_key* keyCtx, u64* input, u64* 
output);
+void threefishEncrypt512(struct threefish_key* keyCtx, u64* input, u64* 
output);
+void threefishEncrypt1024(struct threefish_key* keyCtx, u64* input, u64* 
output);
+void threefishDecrypt256(struct threefish_key* keyCtx, u64* input, u64* 
output);
+void threefishDecrypt512(struct threefish_key* keyCtx, u64* input, u64* 
output);
+void threefishDecrypt1024(struct threefish_key* keyCtx, u64

Re: [PATCH][RESEND 3] hwrng: add randomness to system from rng sources

[Jason Cooper]

On Wed, Mar 05, 2014 at 06:52:27PM -0600, Matt Mackall wrote:
 On Wed, 2014-03-05 at 16:11 -0500, Jason Cooper wrote:
   In other words, if there are 4096 bits of unknownness in X to start
   with, and I can get those same 4096 bits of unknownness back by
   unmixing X' and Y, then there must still be 4096 bits of unknownness
   in X'. If X' is 4096 bits long, then we've just proven that
   reversibility means the attacker can know nothing about the contents of
   X' by his choice of Y.
  
  Well, this reinforces my comfortability with loadable modules.  The pool
  is already initialized by the point at which the driver is loaded.
  
  Unfortunately, any of the drivers in hw_random can be built in.  When
  built in, hwrng_register is going to be called during the kernel
  initialization process.  In that case, the unknownness in X is not 4096
  bits, but far less.  Also, the items that may have seeded X (MAC addr,
  time, etc) are discoverable by a potential attacker.  This is also well
  before random-seed has been fed in.
 
 To which I would respond.. so?

I only saw this line of context pop on my phone last night, and that led
me to a train of thought.  In short, I agree with you, and I actually
now prefer Kees patch in it's original form.

 If the pool is in an attacker-knowable state at early boot, adding
 attacker-controlled data does not make the situation any worse. In fact,
 if the attacker has less-than-perfect control of the inputs, mixing more
 things in will make things exponentially harder for the attacker.

Just to clarify my understanding: Say we have inputs A, B, C, W, X, Y,
Z.  A, B are known to the attacker (MAC address, etc), C is the attacker
known hwrng data.  W-Z are small chunks added in from unpredictable
events.

In order to predict a potential set of states at boot, the attacker not
only has to brute force W-Z, but also the order of A-C,W-Z.

Without C, the order of the events becomes more deterministic.  Thus
making the job easier for the attacker.

 Put another way: mixing can't ever removes unknownness from the pool, it
 can only add more. So the only reason you should ever choose not to mix
 something into the pool is performance.

I also need to clarify an assumption I made in this thread.  I focused
too heavily on Attacker1, who has secret knowledge of the internal
workings of the hwrng.  As we've established above, his job isn't made
easier by adding hwrng data during system boot.

In addition, Attacker2 through AttackerN who _don't_ have the secret
knowledge of the hwrng, but do know the MAC address and other initial
inputs are defeated by adding the hwrng during system boot.

Matt, thanks for taking the time to come out of retirement to help us
with this.  Kees, thanks for your patience :)

thx,

Jason.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH][RESEND 3] hwrng: add randomness to system from rng sources

[Jason Cooper]

On Mon, Mar 03, 2014 at 03:51:48PM -0800, Kees Cook wrote:
 When bringing a new RNG source online, it seems like it would make sense
 to use some of its bytes to make the system entropy pool more random,
 as done with all sorts of other devices that contain per-device or
 per-boot differences.
 
 Signed-off-by: Kees Cook keesc...@chromium.org
 ---
  drivers/char/hw_random/core.c |7 +++
  1 file changed, 7 insertions(+)

fwiw,

Reviewed-by: Jason Cooper ja...@lakedaemon.net

thx,

Jason.

 diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
 index a0f7724852eb..6e5bb68a708c 100644
 --- a/drivers/char/hw_random/core.c
 +++ b/drivers/char/hw_random/core.c
 @@ -41,6 +41,7 @@
  #include linux/miscdevice.h
  #include linux/delay.h
  #include linux/slab.h
 +#include linux/random.h
  #include asm/uaccess.h
  
  
 @@ -305,6 +306,8 @@ int hwrng_register(struct hwrng *rng)
   int must_register_misc;
   int err = -EINVAL;
   struct hwrng *old_rng, *tmp;
 + unsigned char bytes[16];
 + int bytes_read;
  
   if (rng-name == NULL ||
   (rng-data_read == NULL  rng-read == NULL))
 @@ -348,6 +351,10 @@ int hwrng_register(struct hwrng *rng)
   }
   INIT_LIST_HEAD(rng-list);
   list_add_tail(rng-list, rng_list);
 +
 + bytes_read = rng_get_data(rng, bytes, sizeof(bytes), 1);
 + if (bytes_read  0)
 + add_device_randomness(bytes, bytes_read);
  out_unlock:
   mutex_unlock(rng_mutex);
  out:
 -- 
 1.7.9.5
 
 
 -- 
 Kees Cook
 Chrome OS Security
 --
 To unsubscribe from this list: send the line unsubscribe linux-crypto in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH][RESEND 3] hwrng: add randomness to system from rng sources

[Jason Cooper]

Matt, Kees,

On Tue, Mar 04, 2014 at 04:39:57PM -0600, Matt Mackall wrote:
 On Tue, 2014-03-04 at 11:59 -0800, Kees Cook wrote:
  On Tue, Mar 4, 2014 at 11:53 AM, Jason Cooper ja...@lakedaemon.net wrote:
   On Tue, Mar 04, 2014 at 11:01:49AM -0800, Kees Cook wrote:
   On Tue, Mar 4, 2014 at 7:38 AM, Jason Cooper ja...@lakedaemon.net 
   wrote:
On Mon, Mar 03, 2014 at 03:51:48PM -0800, Kees Cook wrote:
...
  Well, I think there's confusion here over the hwrng and a hwrng. I
  have devices with multiple entropy sources, and all my hwrngs are
  built as modules, so I choose when to load them into my kernel. The
  arch-specific entropy source (e.g. RDRAND) is very different.

Dynamically loading modules _after_ boot is fine.  Especially with
Matt's clear explanation.  I'm not concerned about that scenario.

   Please understand, my point-of-view is as someone who installs Linux on
   equipment *after* purchase (hobbyist, tinkers).  If I control the part
   selection and sourcing of the board components, of course I have more
   trust in the hwrng.
  
   So my situation is similar to buying an Intel based laptop.  I can't do
   a special order at Bestbuy and ask for a system without the RDRAND
   instruction.  Same with the hobbyist market.  We buy the gear, but we
   have no control over what's inside it.
  
   In that situation, without this patch, I would enable the hwrng for the
   board.  With the patch in it's current form, I would start looking for
   research papers and discussions regarding using the hwrng for input.  If
   the patch provided arch_get_random_long(), I would feel comfortable
   enabling the hwrng.
  
   Perhaps I'm being too conservative, but I'd rather have the discussion
   now and have concerns proven unfounded than have someone say How the
   hell did this happen? three releases down the road.
  
  Sure, and I don't want to be the one weakening the entropy pool.
 
 [temporarily coming out of retirement to provide a clue]

Thanks, Matt!

 The pool mixing function is intentionally _reversible_. This is a
 crucial security property.
 
 That means, if I have an initial secret pool state X, and hostile
 attacker controlled data Y, then we can do:
 
 X' = mix(X, Y)
 
  and 
 
 X = unmix(X', Y)
 
 We can see from this that the combination of (X' and Y) still contain
 the information that was originally in X. Since it's clearly not in Y..
 it must all remain in X'.
 
 In other words, if there are 4096 bits of unknownness in X to start
 with, and I can get those same 4096 bits of unknownness back by
 unmixing X' and Y, then there must still be 4096 bits of unknownness
 in X'. If X' is 4096 bits long, then we've just proven that
 reversibility means the attacker can know nothing about the contents of
 X' by his choice of Y.

Well, this reinforces my comfortability with loadable modules.  The pool
is already initialized by the point at which the driver is loaded.

Unfortunately, any of the drivers in hw_random can be built in.  When
built in, hwrng_register is going to be called during the kernel
initialization process.  In that case, the unknownness in X is not 4096
bits, but far less.  Also, the items that may have seeded X (MAC addr,
time, etc) are discoverable by a potential attacker.  This is also well
before random-seed has been fed in.

That's the crux of my concern with this patch.  Basically, the user can
choose 'y' over 'm', say when building a dedicated system w/o loadable
modules, and not realize how much more trust he has placed in the hwrng.

How does this patch look?  I'm not claiming my change is acceptable for
mainline, just seeking feedback on the concept.  IS_MODULE() really
doesn't have many users afaict.

This builds without warning on ARCH=arm with multi_v7_defconfig when
HW_RANDOM={y,m,n}

thx,

Jason.

8--
commit 0fcc0669ee4bbeae355c0f61f79a6b319a32ba12
Author: Kees Cook keesc...@chromium.org
Date:   Mon Mar 3 15:51:48 2014 -0800

hwrng: add randomness to system from rng sources

When bringing a new RNG source online, it seems like it would make sense
to use some of its bytes to make the system entropy pool more random,
as done with all sorts of other devices that contain per-device or
per-boot differences.

[jac] prevent the code from being called at boot up, before the entropy
pool has had time to build and be well initialized.  We do this by
making the code conditional on being built as a module.

Signed-off-by: Kees Cook keesc...@chromium.org
Signed-off-by: Jason Cooper ja...@lakedaemon.net

diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index a0f7724852eb..5c3314cbf671 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -41,6 +41,8 @@
 #include linux/miscdevice.h
 #include linux/delay.h
 #include linux/slab.h
+#include linux/random.h
+#include linux/kconfig.h
 #include asm/uaccess.h
 
 
@@ -305,6 +307,10 @@ int

Re: [PATCH][RESEND 3] hwrng: add randomness to system from rng sources

[Jason Cooper]

Kees, Ted,

On Mon, Mar 03, 2014 at 03:51:48PM -0800, Kees Cook wrote:
 When bringing a new RNG source online, it seems like it would make sense
 to use some of its bytes to make the system entropy pool more random,
 as done with all sorts of other devices that contain per-device or
 per-boot differences.

Why is this necessary?  init_std_data() already calls
arch_get_random_long() while stirring each of the pools.

I'm a little concerned here because this gives potentially untrusted
hwrngs more influence over the entropy pools initial state than most
users of random.c expect.  Many of the drivers in hw_random/ are
platform drivers and are initialized before random.c.

I'm comfortable with the design decisions Ted has made wrt random.c and
hwrngs.  However, I think that this changes that trust relationship in a
fundamental way.  I'm ok with building support into my kernels for
hwrngs as long as random.c's internal use of them is limited to the
mixing in extract_buf() and init_std_data().

By adding this patch, even without crediting entropy to the pool, a
rogue hwrng now has significantly more influence over the initial state
of the entropy pools.  Or, am I missing something?

thx,

Jason.

 Signed-off-by: Kees Cook keesc...@chromium.org
 ---
  drivers/char/hw_random/core.c |7 +++
  1 file changed, 7 insertions(+)
 
 diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
 index a0f7724852eb..6e5bb68a708c 100644
 --- a/drivers/char/hw_random/core.c
 +++ b/drivers/char/hw_random/core.c
 @@ -41,6 +41,7 @@
  #include linux/miscdevice.h
  #include linux/delay.h
  #include linux/slab.h
 +#include linux/random.h
  #include asm/uaccess.h
  
  
 @@ -305,6 +306,8 @@ int hwrng_register(struct hwrng *rng)
   int must_register_misc;
   int err = -EINVAL;
   struct hwrng *old_rng, *tmp;
 + unsigned char bytes[16];
 + int bytes_read;
  
   if (rng-name == NULL ||
   (rng-data_read == NULL  rng-read == NULL))
 @@ -348,6 +351,10 @@ int hwrng_register(struct hwrng *rng)
   }
   INIT_LIST_HEAD(rng-list);
   list_add_tail(rng-list, rng_list);
 +
 + bytes_read = rng_get_data(rng, bytes, sizeof(bytes), 1);
 + if (bytes_read  0)
 + add_device_randomness(bytes, bytes_read);
  out_unlock:
   mutex_unlock(rng_mutex);
  out:
 -- 
 1.7.9.5
 
 
 -- 
 Kees Cook
 Chrome OS Security
 --
 To unsubscribe from this list: send the line unsubscribe linux-crypto in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH][RESEND 3] hwrng: add randomness to system from rng sources

[Jason Cooper]

On Tue, Mar 04, 2014 at 11:01:49AM -0800, Kees Cook wrote:
 On Tue, Mar 4, 2014 at 7:38 AM, Jason Cooper ja...@lakedaemon.net wrote:
  Kees, Ted,
 
  On Mon, Mar 03, 2014 at 03:51:48PM -0800, Kees Cook wrote:
  When bringing a new RNG source online, it seems like it would make sense
  to use some of its bytes to make the system entropy pool more random,
  as done with all sorts of other devices that contain per-device or
  per-boot differences.
 
  Why is this necessary?  init_std_data() already calls
  arch_get_random_long() while stirring each of the pools.
 
 I may be misunderstanding something here, but hwrng isn't going to get
 hit by a arch_get_random_long(). 

ahh, you are correct.  It appears it's only used on x86 and powerpc.
Bad assumption on my part.

 That's just for arch-specific RNGs (e.g. RDRAND), where as hwrng is
 for, effectively, add-on devices (e.g. TPMs).
 
  I'm a little concerned here because this gives potentially untrusted
  hwrngs more influence over the entropy pools initial state than most
  users of random.c expect.  Many of the drivers in hw_random/ are
  platform drivers and are initialized before random.c.
 
  I'm comfortable with the design decisions Ted has made wrt random.c and
  hwrngs.  However, I think that this changes that trust relationship in a
  fundamental way.  I'm ok with building support into my kernels for
  hwrngs as long as random.c's internal use of them is limited to the
  mixing in extract_buf() and init_std_data().
 
  By adding this patch, even without crediting entropy to the pool, a
  rogue hwrng now has significantly more influence over the initial state
  of the entropy pools.  Or, am I missing something?
 
 I wasn't viewing this as dealing with rouge hwrngs (though shouldn't
 that state still be covered due to the existing mixing), but more as a
 hey this thing has some randomness associated with it, similar to
 the mixing done for things like NIC MAC, etc. (Better, actually, since
 NIC MAC is going to be the same every boot.) It seemed silly to ignore
 an actual entropy source when seeding.

Agreed, but I think we need to be careful about how random.c interacts
with any hwrng.  Ideally, the drivers in hw_random/ could provide
arch_get_random_long().  This way, random.c still determines when and
how to use the hwrng.

Ultimately, the user (person compiling the kernel) will decide to trust
or not trust the hwrng by enabling support for it or not.  My concern
with this patch is that it changes the magnitude of that trust decision.
And only the most diligent user would discover the change.

To date, all discussion wrt random.c and hwrngs are that the output of
the hwrng (in particular, RDRAND) is XORd with the output of the mixer.
Now, we're saying it can provide input as well.  

Please understand, my point-of-view is as someone who installs Linux on
equipment *after* purchase (hobbyist, tinkers).  If I control the part
selection and sourcing of the board components, of course I have more
trust in the hwrng.

So my situation is similar to buying an Intel based laptop.  I can't do
a special order at Bestbuy and ask for a system without the RDRAND
instruction.  Same with the hobbyist market.  We buy the gear, but we
have no control over what's inside it.

In that situation, without this patch, I would enable the hwrng for the
board.  With the patch in it's current form, I would start looking for
research papers and discussions regarding using the hwrng for input.  If
the patch provided arch_get_random_long(), I would feel comfortable
enabling the hwrng.

Perhaps I'm being too conservative, but I'd rather have the discussion
now and have concerns proven unfounded than have someone say How the
hell did this happen? three releases down the road.

thx,

Jason.


  Signed-off-by: Kees Cook keesc...@chromium.org
  ---
   drivers/char/hw_random/core.c |7 +++
   1 file changed, 7 insertions(+)
 
  diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
  index a0f7724852eb..6e5bb68a708c 100644
  --- a/drivers/char/hw_random/core.c
  +++ b/drivers/char/hw_random/core.c
  @@ -41,6 +41,7 @@
   #include linux/miscdevice.h
   #include linux/delay.h
   #include linux/slab.h
  +#include linux/random.h
   #include asm/uaccess.h
 
 
  @@ -305,6 +306,8 @@ int hwrng_register(struct hwrng *rng)
int must_register_misc;
int err = -EINVAL;
struct hwrng *old_rng, *tmp;
  + unsigned char bytes[16];
  + int bytes_read;
 
if (rng-name == NULL ||
(rng-data_read == NULL  rng-read == NULL))
  @@ -348,6 +351,10 @@ int hwrng_register(struct hwrng *rng)
}
INIT_LIST_HEAD(rng-list);
list_add_tail(rng-list, rng_list);
  +
  + bytes_read = rng_get_data(rng, bytes, sizeof(bytes), 1);
  + if (bytes_read  0)
  + add_device_randomness(bytes, bytes_read);
   out_unlock:
mutex_unlock(rng_mutex);
   out:
  --
  1.7.9.5
 
 
  --
  Kees Cook
  Chrome OS Security

Re: [PATCH] Crypto: CESA: Add support for DT based instantiation.

[Jason Cooper]

On Mon, Sep 03, 2012 at 08:29:34PM +0200, Andrew Lunn wrote:
 Based on work by Michael Waller and Jason Cooper.
 
 Added support for getting the interrupt number and address of SRAM
 from DT.
 
 Signed-off-by: Andrew Lunn and...@lunn.ch

Applied to:

git://git.infradead.org/users/jcooper/linux.git kirkwood/dt

thx,

Jason.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Crypto: CESA: Add support for DT based instantiation.

[Jason Cooper]

On Mon, Sep 03, 2012 at 08:29:34PM +0200, Andrew Lunn wrote:
 Based on work by Michael Waller and Jason Cooper.

nit.  Michael Walle

If nothing significant crops up in the next few days, I'll fix it when I
pull it in.

thx,

Jason.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto: fix build failure in mv_cesa.c (missing of header)

[Jason Cooper]

On Fri, Mar 09, 2012 at 02:58:25PM -0500, Paul Gortmaker wrote:
 Commit 737b75872487f560397ba34846a19823b1addf88 (linux-next)
 
 ARM: kirkwood: mv_cesa devicetree bindings
 
 fails to compile as follows:
 
  CC  drivers/crypto/mv_cesa.o
  drivers/crypto/mv_cesa.c:1139: error: implicit declaration of function 
 'of_match_ptr'
  drivers/crypto/mv_cesa.c:1139: error: 'mv_cesa_dt_ids' undeclared here (not 
 in a function)
  drivers/crypto/mv_cesa.c:1139: error: initializer element is not constant
  drivers/crypto/mv_cesa.c:1139: error: (near initialization for 
 'marvell_crypto.driver.of_match_table')
 
 because it is missing the linux/of.h header file.
 
 Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com

Paul,

Thanks for the patch.  Unfortunately, I'm not learning fast enough.  ;-)
This series has been in a lot of flux lately, as you've experienced.

The good news is, after talking with Olaf and Arnd, I think I have a
good workflow figured out.  Hopefully, failures like this won't happen
in the future.

As an fyi, I'm probably going to take kirkwood_dt_staging down (or, label
it broken ;-) )  I intended it as a publicly viewable branch of what's
coming down the pipe, but it's not working out the way I intended.

As for mv_cesa, it's next on my list.  As soon as I figure out the irq
stuff.

Thanks for testing.

Jason.

 
 diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
 index b7a3d48..093e214 100644
 --- a/drivers/crypto/mv_cesa.c
 +++ b/drivers/crypto/mv_cesa.c
 @@ -10,6 +10,7 @@
  #include crypto/algapi.h
  #include linux/crypto.h
  #include linux/interrupt.h
 +#include linux/of.h
  #include linux/io.h
  #include linux/kthread.h
  #include linux/platform_device.h
 -- 
 1.7.9.1
 
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html