* Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
From: Theodore Ts'o @ 2013-10-12 3:28 UTC (permalink / raw)
To: Sandy Harris; +Cc: Stephan Mueller, LKML, linux-crypto
In-Reply-To: <CACXcFm=qdv9ktjYDGo+L=ssh+tCs7vVniznNpXyWVTBSB1CMRg@mail.gmail.com>
Hi Stephan,
I haven't had a chance to look at your paper in detail, yet, but a
quick scan has found a huge red flag for me that puts the rest of your
analysis in severe doubt for me.
You say that you got really good results and perfect statistical
entropy on a number of platforms, including on an MIPS embedded
system. You also say that you are harvesting jitter by using
get_cycles() yes?
Well, on the MIPS platform, here is the definition of get_cycles:
static inline cycles_t get_cycles(void)
{
return 0;
}
So if you are getting great entropy results when in effect you
couldn't possibly be harvesting any jitter at all, then something is
really, Really, REALLY wrong with your tests.
One might be that you are just getting great statistical results
because of the whitening step. This is why I have very little faith
in statistical tests of randomness, given that they will return
perfect results for the following "random number generator"
AES_ENCRYPT(i++, NSA_KEY)
Regards,
- Ted
^ permalink raw reply
* Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
From: Stephan Mueller @ 2013-10-12 19:04 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: Sandy Harris, LKML, linux-crypto
In-Reply-To: <20131012032835.GC30680@thunk.org>
Am Freitag, 11. Oktober 2013, 23:28:35 schrieb Theodore Ts'o:
Hi Theodore,
>Hi Stephan,
>
>I haven't had a chance to look at your paper in detail, yet, but a
>quick scan has found a huge red flag for me that puts the rest of your
>analysis in severe doubt for me.
>
>You say that you got really good results and perfect statistical
>entropy on a number of platforms, including on an MIPS embedded
>system. You also say that you are harvesting jitter by using
>get_cycles() yes?
>
>Well, on the MIPS platform, here is the definition of get_cycles:
>
>static inline cycles_t get_cycles(void)
>{
> return 0;
>}
There are multiple catches to this issue:
- First, if the time gathering function does not work or is to coarse,
the function jent_entropy_init() returns an error. As outlined in
jitterentropy(3), the result of this function must be honored before
using the RNG.
- Second, the time stamp function of jent_get_nstime uses
__getnstimeofday in case get_cycles returns zero (see implementation of
jent_get_nstime()). On MIPS systems with missing get_cycles, the RNG
would use the __getnstimeofday() as get_cycles returns 0. When using the
RNG in user space, it calls clock_gettime(CLOCK_REALTIME) that is backed
by the same timer of__getnstimeofday on MIPS.
Please consider the use of the jent_entropy_init function in the two
patches for /dev/random and kernel crypto API:
/dev/random:
+ /* we are uninitialized, try to initialize */
+ if(jent_entropy_init())
+ {
+ /* there is no CPU Jitter, disable the entropy
collector */
+ r->jent_enable = 0;
+ return;
+ }
kernel crypto API:
static int __init jent_drng_init(void)
{
...
ret = jent_entropy_init();
if(ret)
{
printk(DRIVER_NAME ": Initialization failed with host
not compliant with requirements: %d\n", ret);
return -EFAULT;
}
>
>So if you are getting great entropy results when in effect you
>couldn't possibly be harvesting any jitter at all, then something is
>really, Really, REALLY wrong with your tests.
>
>One might be that you are just getting great statistical results
>because of the whitening step. This is why I have very little faith
There is *no* whitening function (cryptographic or otherwise) involved
in the generation of random data. All is done by harvesting time deltas
and align them appropriately. This is the sole reason why the heart of
the RNG is only 30 lines of code.
I have added arguments about broken time stamp collections in section
4.3 of the documentation in [2]. These anti tests clearly show that
broken time stamps would be immediately visible and not disguised by
some whitening function.
Note, the testing of the 200+ systems is tone by measuring the jitter of
the core of the RNG. The measurement is logically similar to measure the
different add_*_randomness functions for random.c. Thus, even the logic
to arrange the timing values to a random value bit stream does not
affect the measurements.
>in statistical tests of randomness, given that they will return
>perfect results for the following "random number generator"
>
> AES_ENCRYPT(i++, NSA_KEY)
>
>Regards,
>
> - Ted
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
From: Stephan Mueller @ 2013-10-12 20:12 UTC (permalink / raw)
To: Sandy Harris; +Cc: Theodore Ts'o, LKML, linux-crypto
In-Reply-To: <CACXcFm=qdv9ktjYDGo+L=ssh+tCs7vVniznNpXyWVTBSB1CMRg@mail.gmail.com>
Am Freitag, 11. Oktober 2013, 21:45:57 schrieb Sandy Harris:
Hi Sandy,
>On Fri, Oct 11, 2013 at 2:38 PM, Stephan Mueller <smueller@chronox.de>
>wrote:
>
>I like the basic idea. Here I'm alternately reading the email and the
>page you link to & commenting on both.
Thank you very much for reviewing both and sharing your thoughts.
>
>A nitpick in the paper is that you cite RFC 1750. That was superceded
>some years back by RFC 4086
>http://tools.ietf.org/html/rfc4086
Thank you for the link. I updated the reference in the paper. Though,
the Von-Neumann unbias operation is way older than this RFC and I just
listed the RFC to give people a reference.
>
>(Ted's comments in the actual driver had the same problem last
>I looked. That is excusable since they were written long ago.)
>
>I think you may be missing some other citations that should be
>there, to previous work along similar lines. One is the HAVEGE
>work, another:
>McGuire, Okech & Schiesser,
>Analysis of inherent randomness of the Linux kernel,
>http://lwn.net/images/conf/rtlws11/random-hardware.pdf
Thank you for the reminder. I added section 1.1.
>
>Paper has:
>
>" the time delta is partitioned into chunks of 1 bit starting at the
>lowest bit " .... The 64 1 bit chunks of the time value are XORed with
>each other to " form a 1 bit value.
>
>As I read that, you are just taking the parity. Why not use that
>simpler description & possibly one of several possible optimised
>algorithms for the task:
>http://graphics.stanford.edu/~seander/bithacks.html
I am fully aware that the bit operation is inefficient. Yet it is
deliberately inefficient, because that "folding loop" performs actual
work for the RNG (the collapse of 64 bits into one bit) and at the very
same time, it is the fixed instruction set over which I measure the time
variations.
Thus, the folding loop can be considered as the entropy source at the
same time. Thus, when making it shorter or more efficient, we alter the
duration of the loop. With significantly shorter durations, the jitter
measurements will get smaller.
That issue is the sole reason why that code part of the RNG shall be
compiled without optimizations. The compiler is clever enough to arrange
my inefficient operation into something faster when optimizing. You
clearly see that with Clang: the unoptimized folding loop code takes
about 300 nanoseconds on my i7 2nd gen. Optimized, it takes about 40 ns!
At the same time, the jitter is lower (it is still sufficient, but the
cushion is smaller).
As the RNG is not primarily about speed, the folding operation should
stay inefficient.
>
>If what you are doing is not a parity computation, then you need a
>better description so people like me do not misread it.
It is not a parity computation that the folding loop performs. The code
XORs each individual bit of the 64 bit stream with each other, whereas
your cited document implies an ANDing of the bits (see section
"Computing parity the naive way" of the cited document). The reason is
that the different bits contain entropy -- the lower the bit index, the
more entropy they are assumed to have. The only operation to retain
entropy and yet collapse a bit string is to use XOR. Any other operation
will result in the fact that you cannot make any statement about the
entropy behavior any more.
The rationale about the folding loop is given in section 5.1 [2].
>
>A bit later you have:
>
>" After obtaining the 1 bit folded and unbiased time stamp,
>" how is it mixed into the entropy pool? ... The 1 bit folded
>" value is XORed with 1 bit from the entropy pool.
>
>This appears to be missing the cryptographically strong
>mixing step which most RNG code includes. If that is
>what you are doing, you need to provide some strong
>arguments to justify it.
The key here is that there is no cryptographic function needed for
mixing as in fact I am not really mixing things. I am simply
concatenating the new bit to the previously obtained bits. That is it.
The argument for doing that is that the time deltas are independent of
each other. Yet, these deltas show variations which are collapsed into
the one bit that is the result of the folding loop. Therefore, the
individual bits are independent of each other and yet contain the
variations of the jitter. Now, there is no need to apply a cryptographic
function for further mixing.
The key here is that the variations in the time deltas must be *larger*
than one bit. What does that mean? For example, if the variation would
be, say 50% of 250 ns and 50% of 251 ns, we have 1 bit variation
(considering that each individual measurement is independent of the
others). Or, if you have 30% with 249ns, 20% with 250%, 25% with 251 and
25% with 252ns, you have more than one bit. You see, that this line of
thought brings us to the Shannon Entropy formula. And now we come to the
200+ test systems that I tested on: all with the exception of one very
old system showed a variation with the lower boundary of more than one
bit. Therefore, each bit from the folding operation therefore contains
one bit of entropy. So, why should I mix it even further with some
crypto function?
>
>Sometimes doing without is justified; for example my
>code along these lines
>ftp://ftp.cs.sjtu.edu.cn:990/sandy/maxwell/
>does more mixing than I see in yours, but probably
>not enough overall. That's OK because I am just
>feeding into /dev/random which has plenty of
>mixing.
>
>It is OK for your code too if you are feeding into
>/dev/random, but it looks problematic if your code
>is expected to stand alone.
Please consider use case of the CPU Jitter RNG: it is intended as a seed
source for deterministic RNGs. That is how the various integration
patches for the kernel crypto API, /dev/random, OpenSSL, libgcrypt or
even the stand-alone entropy feeding daemon operate. Thus, you have a
whitening function when using it together with such DRNGs.
Yet, the code allows other users that may want entropy (NSS or even
stand-alone DRNGs come to mind) to simply use that noise source without
the burden of another whitening function to their DRNGs.
>
>Ah! You talk about whitening a bit later. However,
>you seem to make it optional, up to the user. I
>cannot see that that is a good idea.
Why is whitening a good idea in the first place when the statistical
properties of your output already are white noise? When applying all
kinds of statistical test to my non-whitened output, I do not see any
statistical significant odd behavior -- ent (Chi-Square test, mean test,
monte carlo simulation), dieharder tests, various tests from the German
BSI, NIST test suite.
And if you say that your entropy source has problems, then your
whitening function only disguises the fact but does not remedy it.
Please refer to section 4.3 of my document in [2] where I have some
"anti" tests with broken timers. Such brokenness would be immediately
visible for anybody without a whitening function (such as the jitter
RNG). But if the jitter RNG would use a whitening function, the missing
entropy would not be visible.
Also, the RNG is intended as a seeding mechanism for all kinds of use
cases. The typical one is the seeding of a DRNG of your choice. This is
one more reason why I consider the use of a whitening function as not
helpful.
>
>At the very least I think you need something like
>the linear transform from the ARIA cipher -- fast
>and cheap, 128 bits in & 128 out and it makes
>every output bit depend on every input bit. That
>might not be enough, though.
Can you please help me understand why you think that a whitening
function (cryptographic or not) is needed in the case of the CPU Jitter
RNG, provided that I can show that each individual bit coming from the
folding operation has one bit of entropy?
>
>You require compilation without optimisation. How does
>that interact with kernel makefiles? Can you avoid
>undesirable optimisations in some other way, such as
>volatile declartions?
That is very easy to implement, see the kernel Makefile for my code:
...
obj-m += jitterentropy.o
CFLAGS_jitterentropy-base.o = -O0
jitterentropy-y := jitterentropy-base.o jitterentropy-drng.o
...
This code implies that only the compilation of jitterentropy-base.c is
performed with -O0. Any other C file from my code or even the reminder
of the kernel is compiled with the optimization the kernel developer
deemed right.
>
>> I am asking whether this RNG would good as an inclusion into the
>> Linux
>> kernel for:
>>
>> - kernel crypto API to provide a true random number generator as part
>> of this API (see [2] appendix B for a description)
>
>My first reaction is no. We have /dev/random for the userspace
>API and there is a decent kernel API too. I may change my
>mind here as I look more at your appendix & maybe the code.
The concern with /dev/random and its get_random_bytes() function is that
inside the kernel, we only have the equivalent of /dev/urandom.
Therefore, in the worst case, you have *no* guarantee that you obtain
random numbers that are freshly seeded with hardware entropy.
For example, when you look into libgcrypt and you want to have "strong
random numbers", libgcrypt seeds from /dev/random every 1000 or so
random numbers produced from the DRNG.
Due to the ability of user space to obtain data via the nonblocking_pool
using /dev/urandom and the use of the same pool for get_random_bytes,
equally strong random numbers as, for example, libgcrypt would produce
would not be available.
Therefore, the code linking with the kernel crypto API registers three
RNGs:
- one X9.31 DRNG that is seeded "once in a while" with the CPU jitter
- one X9.31 DRNG that is seeded "frequently" with the CPU jitter
- and one direct access to the CPU jitter RNG
This is logically equivalent to what is done in libgcrypt.
Of course, we may replace the X9.31 with, say, an SP800-90A DRBG, if
that becomes available.
Furthermore, one of the core ideas of the CPU jitter RNG is that you get
away from the centralized noise source of /dev/random. Such central
services are also the focus for hackers. The CPU Jitter RNG allows
multiple instantiations of the noise source into independent components.
Every "user" of random data may now have its own private copy of a noise
source and its operation.
>
>> - inclusion into /dev/random as an entropy provider of last resort
>> when the entropy estimator falls low.
>
>Why only 'of last resort'? If it can provide good entropy, we should
>use it often.
I did not dare to be more than a provider of last resort at this point.
The CPU jitter RNG is new and I guess people may want to study it first.
>From my point of view, it surely can become one "regular" source. But as
it delivers entropy on demand, it may simply outpace any other entropy
source of /dev/random. This means, in some normal use cases, my CPU
jitter RNG would always be the provider of the majority of the entropy,
by far. Therefore, my CPU Jitter RNG would alter the nature of
/dev/random significantly.
If Ted thinks that this is ok, I am all for it and will change the
patch. But I tried to be cautious and not to overwhelm people :-)
>
>> I will present the RNG at the Linux Symposium in Ottawa this year.
>> There I can give a detailed description of the design and testing.
>
>I live in Ottawa, don't know if I'll make it to the Symposium this
>year. Ted; I saw you at one Symposium; are you coming this
>year?
As mentioned before, I would really like to meet you there to have a cup
of coffee over that matter.
Ciao
Stephan
^ permalink raw reply
* [PATCH] crypto: mv_cesa: remove deprecated IRQF_DISABLED
From: Michael Opdenacker @ 2013-10-13 4:49 UTC (permalink / raw)
To: herbert, davem; +Cc: linux-crypto, linux-kernel, Michael Opdenacker
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
---
drivers/crypto/mv_cesa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 3374a3e..e0f9ed4 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -1084,7 +1084,7 @@ static int mv_probe(struct platform_device *pdev)
goto err_unmap_sram;
}
- ret = request_irq(irq, crypto_int, IRQF_DISABLED, dev_name(&pdev->dev),
+ ret = request_irq(irq, crypto_int, 0, dev_name(&pdev->dev),
cp);
if (ret)
goto err_thread;
--
1.8.1.2
^ permalink raw reply related
* Fwd: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
From: Sandy Harris @ 2013-10-14 13:38 UTC (permalink / raw)
To: Theodore Ts'o, LKML, linux-crypto, Stephan Mueller
In-Reply-To: <CACXcFm=_jmeKe2YYbHDi-jTGX-23hDsDeu_weWQkr2F_FpE_6g@mail.gmail.com>
Stephan Mueller <smueller@chronox.de> wrote:
>>Paper has:
>>
>>" the time delta is partitioned into chunks of 1 bit starting at the
>>lowest bit " .... The 64 1 bit chunks of the time value are XORed with
>>each other to " form a 1 bit value.
>>
>>As I read that, you are just taking the parity. Why not use that
>>simpler description & possibly one of several possible optimised
>>algorithms for the task:
>>http://graphics.stanford.edu/~seander/bithacks.html
>
> I am fully aware that the bit operation is inefficient. Yet it is
> deliberately inefficient, because that "folding loop" performs actual
> work for the RNG (the collapse of 64 bits into one bit) and at the very
> same time, it is the fixed instruction set over which I measure the time
> variations.
>
> Thus, the folding loop can be considered as the entropy source ...
>
> As the RNG is not primarily about speed, the folding operation should
> stay inefficient.
OK, that makes sense.
>>If what you are doing is not a parity computation, then you need a
>>better description so people like me do not misread it.
>
> It is not a parity computation that the folding loop performs. The code
> XORs each individual bit of the 64 bit stream with each other, whereas
> your cited document implies an ANDing of the bits (see section
> "Computing parity the naive way" of the cited document).
No. The AND is used in a trick; x&(x-1) gives a value with exactly
one bit set, the lowest bit set in x. The code there just counts that
way for efficiency.
Parity asks whether the number of set bits is odd or even. For
example this is another way to find the parity of x.
for( p = 0; x ; x >>= 1 )
p ^= (x&1) ;
>From your description (I haven't looked at the code) you are
computing parity. If so, say that. If not, explain.
>>This appears to be missing the cryptographically strong
>>mixing step which most RNG code includes. If that is
>>what you are doing, you need to provide some strong
>>arguments to justify it.
>
> The key here is that there is no cryptographic function needed for
> mixing as in fact I am not really mixing things. I am simply
> concatenating the new bit to the previously obtained bits. That is it.
>
> The argument for doing that is that the time deltas are independent of
> each other. ...
> ... each bit from the folding operation therefore contains
> one bit of entropy. So, why should I mix it even further with some
> crypto function?
That does make sense, but in security code I tend to prefer a
belt-and-suspenders approach. Even believing that each
individual bit is truly random, I'd still mix some just in case.
> Can you please help me understand why you think that a whitening
> function (cryptographic or not) is needed in the case of the CPU Jitter
> RNG, provided that I can show that each individual bit coming from the
> folding operation has one bit of entropy?
Basically, sheer paranoia. I'd mix and whiten just on general
principles. Since efficiency is not a large concern, there is little
reason not to.
On the other hand, most RNGs use a hash because they need
to distill some large amount of low-entropy input into a smaller
high-entropy output. With high input entropy, you do not need
the hash and can choose some cheaper mixer.
>>> I will present the RNG at the Linux Symposium in Ottawa this year.
>>> ....
>>
>>I live in Ottawa, ...
>
> As mentioned before, I would really like to meet you there to have a cup
> of coffee over that matter.
Sounds good. Ted, will you be around?
^ permalink raw reply
* Re: Fwd: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
From: Stephan Mueller @ 2013-10-14 14:12 UTC (permalink / raw)
To: Sandy Harris; +Cc: Theodore Ts'o, LKML, linux-crypto
In-Reply-To: <CACXcFm=3Ee1+HGYRpsjhFMwqn2t15qAZNnMpZ8jOsE_HkB2CPg@mail.gmail.com>
Am Montag, 14. Oktober 2013, 09:38:34 schrieb Sandy Harris:
Hi Sandy,
>Stephan Mueller <smueller@chronox.de> wrote:
>
>>>If what you are doing is not a parity computation, then you need a
>>>better description so people like me do not misread it.
>>>
>> It is not a parity computation that the folding loop performs. The
>> code XORs each individual bit of the 64 bit stream with each other,
>> whereas your cited document implies an ANDing of the bits (see
>> section "Computing parity the naive way" of the cited document).
>
>No. The AND is used in a trick; x&(x-1) gives a value with exactly
>one bit set, the lowest bit set in x. The code there just counts that
>way for efficiency.
>
>Parity asks whether the number of set bits is odd or even. For
>example this is another way to find the parity of x.
>
> for( p = 0; x ; x >>= 1 )
> p ^= (x&1) ;
>
>From your description (I haven't looked at the code) you are
>computing parity. If so, say that. If not, explain.
I re-read the referenced documentation. Yes, what I do is a parity
calculation. But I do not want to think that way, although technically
it is.
The reason and the goal of the implementation is the following: To
maintain a mathematical model in which the entropy is preserved, I can
only perform the following operations:
1. Use of concatenation which in terms of entropy implies that two
values concatenated with each other add the entropy the two values
contain. For example: string a contains 4 bits of entropy, string b
contains 6 bits of entropy. Now, when concatenating both, I get 10 bits
of entropy in the combined string.
2. The use of XOR implies that the resulting value has the maximum
entropy of the two individual strings. With the same example above, a
XOR b implies that the resulting string has 6 bits of entropy.
Any other operation will loose entropy in a way that is not easily to be
modeled.
Now, back to the folding loop: I know that the lower bits have some
entropy. When collapsing them into one single bit, I "slice" the 64 bit
timer value into 64 1 bit values and XOR the 64 bit values together. The
goal is to preserve the entropy each bit holds.
(PS: I am aware that in case none of the individual bits would contain
one full bit of entropy, the folding operation may --mathematically
spoken-- not deliver one full bit of entropy. However, after speaking
with a mathematician, that slight inconsistency is ok, if I can show
that the distribution of the folded bit is 50% zeros and 50% ones. That
is what I did in section 5.2.1. Thus, the conclusion is that I receive
one bit of entropy after the folding loop.)
Yes, that is equal to parity calculation. But the reference to a parity
calculation is not defined when you want to apply a mathematical model
to entropy maintenance. Thus, I would rather like to have a consistent
design description that I can easily apply to the entropy discussion.
>
>>>This appears to be missing the cryptographically strong
>>>mixing step which most RNG code includes. If that is
>>>what you are doing, you need to provide some strong
>>>arguments to justify it.
>>>
>> The key here is that there is no cryptographic function needed for
>> mixing as in fact I am not really mixing things. I am simply
>> concatenating the new bit to the previously obtained bits. That is
>> it.
>>
>> The argument for doing that is that the time deltas are independent
>> of
>> each other. ...
>>
>> ... each bit from the folding operation therefore contains
>> one bit of entropy. So, why should I mix it even further with some
>> crypto function?
>
>That does make sense, but in security code I tend to prefer a
>belt-and-suspenders approach. Even believing that each
>individual bit is truly random, I'd still mix some just in case.
I am with you on the potential for further mixing. However, please note
that the standard hashes are all surjective and not bijective. Thus,
they implicitly loose entropy (albeit it is not much). Therefore, a good
mixing function would be a symmetric cipher.
Also, I tried to have my code portable to a large variety of target
systems. All of them have crypto libraries with a great number of cipher
implementation, but which suffer from the lack of entropy. Thus, I
concluded that I do not want to re-invent the wheel by reimplementing
some cipher, but only provide what is missing: a decentral entropy
source that delivers entropy on demand in kernel and user space.
Who would be a user of the CPU Jitter RNG? I hardly believe that a
normal end user would use it, but rather it would be provided via some
crypto lib. And the authors of a crypto lib surely know how to handle
the seed source (I hope).
This all is the reason why I implemented the different links to various
crypto libraries, where the kernel crypto API is one of it. The CPU
Jitter RNG is no a stand-alone system, but always linked with a DRNG
that is frequently seeded by the CPU Jitter RNG.
>
>> Can you please help me understand why you think that a whitening
>> function (cryptographic or not) is needed in the case of the CPU
>> Jitter RNG, provided that I can show that each individual bit coming
>> from the folding operation has one bit of entropy?
>
>Basically, sheer paranoia. I'd mix and whiten just on general
>principles. Since efficiency is not a large concern, there is little
>reason not to.
I am ok with that, when you consider the surjective/bijective argument
above. Still, as mentioned above, I think that will be covered by the
"users" of the CPU jitter RNG.
>
>On the other hand, most RNGs use a hash because they need
>to distill some large amount of low-entropy input into a smaller
>high-entropy output. With high input entropy, you do not need
>the hash and can choose some cheaper mixer.
IMHO, that decision is left to the user of the code. Some users are
forced to use some DRNGs (e.g. FIPS comes to mind). Thus, I do not want
to do things that will need to be re-done in a slightly different way
again. This is what I see as inefficient complexity that I truly want to
avoid.
>
>>>> I will present the RNG at the Linux Symposium in Ottawa this year.
>>>> ....
>>>
>>>I live in Ottawa, ...
>>>
>> As mentioned before, I would really like to meet you there to have a
>> cup of coffee over that matter.
>
>Sounds good. Ted, will you be around?
Thanks
Stephan
^ permalink raw reply
* Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
From: Sandy Harris @ 2013-10-14 14:14 UTC (permalink / raw)
To: Theodore Ts'o, LKML, linux-crypto, Stephan Mueller
In-Reply-To: <CACXcFm=3Ee1+HGYRpsjhFMwqn2t15qAZNnMpZ8jOsE_HkB2CPg@mail.gmail.com>
On Mon, Oct 14, 2013 at 9:38 AM, Sandy Harris <sandyinchina@gmail.com> wrote:
> Stephan Mueller <smueller@chronox.de> wrote:
>> Can you please help me understand why you think that a whitening
>> function (cryptographic or not) is needed in the case of the CPU Jitter
>> RNG, provided that I can show that each individual bit coming from the
>> folding operation has one bit of entropy?
>
> Basically, sheer paranoia. I'd mix and whiten just on general
> principles. Since efficiency is not a large concern, there is little
> reason not to.
>
> On the other hand, most RNGs use a hash because they need
> to distill some large amount of low-entropy input into a smaller
> high-entropy output. With high input entropy, you do not need
> the hash and can choose some cheaper mixer.
You could use strong mixing/whitening:
Feed into random(4) and let it do the mixing.
Use some early outputs from your RNG to key an AES
instance. Then encrypt later outputs; this gives a 64 in 64
out mixer that is cryptographically strong but perhaps a bit
slow in the context.
Alternately, quite a few plausible components for fast cheap
mixing are readily available.
The Aria cipher has one that is 128 in 128 out. It multiplies
a 128-bit object by a fixed Boolean matrix, makes every
output bit depend on many input bits. It is fairly cheap,
used in every round and the cipher is acceptably fast.
The column transform from AES is 32 in 32 out and makes
every output byte depend on every input byte. It is fast; has
to be since it is used four times in every round.
A two-way pseudo-Hadamard transform (PHT) is 2n bits in
and 2n out, requires only two additions, makes both n-bit
outputs depend on both inputs.
PHT can be applied recursively to mix 4n, 8n, ...
My QHT is 32 in 32 out, makes every /bit/ of output
depend on every bit of input. It is a tad expensive;
two multiplications & two modulo operations. File
qht.c at:
ftp://ftp.cs.sjtu.edu.cn:990/sandy/maxwell/
To mix 64 bits, I'd use two qht() calls to mix the 32-bit
halves then a two-way PHT.
^ permalink raw reply
* Re: Fwd: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
From: Stephan Mueller @ 2013-10-14 14:26 UTC (permalink / raw)
To: Sandy Harris; +Cc: Theodore Ts'o, LKML, linux-crypto
In-Reply-To: <5084508.OCAIYQezeq@tauon>
Am Montag, 14. Oktober 2013, 16:12:24 schrieb Stephan Mueller:
Hi Sandy,
>
>(PS: I am aware that in case none of the individual bits would contain
>one full bit of entropy, the folding operation may --mathematically
>spoken-- not deliver one full bit of entropy. However, after speaking
>with a mathematician, that slight inconsistency is ok, if I can show
>that the distribution of the folded bit is 50% zeros and 50% ones. That
>is what I did in section 5.2.1. Thus, the conclusion is that I receive
>one bit of entropy after the folding loop.)
One followup on this issue: if one believes that he has a problem with
that consideration, he can initialize the CPU Jitter RNG with an
oversampling rate. That rate simply performs the folding operation 64
times oversampling rate.
To fill the entropy pool completely once, the RNG needs 64 time deltas
which are folded into the one bit. All the oversampling rate now does is
to calculate more than once the complete entropy pool.
For example, when you set the oversampling rate to 2, you need twice as
long for the random value as each bit the random value is calculated
twice. And the two independent 64 bit random values are simply XORed
together.
You can set the oversampling rate to any value above 1.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
From: Stephan Mueller @ 2013-10-14 14:40 UTC (permalink / raw)
To: Sandy Harris; +Cc: Theodore Ts'o, LKML, linux-crypto
In-Reply-To: <CACXcFmnDjSWHrU-4dR=Nb5n-9t=0PmM9Bc_pOFMTi3eotR2g6A@mail.gmail.com>
Am Montag, 14. Oktober 2013, 10:14:00 schrieb Sandy Harris:
Hi Sandy,
>On Mon, Oct 14, 2013 at 9:38 AM, Sandy Harris <sandyinchina@gmail.com>
wrote:
>> Stephan Mueller <smueller@chronox.de> wrote:
>>> Can you please help me understand why you think that a whitening
>>> function (cryptographic or not) is needed in the case of the CPU
>>> Jitter RNG, provided that I can show that each individual bit
>>> coming from the folding operation has one bit of entropy?
>>
>> Basically, sheer paranoia. I'd mix and whiten just on general
>> principles. Since efficiency is not a large concern, there is little
>> reason not to.
>>
>> On the other hand, most RNGs use a hash because they need
>> to distill some large amount of low-entropy input into a smaller
>> high-entropy output. With high input entropy, you do not need
>> the hash and can choose some cheaper mixer.
>
>You could use strong mixing/whitening:
>
>Feed into random(4) and let it do the mixing.
That is exactly the goal with the patch found in patches/linux-3.9-
random.patch in the code distribution.
And that approach is exactly what I do in the linking code / patches for
other crypto libs:
- kernel crypto API
- OpenSSL (implementation as an Engine that uses the internal DRNGs or a
hook into RAND_poll that implements the seeding for the DRNGs)
- libgcrypt (hook into the seeding of the DRNGs)
>
>Use some early outputs from your RNG to key an AES
>instance. Then encrypt later outputs; this gives a 64 in 64
>out mixer that is cryptographically strong but perhaps a bit
>slow in the context.
That is exactly what the SP800-90A CTR DRBG or the X9.31 does. As these
DRNGs are available for different crypto libs, I am simply reusing them
with the crypto lib linking code.
>
>Alternately, quite a few plausible components for fast cheap
>mixing are readily available.
Thank you for the references. I have seen that in your maxwell(8)
documentation. But again, I do not re-invent the wheel with the CPU
Jitter RNG and therefore skipped the whitening step based on the reasons
above.
Another thing: when you start adding whitening functions, other people
are starting (and did -- thus I added section 4.3 to my documentation)
to complain that you hide your weaknesses behind the whiteners. I simply
want to counter that argument and show that RNG produces white noise
without a whitener.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
From: Sandy Harris @ 2013-10-14 15:18 UTC (permalink / raw)
To: Stephan Mueller; +Cc: Theodore Ts'o, LKML, linux-crypto
In-Reply-To: <3593500.a7fOuGKlEX@tauon>
On Mon, Oct 14, 2013 at 10:40 AM, Stephan Mueller <smueller@chronox.de> wrote:
> Another thing: when you start adding whitening functions, other people
> are starting (and did -- thus I added section 4.3 to my documentation)
> to complain that you hide your weaknesses behind the whiteners. I simply
> want to counter that argument and show that RNG produces white noise
> without a whitener.
Yes, you absolutely have to test the unwhitened input entropy, and
provide a way for others to test it so they can have confidence in your
code and it can be tested again if it is going to be used on some new
host. You do a fine job of that; your paper has the most detailed
analysis I have seen. Bravo.
However, having done that, I see no reason not to add mixing.
Using bit() for getting one bit of input and rotl(x) for rotating
left one bit, your code is basically, with 64-bit x:
for( i=0, x = 0 ; i < 64; i++, x =rotl(x) )
x |= bit()
Why not declare some 64-bit constant C with a significant
number of bits set and do this:
for( i=0, x = 0 ; i < 64; i++, x =rotl(x) ) // same loop control
if( bit() ) x ^= C ;
This makes every output bit depend on many input bits
and costs almost nothing extra.
In the unlikely event that the overhead here matters,
your deliberately inefficient parity calculation in bit()
could easily be made faster to compensate.
^ permalink raw reply
* Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
From: Stephan Mueller @ 2013-10-14 15:26 UTC (permalink / raw)
To: Sandy Harris; +Cc: Theodore Ts'o, LKML, linux-crypto
In-Reply-To: <CACXcFm=M2Jrra3tttWyhwfs-a6iVm0joiKi=wHKuANe_s_F-Sw@mail.gmail.com>
Am Montag, 14. Oktober 2013, 11:18:16 schrieb Sandy Harris:
Hi Sandy,
>On Mon, Oct 14, 2013 at 10:40 AM, Stephan Mueller <smueller@chronox.de>
wrote:
>> Another thing: when you start adding whitening functions, other
>> people
>> are starting (and did -- thus I added section 4.3 to my
>> documentation)
>> to complain that you hide your weaknesses behind the whiteners. I
>> simply want to counter that argument and show that RNG produces
>> white noise without a whitener.
>
>Yes, you absolutely have to test the unwhitened input entropy, and
>provide a way for others to test it so they can have confidence in your
>code and it can be tested again if it is going to be used on some new
>host. You do a fine job of that; your paper has the most detailed
>analysis I have seen. Bravo.
Thank you very much.
>
>However, having done that, I see no reason not to add mixing.
>Using bit() for getting one bit of input and rotl(x) for rotating
>left one bit, your code is basically, with 64-bit x:
>
> for( i=0, x = 0 ; i < 64; i++, x =rotl(x) )
> x |= bit()
Ok, let me play a bit with that. Maybe I can add another flag to the
allocation function so that the caller can decide whether to use that.
If the user is another RNG, you skip that mixing function, otherwise you
should take it.
But I need a whitening / mixing function that should not add more
dependencies on the underlying host. The code you have above would be
ok.
>
>Why not declare some 64-bit constant C with a significant
Which constant would you take? The CRC twist values? The SHA-1 initial
values? Or the first few from SHA-256?
>number of bits set and do this:
>
> for( i=0, x = 0 ; i < 64; i++, x =rotl(x) ) // same loop control
> if( bit() ) x ^= C ;
>
>This makes every output bit depend on many input bits
>and costs almost nothing extra.
Good point.
>
>In the unlikely event that the overhead here matters,
>your deliberately inefficient parity calculation in bit()
>could easily be made faster to compensate.
I will come back to you on this suggestion.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
From: Sandy Harris @ 2013-10-14 15:46 UTC (permalink / raw)
To: Stephan Mueller; +Cc: Theodore Ts'o, LKML, linux-crypto
In-Reply-To: <1420251.G1iR4tbUp8@tauon>
On Mon, Oct 14, 2013 at 11:26 AM, Stephan Mueller <smueller@chronox.de> wrote:
>>Why not declare some 64-bit constant C with a significant
>
> Which constant would you take? The CRC twist values? The SHA-1 initial
> values? Or the first few from SHA-256?
The only essential requirement is that it not be something stupidly
regular like a 64-bit string 0x5555555555555555.
I'd pick an odd number so the low bit always changes, and a
constant with about half the bits set, maybe 24 < n < 40 or
some such. I'm not certain either of those is strictly required
but I'd do them anyway.
^ permalink raw reply
* [PATCH] crypto: atmel-aes - add support for Device Tree
From: Nicolas Ferre @ 2013-10-14 16:35 UTC (permalink / raw)
To: linux-arm-kernel, ebenard, linux-crypto, herbert
Cc: linux-kernel, Nicolas Ferre
Add support for Device Tree and use of the DMA DT API to
get the needed channels.
Documentation is added for these DT nodes.
Initial code by: Nicolas Royer and Eukrea.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
.../devicetree/bindings/crypto/atmel-crypto.txt | 23 ++++
drivers/crypto/atmel-aes.c | 143 ++++++++++++++-------
2 files changed, 117 insertions(+), 49 deletions(-)
create mode 100644 Documentation/devicetree/bindings/crypto/atmel-crypto.txt
diff --git a/Documentation/devicetree/bindings/crypto/atmel-crypto.txt b/Documentation/devicetree/bindings/crypto/atmel-crypto.txt
new file mode 100644
index 0000000..d273f0b
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/atmel-crypto.txt
@@ -0,0 +1,23 @@
+* Atmel HW cryptographic accelerators
+
+These are the HW cryptographic accelerators found on some Atmel products.
+
+* Advanced Encryption Standard (AES)
+
+Required properties:
+- compatible : Should be "atmel,at91sam9g46-aes".
+- reg: Should contain AES registers location and length.
+- interrupts: Should contain the IRQ line for the AES.
+- dmas: List of two DMA specifiers as described in
+ atmel-dma.txt and dma.txt files.
+- dma-names: Contains one identifier string for each DMA specifier
+ in the dmas property.
+
+Example:
+aes@f8038000 {
+ compatible = "atmel,at91sam9g46-aes";
+ reg = <0xf8038000 0x100>;
+ interrupts = <43 4 0>;
+ dmas = <&dma1 2 18>,
+ <&dma1 2 19>;
+ dma-names = "tx", "rx";
diff --git a/drivers/crypto/atmel-aes.c b/drivers/crypto/atmel-aes.c
index c1efd91..d7c9e31 100644
--- a/drivers/crypto/atmel-aes.c
+++ b/drivers/crypto/atmel-aes.c
@@ -30,6 +30,7 @@
#include <linux/irq.h>
#include <linux/scatterlist.h>
#include <linux/dma-mapping.h>
+#include <linux/of_device.h>
#include <linux/delay.h>
#include <linux/crypto.h>
#include <linux/cryptohash.h>
@@ -39,6 +40,7 @@
#include <crypto/hash.h>
#include <crypto/internal/hash.h>
#include <linux/platform_data/crypto-atmel.h>
+#include <dt-bindings/dma/at91.h>
#include "atmel-aes-regs.h"
#define CFB8_BLOCK_SIZE 1
@@ -747,59 +749,50 @@ static int atmel_aes_dma_init(struct atmel_aes_dev *dd,
struct crypto_platform_data *pdata)
{
int err = -ENOMEM;
- dma_cap_mask_t mask_in, mask_out;
+ dma_cap_mask_t mask;
+
+ dma_cap_zero(mask);
+ dma_cap_set(DMA_SLAVE, mask);
+
+ /* Try to grab 2 DMA channels */
+ dd->dma_lch_in.chan = dma_request_slave_channel_compat(mask,
+ atmel_aes_filter, &pdata->dma_slave->rxdata, dd->dev, "tx");
+ if (!dd->dma_lch_in.chan)
+ goto err_dma_in;
+
+ dd->dma_lch_in.dma_conf.direction = DMA_MEM_TO_DEV;
+ dd->dma_lch_in.dma_conf.dst_addr = dd->phys_base +
+ AES_IDATAR(0);
+ dd->dma_lch_in.dma_conf.src_maxburst = dd->caps.max_burst_size;
+ dd->dma_lch_in.dma_conf.src_addr_width =
+ DMA_SLAVE_BUSWIDTH_4_BYTES;
+ dd->dma_lch_in.dma_conf.dst_maxburst = dd->caps.max_burst_size;
+ dd->dma_lch_in.dma_conf.dst_addr_width =
+ DMA_SLAVE_BUSWIDTH_4_BYTES;
+ dd->dma_lch_in.dma_conf.device_fc = false;
+
+ dd->dma_lch_out.chan = dma_request_slave_channel_compat(mask,
+ atmel_aes_filter, &pdata->dma_slave->txdata, dd->dev, "rx");
+ if (!dd->dma_lch_out.chan)
+ goto err_dma_out;
+
+ dd->dma_lch_out.dma_conf.direction = DMA_DEV_TO_MEM;
+ dd->dma_lch_out.dma_conf.src_addr = dd->phys_base +
+ AES_ODATAR(0);
+ dd->dma_lch_out.dma_conf.src_maxburst = dd->caps.max_burst_size;
+ dd->dma_lch_out.dma_conf.src_addr_width =
+ DMA_SLAVE_BUSWIDTH_4_BYTES;
+ dd->dma_lch_out.dma_conf.dst_maxburst = dd->caps.max_burst_size;
+ dd->dma_lch_out.dma_conf.dst_addr_width =
+ DMA_SLAVE_BUSWIDTH_4_BYTES;
+ dd->dma_lch_out.dma_conf.device_fc = false;
- if (pdata && pdata->dma_slave->txdata.dma_dev &&
- pdata->dma_slave->rxdata.dma_dev) {
-
- /* Try to grab 2 DMA channels */
- dma_cap_zero(mask_in);
- dma_cap_set(DMA_SLAVE, mask_in);
-
- dd->dma_lch_in.chan = dma_request_channel(mask_in,
- atmel_aes_filter, &pdata->dma_slave->rxdata);
-
- if (!dd->dma_lch_in.chan)
- goto err_dma_in;
-
- dd->dma_lch_in.dma_conf.direction = DMA_MEM_TO_DEV;
- dd->dma_lch_in.dma_conf.dst_addr = dd->phys_base +
- AES_IDATAR(0);
- dd->dma_lch_in.dma_conf.src_maxburst = dd->caps.max_burst_size;
- dd->dma_lch_in.dma_conf.src_addr_width =
- DMA_SLAVE_BUSWIDTH_4_BYTES;
- dd->dma_lch_in.dma_conf.dst_maxburst = dd->caps.max_burst_size;
- dd->dma_lch_in.dma_conf.dst_addr_width =
- DMA_SLAVE_BUSWIDTH_4_BYTES;
- dd->dma_lch_in.dma_conf.device_fc = false;
-
- dma_cap_zero(mask_out);
- dma_cap_set(DMA_SLAVE, mask_out);
- dd->dma_lch_out.chan = dma_request_channel(mask_out,
- atmel_aes_filter, &pdata->dma_slave->txdata);
-
- if (!dd->dma_lch_out.chan)
- goto err_dma_out;
-
- dd->dma_lch_out.dma_conf.direction = DMA_DEV_TO_MEM;
- dd->dma_lch_out.dma_conf.src_addr = dd->phys_base +
- AES_ODATAR(0);
- dd->dma_lch_out.dma_conf.src_maxburst = dd->caps.max_burst_size;
- dd->dma_lch_out.dma_conf.src_addr_width =
- DMA_SLAVE_BUSWIDTH_4_BYTES;
- dd->dma_lch_out.dma_conf.dst_maxburst = dd->caps.max_burst_size;
- dd->dma_lch_out.dma_conf.dst_addr_width =
- DMA_SLAVE_BUSWIDTH_4_BYTES;
- dd->dma_lch_out.dma_conf.device_fc = false;
-
- return 0;
- } else {
- return -ENODEV;
- }
+ return 0;
err_dma_out:
dma_release_channel(dd->dma_lch_in.chan);
err_dma_in:
+ dev_warn(dd->dev, "no DMA channel available\n");
return err;
}
@@ -1261,6 +1254,47 @@ static void atmel_aes_get_cap(struct atmel_aes_dev *dd)
}
}
+#if defined(CONFIG_OF)
+static const struct of_device_id atmel_aes_dt_ids[] = {
+ { .compatible = "atmel,at91sam9g46-aes" },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, atmel_aes_dt_ids);
+
+static struct crypto_platform_data *atmel_aes_of_init(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct crypto_platform_data *pdata;
+
+ if (!np) {
+ dev_err(&pdev->dev, "device node not found\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(&pdev->dev, "could not allocate memory for pdata\n");
+ return ERR_PTR(-ENOMEM);
+ }
+
+ pdata->dma_slave = devm_kzalloc(&pdev->dev,
+ sizeof(*(pdata->dma_slave)),
+ GFP_KERNEL);
+ if (!pdata->dma_slave) {
+ dev_err(&pdev->dev, "could not allocate memory for dma_slave\n");
+ devm_kfree(&pdev->dev, pdata);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ return pdata;
+}
+#else
+static inline struct crypto_platform_data *atmel_aes_of_init(struct platform_device *pdev)
+{
+ return ERR_PTR(-EINVAL);
+}
+#endif
+
static int atmel_aes_probe(struct platform_device *pdev)
{
struct atmel_aes_dev *aes_dd;
@@ -1272,6 +1306,14 @@ static int atmel_aes_probe(struct platform_device *pdev)
pdata = pdev->dev.platform_data;
if (!pdata) {
+ pdata = atmel_aes_of_init(pdev);
+ if (IS_ERR(pdata)) {
+ err = PTR_ERR(pdata);
+ goto aes_dd_err;
+ }
+ }
+
+ if (!pdata->dma_slave) {
err = -ENXIO;
goto aes_dd_err;
}
@@ -1358,7 +1400,9 @@ static int atmel_aes_probe(struct platform_device *pdev)
if (err)
goto err_algs;
- dev_info(dev, "Atmel AES\n");
+ dev_info(dev, "Atmel AES - Using %s, %s for DMA transfers\n",
+ dma_chan_name(aes_dd->dma_lch_in.chan),
+ dma_chan_name(aes_dd->dma_lch_out.chan));
return 0;
@@ -1424,6 +1468,7 @@ static struct platform_driver atmel_aes_driver = {
.driver = {
.name = "atmel_aes",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(atmel_aes_dt_ids),
},
};
--
1.8.2.2
^ permalink raw reply related
* [PATCH 1/3] ARM: at91/dt/trivial: use macro for AES irq type
From: Nicolas Ferre @ 2013-10-14 16:46 UTC (permalink / raw)
To: linux-arm-kernel, ebenard
Cc: linux-kernel, linux-crypto, herbert, Nicolas Ferre
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/boot/dts/sama5d3.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index ca956b6..b2aabff 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -350,7 +350,7 @@
aes@f8038000 {
compatible = "atmel,sam9g46-aes";
reg = <0xf8038000 0x100>;
- interrupts = <43 4 0>;
+ interrupts = <43 IRQ_TYPE_LEVEL_HIGH 0>;
};
tdes@f803c000 {
--
1.8.2.2
^ permalink raw reply related
* [PATCH 2/3] ARM: at91/dt/trivial: before sama5d3, Atmel MPU were using at91 prefix
From: Nicolas Ferre @ 2013-10-14 16:46 UTC (permalink / raw)
To: linux-arm-kernel, ebenard
Cc: linux-kernel, linux-crypto, herbert, Nicolas Ferre
In-Reply-To: <ba9872c3bb29c9a06f06caa8e0b4528329f07675.1381769174.git.nicolas.ferre@atmel.com>
Change the sha/aes/tdes compatibility string to match common
case for the at91sam9g45 family which is to keep the at91 prefix.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/boot/dts/sama5d3.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index b2aabff..99bd4a6 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -342,19 +342,19 @@
};
sha@f8034000 {
- compatible = "atmel,sam9g46-sha";
+ compatible = "atmel,at91sam9g46-sha";
reg = <0xf8034000 0x100>;
interrupts = <42 IRQ_TYPE_LEVEL_HIGH 0>;
};
aes@f8038000 {
- compatible = "atmel,sam9g46-aes";
+ compatible = "atmel,at91sam9g46-aes";
reg = <0xf8038000 0x100>;
interrupts = <43 IRQ_TYPE_LEVEL_HIGH 0>;
};
tdes@f803c000 {
- compatible = "atmel,sam9g46-tdes";
+ compatible = "atmel,at91sam9g46-tdes";
reg = <0xf803c000 0x100>;
interrupts = <44 IRQ_TYPE_LEVEL_HIGH 0>;
};
--
1.8.2.2
^ permalink raw reply related
* [PATCH 3/3] ARM: at91/dt/sama5d3: add DMA information to SHA/AES/TDES nodes
From: Nicolas Ferre @ 2013-10-14 16:46 UTC (permalink / raw)
To: linux-arm-kernel, ebenard
Cc: linux-kernel, linux-crypto, herbert, Nicolas Ferre
In-Reply-To: <ba9872c3bb29c9a06f06caa8e0b4528329f07675.1381769174.git.nicolas.ferre@atmel.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/boot/dts/sama5d3.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index 99bd4a6..aca3893 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -345,18 +345,26 @@
compatible = "atmel,at91sam9g46-sha";
reg = <0xf8034000 0x100>;
interrupts = <42 IRQ_TYPE_LEVEL_HIGH 0>;
+ dmas = <&dma1 2 AT91_DMA_CFG_PER_ID(17)>;
+ dma-names = "tx";
};
aes@f8038000 {
compatible = "atmel,at91sam9g46-aes";
reg = <0xf8038000 0x100>;
interrupts = <43 IRQ_TYPE_LEVEL_HIGH 0>;
+ dmas = <&dma1 2 AT91_DMA_CFG_PER_ID(18)>,
+ <&dma1 2 AT91_DMA_CFG_PER_ID(19)>;
+ dma-names = "tx", "rx";
};
tdes@f803c000 {
compatible = "atmel,at91sam9g46-tdes";
reg = <0xf803c000 0x100>;
interrupts = <44 IRQ_TYPE_LEVEL_HIGH 0>;
+ dmas = <&dma1 2 AT91_DMA_CFG_PER_ID(20)>,
+ <&dma1 2 AT91_DMA_CFG_PER_ID(21)>;
+ dma-names = "tx", "rx";
};
dma0: dma-controller@ffffe600 {
--
1.8.2.2
^ permalink raw reply related
* Re: [PATCH 2/3] ARM: at91/dt/trivial: before sama5d3, Atmel MPU were using at91 prefix
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-10-14 17:09 UTC (permalink / raw)
To: Nicolas Ferre
Cc: linux-crypto, linux-kernel, ebenard, linux-arm-kernel, herbert
In-Reply-To: <a7f43a96aaf83c3348dc631c71c54729f9d0e9e0.1381769174.git.nicolas.ferre@atmel.com>
On 18:46 Mon 14 Oct , Nicolas Ferre wrote:
> Change the sha/aes/tdes compatibility string to match common
> case for the at91sam9g45 family which is to keep the at91 prefix.
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> arch/arm/boot/dts/sama5d3.dtsi | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
> index b2aabff..99bd4a6 100644
> --- a/arch/arm/boot/dts/sama5d3.dtsi
> +++ b/arch/arm/boot/dts/sama5d3.dtsi
> @@ -342,19 +342,19 @@
> };
>
> sha@f8034000 {
> - compatible = "atmel,sam9g46-sha";
> + compatible = "atmel,at91sam9g46-sha";
> reg = <0xf8034000 0x100>;
> interrupts = <42 IRQ_TYPE_LEVEL_HIGH 0>;
> };
>
> aes@f8038000 {
> - compatible = "atmel,sam9g46-aes";
> + compatible = "atmel,at91sam9g46-aes";
> reg = <0xf8038000 0x100>;
> interrupts = <43 IRQ_TYPE_LEVEL_HIGH 0>;
> };
>
> tdes@f803c000 {
> - compatible = "atmel,sam9g46-tdes";
> + compatible = "atmel,at91sam9g46-tdes";
> reg = <0xf803c000 0x100>;
> interrupts = <44 IRQ_TYPE_LEVEL_HIGH 0>;
you keep the previous compatible in the driver too for backword compatiblity
Best Regards,
J.
> };
> --
> 1.8.2.2
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
From: Sandy Harris @ 2013-10-14 21:33 UTC (permalink / raw)
To: Stephan Mueller; +Cc: Theodore Ts'o, LKML, linux-crypto
In-Reply-To: <1420251.G1iR4tbUp8@tauon>
Stephan Mueller <smueller@chronox.de> wrote:
> [quoting me]
>> ...your code is basically, with 64-bit x:
>>
>> for( i=0, x = 0 ; i < 64; i++, x =rotl(x) )
>> x |= bit()
>
> Why not declare some 64-bit constant C with a significant
>>number of bits set and do this:
>>
>> for( i=0, x = 0 ; i < 64; i++, x =rotl(x) ) // same loop control
>> if( bit() ) x ^= C ;
>>
>>This makes every output bit depend on many input bits
>>and costs almost nothing extra.
> Ok, let me play a bit with that. Maybe I can add another flag to the
> allocation function so that the caller can decide whether to use that.
> If the user is another RNG, you skip that mixing function, otherwise you
> should take it.
I'd say just do it. It is cheap enough and using it does no harm
even where it is not strictly needed. Adding a flag just gives the
calling code a chance to get it wrong. Better not to take that risk
if you don't have to.
^ permalink raw reply
* Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
From: Stephan Mueller @ 2013-10-15 6:23 UTC (permalink / raw)
To: Sandy Harris; +Cc: Theodore Ts'o, LKML, linux-crypto
In-Reply-To: <CACXcFm=M2Jrra3tttWyhwfs-a6iVm0joiKi=wHKuANe_s_F-Sw@mail.gmail.com>
Am Montag, 14. Oktober 2013, 11:18:16 schrieb Sandy Harris:
Hi Sandy,
Could you please review the following code to see that the mix is
function right in your eyes?
>
>However, having done that, I see no reason not to add mixing.
>Using bit() for getting one bit of input and rotl(x) for rotating
>left one bit, your code is basically, with 64-bit x:
>
> for( i=0, x = 0 ; i < 64; i++, x =rotl(x) )
> x |= bit()
>
>Why not declare some 64-bit constant C with a significant
>number of bits set and do this:
>
> for( i=0, x = 0 ; i < 64; i++, x =rotl(x) ) // same loop control
> if( bit() ) x ^= C ;
I only want to use the XOR function as this is bijective and fits to my
mathematical model.
The entropy_collector->data contains the random number. The code first
produces the mixer value that is XORed as often as set bits are
available in the input random number. Finally, it is XORed with the
random number.
The function is currently called unconditionally after the 64 bit random
number is generated from the noise source.
static inline void jent_stir_pool(struct rand_data *entropy_collector)
{
/* This constant is derived from the first two 32 bit
initialization
* vectors of SHA-1 -- 32 bits are set and 32 are unset */
__u64 constant = 0x67452301efcdab89;
__u64 mixer = 0;
int i = 0;
for(i = 0; i < DATA_SIZE_BITS; i++)
{
/* get the i-th bit of the input random number and
* XOR the constant into the mixer value only when that
bit
* is set */
if((entropy_collector->data >> i) & 0x0000000000000001)
mixer ^= constant;
mixer = rol64(mixer, 1);
}
entropy_collector->data ^= mixer;
}
The statistical behavior of the output looks good so far (just tested it
with the ent tool -- the Chi Square value is good). It also does not
compress with bzip2.
Thanks a lot
Stephan
^ permalink raw reply
* Re: [PATCH 2/3] ARM: at91/dt/trivial: before sama5d3, Atmel MPU were using at91 prefix
From: Nicolas Ferre @ 2013-10-15 8:14 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: linux-arm-kernel, ebenard, herbert, linux-kernel, linux-crypto
In-Reply-To: <20131014170951.GJ11420@ns203013.ovh.net>
On 14/10/2013 19:09, Jean-Christophe PLAGNIOL-VILLARD :
> On 18:46 Mon 14 Oct , Nicolas Ferre wrote:
>> Change the sha/aes/tdes compatibility string to match common
>> case for the at91sam9g45 family which is to keep the at91 prefix.
>>
>> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>> ---
>> arch/arm/boot/dts/sama5d3.dtsi | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
>> index b2aabff..99bd4a6 100644
>> --- a/arch/arm/boot/dts/sama5d3.dtsi
>> +++ b/arch/arm/boot/dts/sama5d3.dtsi
>> @@ -342,19 +342,19 @@
>> };
>>
>> sha@f8034000 {
>> - compatible = "atmel,sam9g46-sha";
>> + compatible = "atmel,at91sam9g46-sha";
>> reg = <0xf8034000 0x100>;
>> interrupts = <42 IRQ_TYPE_LEVEL_HIGH 0>;
>> };
>>
>> aes@f8038000 {
>> - compatible = "atmel,sam9g46-aes";
>> + compatible = "atmel,at91sam9g46-aes";
>> reg = <0xf8038000 0x100>;
>> interrupts = <43 IRQ_TYPE_LEVEL_HIGH 0>;
>> };
>>
>> tdes@f803c000 {
>> - compatible = "atmel,sam9g46-tdes";
>> + compatible = "atmel,at91sam9g46-tdes";
>> reg = <0xf803c000 0x100>;
>> interrupts = <44 IRQ_TYPE_LEVEL_HIGH 0>;
> you keep the previous compatible in the driver too for backword compatiblity
No, as the consumer of the old compatibility string has never been sent
to mainline (or even mailing-list) and as the "dma" property is not
compatible with the one existing on our 3.6.9-based kernel.
So, anyway the DT has to be changed for a move from 3.6.9 => 3.10. As I
do not want to bloat the DT forever, let's stick with this new
compatibility string.
Bye,
>> };
>> --
>> 1.8.2.2
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH 0/5] Authenc key parsing consolidation
From: Mathias Krause @ 2013-10-15 11:49 UTC (permalink / raw)
To: linux-crypto
Cc: Mathias Krause, Herbert Xu, David S. Miller, Christian Hohnstaedt,
Kim Phillips, Jamie Iles
This series removes the code duplication of authenc key parsing by
introducing a common helper function crypto_authenc_extractkeys() in
patch 1. Patches 2 to 5 change all remaining places to use the new
helper. Patches 3 and 4 also fix potential memory corruptions by
ensuring the supplied keys won't overflow there respective buffers.
I was unable to test patches 3 to 5 as I don't have the needed hardware
for these devices -- not even a cross compiler for those architectures.
In case patches 3 and 4 are enqueued for stable, patch 1 needs to be as
well, as it's a prerequisite for those.
Please apply!
Mathias Krause (5):
crypto: authenc - Export key parsing helper function
crypto: authencesn - Simplify key parsing
crypto: ixp4xx - Simplify and harden key parsing
crypto: picoxcell - Simplify and harden key parsing
crypto: talitos - Simplify key parsing
crypto/authenc.c | 48 +++++++++++++++++++++++--------------
crypto/authencesn.c | 26 +++-----------------
drivers/crypto/ixp4xx_crypto.c | 26 +++++++-------------
drivers/crypto/picoxcell_crypto.c | 32 ++++++------------------
drivers/crypto/talitos.c | 35 ++++++--------------------
include/crypto/authenc.h | 12 ++++++++-
6 files changed, 70 insertions(+), 109 deletions(-)
--
1.7.2.5
^ permalink raw reply
* [PATCH 2/5] crypto: authencesn - Simplify key parsing
From: Mathias Krause @ 2013-10-15 11:49 UTC (permalink / raw)
To: linux-crypto
Cc: Mathias Krause, Christian Hohnstaedt, Kim Phillips, Jamie Iles,
Herbert Xu, David S. Miller
In-Reply-To: <cover.1381831574.git.mathias.krause@secunet.com>
Use the common helper function crypto_authenc_extractkeys() for key
parsing.
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Mathias Krause <mathias.krause@secunet.com>
---
crypto/authencesn.c | 26 ++++----------------------
1 files changed, 4 insertions(+), 22 deletions(-)
diff --git a/crypto/authencesn.c b/crypto/authencesn.c
index ab53762..8ed5b47 100644
--- a/crypto/authencesn.c
+++ b/crypto/authencesn.c
@@ -59,37 +59,19 @@ static void authenc_esn_request_complete(struct aead_request *req, int err)
static int crypto_authenc_esn_setkey(struct crypto_aead *authenc_esn, const u8 *key,
unsigned int keylen)
{
- unsigned int authkeylen;
- unsigned int enckeylen;
struct crypto_authenc_esn_ctx *ctx = crypto_aead_ctx(authenc_esn);
struct crypto_ahash *auth = ctx->auth;
struct crypto_ablkcipher *enc = ctx->enc;
- struct rtattr *rta = (void *)key;
- struct crypto_authenc_key_param *param;
+ struct crypto_authenc_keys keys;
int err = -EINVAL;
- if (!RTA_OK(rta, keylen))
+ if (crypto_authenc_extractkeys(&keys, key, keylen) != 0)
goto badkey;
- if (rta->rta_type != CRYPTO_AUTHENC_KEYA_PARAM)
- goto badkey;
- if (RTA_PAYLOAD(rta) < sizeof(*param))
- goto badkey;
-
- param = RTA_DATA(rta);
- enckeylen = be32_to_cpu(param->enckeylen);
-
- key += RTA_ALIGN(rta->rta_len);
- keylen -= RTA_ALIGN(rta->rta_len);
-
- if (keylen < enckeylen)
- goto badkey;
-
- authkeylen = keylen - enckeylen;
crypto_ahash_clear_flags(auth, CRYPTO_TFM_REQ_MASK);
crypto_ahash_set_flags(auth, crypto_aead_get_flags(authenc_esn) &
CRYPTO_TFM_REQ_MASK);
- err = crypto_ahash_setkey(auth, key, authkeylen);
+ err = crypto_ahash_setkey(auth, keys.authkey, keys.authkeylen);
crypto_aead_set_flags(authenc_esn, crypto_ahash_get_flags(auth) &
CRYPTO_TFM_RES_MASK);
@@ -99,7 +81,7 @@ static int crypto_authenc_esn_setkey(struct crypto_aead *authenc_esn, const u8 *
crypto_ablkcipher_clear_flags(enc, CRYPTO_TFM_REQ_MASK);
crypto_ablkcipher_set_flags(enc, crypto_aead_get_flags(authenc_esn) &
CRYPTO_TFM_REQ_MASK);
- err = crypto_ablkcipher_setkey(enc, key + authkeylen, enckeylen);
+ err = crypto_ablkcipher_setkey(enc, keys.enckey, keys.enckeylen);
crypto_aead_set_flags(authenc_esn, crypto_ablkcipher_get_flags(enc) &
CRYPTO_TFM_RES_MASK);
--
1.7.2.5
^ permalink raw reply related
* [PATCH 1/5] crypto: authenc - Export key parsing helper function
From: Mathias Krause @ 2013-10-15 11:49 UTC (permalink / raw)
To: linux-crypto
Cc: Mathias Krause, Christian Hohnstaedt, Kim Phillips, Jamie Iles,
Herbert Xu, David S. Miller
In-Reply-To: <cover.1381831574.git.mathias.krause@secunet.com>
AEAD key parsing is duplicated to multiple places in the kernel. Add a
common helper function to consolidate that functionality.
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Mathias Krause <mathias.krause@secunet.com>
---
crypto/authenc.c | 48 ++++++++++++++++++++++++++++-----------------
include/crypto/authenc.h | 12 ++++++++++-
2 files changed, 41 insertions(+), 19 deletions(-)
diff --git a/crypto/authenc.c b/crypto/authenc.c
index ffce19d..0fda5ba 100644
--- a/crypto/authenc.c
+++ b/crypto/authenc.c
@@ -52,40 +52,52 @@ static void authenc_request_complete(struct aead_request *req, int err)
aead_request_complete(req, err);
}
-static int crypto_authenc_setkey(struct crypto_aead *authenc, const u8 *key,
- unsigned int keylen)
+int crypto_authenc_extractkeys(struct crypto_authenc_keys *keys, const u8 *key,
+ unsigned int keylen)
{
- unsigned int authkeylen;
- unsigned int enckeylen;
- struct crypto_authenc_ctx *ctx = crypto_aead_ctx(authenc);
- struct crypto_ahash *auth = ctx->auth;
- struct crypto_ablkcipher *enc = ctx->enc;
- struct rtattr *rta = (void *)key;
+ struct rtattr *rta = (struct rtattr *)key;
struct crypto_authenc_key_param *param;
- int err = -EINVAL;
if (!RTA_OK(rta, keylen))
- goto badkey;
+ return -EINVAL;
if (rta->rta_type != CRYPTO_AUTHENC_KEYA_PARAM)
- goto badkey;
+ return -EINVAL;
if (RTA_PAYLOAD(rta) < sizeof(*param))
- goto badkey;
+ return -EINVAL;
param = RTA_DATA(rta);
- enckeylen = be32_to_cpu(param->enckeylen);
+ keys->enckeylen = be32_to_cpu(param->enckeylen);
key += RTA_ALIGN(rta->rta_len);
keylen -= RTA_ALIGN(rta->rta_len);
- if (keylen < enckeylen)
- goto badkey;
+ if (keylen < keys->enckeylen)
+ return -EINVAL;
- authkeylen = keylen - enckeylen;
+ keys->authkeylen = keylen - keys->enckeylen;
+ keys->authkey = key;
+ keys->enckey = key + keys->authkeylen;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(crypto_authenc_extractkeys);
+
+static int crypto_authenc_setkey(struct crypto_aead *authenc, const u8 *key,
+ unsigned int keylen)
+{
+ struct crypto_authenc_ctx *ctx = crypto_aead_ctx(authenc);
+ struct crypto_ahash *auth = ctx->auth;
+ struct crypto_ablkcipher *enc = ctx->enc;
+ struct crypto_authenc_keys keys;
+ int err = -EINVAL;
+
+ if (crypto_authenc_extractkeys(&keys, key, keylen) != 0)
+ goto badkey;
crypto_ahash_clear_flags(auth, CRYPTO_TFM_REQ_MASK);
crypto_ahash_set_flags(auth, crypto_aead_get_flags(authenc) &
CRYPTO_TFM_REQ_MASK);
- err = crypto_ahash_setkey(auth, key, authkeylen);
+ err = crypto_ahash_setkey(auth, keys.authkey, keys.authkeylen);
crypto_aead_set_flags(authenc, crypto_ahash_get_flags(auth) &
CRYPTO_TFM_RES_MASK);
@@ -95,7 +107,7 @@ static int crypto_authenc_setkey(struct crypto_aead *authenc, const u8 *key,
crypto_ablkcipher_clear_flags(enc, CRYPTO_TFM_REQ_MASK);
crypto_ablkcipher_set_flags(enc, crypto_aead_get_flags(authenc) &
CRYPTO_TFM_REQ_MASK);
- err = crypto_ablkcipher_setkey(enc, key + authkeylen, enckeylen);
+ err = crypto_ablkcipher_setkey(enc, keys.enckey, keys.enckeylen);
crypto_aead_set_flags(authenc, crypto_ablkcipher_get_flags(enc) &
CRYPTO_TFM_RES_MASK);
diff --git a/include/crypto/authenc.h b/include/crypto/authenc.h
index e47b044..6775059 100644
--- a/include/crypto/authenc.h
+++ b/include/crypto/authenc.h
@@ -23,5 +23,15 @@ struct crypto_authenc_key_param {
__be32 enckeylen;
};
-#endif /* _CRYPTO_AUTHENC_H */
+struct crypto_authenc_keys {
+ const u8 *authkey;
+ const u8 *enckey;
+
+ unsigned int authkeylen;
+ unsigned int enckeylen;
+};
+int crypto_authenc_extractkeys(struct crypto_authenc_keys *keys, const u8 *key,
+ unsigned int keylen);
+
+#endif /* _CRYPTO_AUTHENC_H */
--
1.7.2.5
^ permalink raw reply related
* [PATCH 3/5] crypto: ixp4xx - Simplify and harden key parsing
From: Mathias Krause @ 2013-10-15 11:49 UTC (permalink / raw)
To: linux-crypto
Cc: Mathias Krause, Christian Hohnstaedt, Kim Phillips, Jamie Iles,
Herbert Xu, David S. Miller
In-Reply-To: <cover.1381831574.git.mathias.krause@secunet.com>
Use the common helper function crypto_authenc_extractkeys() for key
parsing. Also ensure the keys do fit into the corresponding buffers.
Otherwise memory corruption might occur.
Cc: Christian Hohnstaedt <chohnstaedt@innominate.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Mathias Krause <mathias.krause@secunet.com>
---
Not tested as I've no such hardware, nor the needed cross compiler!
drivers/crypto/ixp4xx_crypto.c | 26 +++++++++-----------------
1 files changed, 9 insertions(+), 17 deletions(-)
diff --git a/drivers/crypto/ixp4xx_crypto.c b/drivers/crypto/ixp4xx_crypto.c
index 21180d6..153f73c 100644
--- a/drivers/crypto/ixp4xx_crypto.c
+++ b/drivers/crypto/ixp4xx_crypto.c
@@ -1159,32 +1159,24 @@ static int aead_setkey(struct crypto_aead *tfm, const u8 *key,
unsigned int keylen)
{
struct ixp_ctx *ctx = crypto_aead_ctx(tfm);
- struct rtattr *rta = (struct rtattr *)key;
- struct crypto_authenc_key_param *param;
+ struct crypto_authenc_keys keys;
- if (!RTA_OK(rta, keylen))
- goto badkey;
- if (rta->rta_type != CRYPTO_AUTHENC_KEYA_PARAM)
- goto badkey;
- if (RTA_PAYLOAD(rta) < sizeof(*param))
+ if (crypto_authenc_extractkeys(&keys, key, keylen) != 0)
goto badkey;
- param = RTA_DATA(rta);
- ctx->enckey_len = be32_to_cpu(param->enckeylen);
-
- key += RTA_ALIGN(rta->rta_len);
- keylen -= RTA_ALIGN(rta->rta_len);
+ if (keys.authkeylen > sizeof(ctx->authkey))
+ goto badkey;
- if (keylen < ctx->enckey_len)
+ if (keys.enckeylen > sizeof(ctx->enckey))
goto badkey;
- ctx->authkey_len = keylen - ctx->enckey_len;
- memcpy(ctx->enckey, key + ctx->authkey_len, ctx->enckey_len);
- memcpy(ctx->authkey, key, ctx->authkey_len);
+ memcpy(ctx->authkey, keys.authkey, keys.authkeylen);
+ memcpy(ctx->enckey, keys.enckey, keys.enckeylen);
+ ctx->authkey_len = keys.authkeylen;
+ ctx->enckey_len = keys.enckeylen;
return aead_setup(tfm, crypto_aead_authsize(tfm));
badkey:
- ctx->enckey_len = 0;
crypto_aead_set_flags(tfm, CRYPTO_TFM_RES_BAD_KEY_LEN);
return -EINVAL;
}
--
1.7.2.5
^ permalink raw reply related
* [PATCH 4/5] crypto: picoxcell - Simplify and harden key parsing
From: Mathias Krause @ 2013-10-15 11:49 UTC (permalink / raw)
To: linux-crypto
Cc: Mathias Krause, Christian Hohnstaedt, Kim Phillips, Jamie Iles,
Herbert Xu, David S. Miller
In-Reply-To: <cover.1381831574.git.mathias.krause@secunet.com>
Use the common helper function crypto_authenc_extractkeys() for key
parsing. Also ensure the auth key won't overflow the hash_ctx buffer.
Cc: Jamie Iles <jamie@jamieiles.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Mathias Krause <mathias.krause@secunet.com>
---
Not tested as I've no such hardware, nor the needed cross compiler!
drivers/crypto/picoxcell_crypto.c | 32 ++++++++------------------------
1 files changed, 8 insertions(+), 24 deletions(-)
diff --git a/drivers/crypto/picoxcell_crypto.c b/drivers/crypto/picoxcell_crypto.c
index 888f7f4..a6175ba 100644
--- a/drivers/crypto/picoxcell_crypto.c
+++ b/drivers/crypto/picoxcell_crypto.c
@@ -495,45 +495,29 @@ static int spacc_aead_setkey(struct crypto_aead *tfm, const u8 *key,
{
struct spacc_aead_ctx *ctx = crypto_aead_ctx(tfm);
struct spacc_alg *alg = to_spacc_alg(tfm->base.__crt_alg);
- struct rtattr *rta = (void *)key;
- struct crypto_authenc_key_param *param;
- unsigned int authkeylen, enckeylen;
+ struct crypto_authenc_keys keys;
int err = -EINVAL;
- if (!RTA_OK(rta, keylen))
+ if (crypto_authenc_extractkeys(&keys, key, keylen) != 0)
goto badkey;
- if (rta->rta_type != CRYPTO_AUTHENC_KEYA_PARAM)
+ if (keys.enckeylen > AES_MAX_KEY_SIZE)
goto badkey;
- if (RTA_PAYLOAD(rta) < sizeof(*param))
- goto badkey;
-
- param = RTA_DATA(rta);
- enckeylen = be32_to_cpu(param->enckeylen);
-
- key += RTA_ALIGN(rta->rta_len);
- keylen -= RTA_ALIGN(rta->rta_len);
-
- if (keylen < enckeylen)
- goto badkey;
-
- authkeylen = keylen - enckeylen;
-
- if (enckeylen > AES_MAX_KEY_SIZE)
+ if (keys.authkeylen > sizeof(ctx->hash_ctx))
goto badkey;
if ((alg->ctrl_default & SPACC_CRYPTO_ALG_MASK) ==
SPA_CTRL_CIPH_ALG_AES)
- err = spacc_aead_aes_setkey(tfm, key + authkeylen, enckeylen);
+ err = spacc_aead_aes_setkey(tfm, keys.enckey, keys.enckeylen);
else
- err = spacc_aead_des_setkey(tfm, key + authkeylen, enckeylen);
+ err = spacc_aead_des_setkey(tfm, keys.enckey, keys.enckeylen);
if (err)
goto badkey;
- memcpy(ctx->hash_ctx, key, authkeylen);
- ctx->hash_key_len = authkeylen;
+ memcpy(ctx->hash_ctx, keys.authkey, keys.authkeylen);
+ ctx->hash_key_len = keys.authkeylen;
return 0;
--
1.7.2.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox