> Oh my, if you are right with your first guess, this is a bad DRNG design.
>
> Just out of curiousity: what happens if a caller invokes the seed function
> twice or more times (each time with the sufficient amount of bits)? What is
> your guess here?
Should the second seed use the random data gen
Am Sonntag, 26. März 2017, 20:00:12 CEST schrieb Krzysztof Kozlowski:
Hi Krzysztof,
> > Would it make sense to add another outer loop here to allow all of slen to
> > be injected into the DRNG? Note, in some cases, a user wants to add more
> > seed into the DRNG than the actual seed size. In this
On 26 March 2017 at 20:50, Nicolas Pitre wrote:
> On Sun, 26 Mar 2017, Ard Biesheuvel wrote:
>
>> [...]
>> +static const u32 rco_tab[10] = { 1, 2, 4, 8, 16, 32, 64, 128, 27, 54 };
>
> You could consider using u8 for this table. This is a tiny space saving
> and normally it shouldn't make the runti
On Sun, 26 Mar 2017, Ard Biesheuvel wrote:
> The generic AES driver uses 16 lookup tables of 1 KB each, and has
> encryption and decryption routines that are fully unrolled. Given how
> the dependencies between this code and other drivers are declared in
> Kconfig files, this code is always pulled
On Sun, 26 Mar 2017, Ard Biesheuvel wrote:
> [...]
> +static const u32 rco_tab[10] = { 1, 2, 4, 8, 16, 32, 64, 128, 27, 54 };
You could consider using u8 for this table. This is a tiny space saving
and normally it shouldn't make the runtime any slower on most
architectures.
Nicolas
Both the original generic AES code and the new fixed-time AES driver
contain C implementations of crypto_aes_expand_key() which are
functionally equivalent to each other. However, the former version
pulls in crypto/aes_generic.o in its entirety, consisting of 16 KB
of lookup tables and fully unroll
Many drivers have a soft dependency on the availability of any crypto
driver that implements the "aes" cipher. To separate this notion from
the link time dependency on the tables or routines in the generic AES
driver, introduce a new Kconfig symbol CRYPTO_NEED_AES and use it to
replace any occurren
Call crypto_aes_expand_key() rather than crypto_aes_set_key() so
that we can move to another implementation of it in a subsequent
patch.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/aes-glue.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/cryp
The generic AES driver uses 16 lookup tables of 1 KB each, and has
encryption and decryption routines that are fully unrolled. Given how
the dependencies between this code and other drivers are declared in
Kconfig files, this code is always pulled into the core kernel, even
if it is usually superse
In preparation of fine tuning the dependency relations between the
accelerated AES drivers and the core support code, let's remove the
dependency declarations that are false. None of these modules have
link time dependencies on the generic AES code, nor do they declare
any AES algos with CRYPTO_ALG
The crypto API does not allow setkey() to be used in interrupt context,
and so the fallback to crypto_aes_expand_key() is dead code which can
be eliminated. This removes a dependency on crypto_aes_expand_key()
which will be fulfilled by another driver after a subsequent patch.
Signed-off-by: Ard B
Allow other AES drivers than crypto/aes_generic.o to fulfil soft
dependencies on AES. This allows CRYPTO_AES to be disabled if no
hard dependencies on it are enabled.
Signed-off-by: Ard Biesheuvel
---
arch/arm/crypto/Kconfig | 1 +
arch/arm64/crypto/Kconfig | 1 +
crypto/Kconfig| 9
Various accelerated scalar AES drivers reuse the lookup tables and
key expansion routines in crypto/aes_generic.o, but not the actual
encryption/decryption routines themselves. So split them off into
a separate module with its own Kconfig symbol CRYPTO_AES_CORE.
Signed-off-by: Ard Biesheuvel
---
On Sun, Mar 26, 2017 at 07:05:48PM +0200, Stephan Müller wrote:
> Am Sonntag, 26. März 2017, 18:46:02 CEST schrieb PrasannaKumar Muralidharan:
>
> HiKrzysztof,
>
> > >> > + if (slen < EXYNOS_RNG_SEED_SIZE) {
> > >> > + dev_warn(rng->dev, "Seed too short (only %u bytes)\n",
On Sun, Mar 26, 2017 at 07:11:28PM +0200, Stephan Müller wrote:
> Am Samstag, 25. März 2017, 17:26:52 CEST schrieb Krzysztof Kozlowski:
> > +static int exynos_rng_set_seed(struct exynos_rng_dev *rng,
> > + const u8 *seed, unsigned int slen)
> > +{
> > + u32 val;
> > + i
Am Samstag, 25. März 2017, 17:26:52 CEST schrieb Krzysztof Kozlowski:
Hi Krzysztof,
> +static int exynos_rng_set_seed(struct exynos_rng_dev *rng,
> +const u8 *seed, unsigned int slen)
> +{
> + u32 val;
> + int i;
> +
> + dev_dbg(rng->dev, "Seeding with %u b
Am Sonntag, 26. März 2017, 18:46:02 CEST schrieb PrasannaKumar Muralidharan:
Hi Krzysztof,
> >> > + if (slen < EXYNOS_RNG_SEED_SIZE) {
> >> > + dev_warn(rng->dev, "Seed too short (only %u bytes)\n",
> >> > slen); + return -EINVAL;
> >> > + }
> >>
> >>
On 26 March 2017 at 21:31, Krzysztof Kozlowski wrote:
> On Sun, Mar 26, 2017 at 08:50:42PM +0530, PrasannaKumar Muralidharan wrote:
>> .Have some minor comments. Please feel free to correct if I am wrong.
>>
>> On 25 March 2017 at 21:56, Krzysztof Kozlowski wrote:
>> > diff --git a/drivers/crypto
Am Sonntag, 26. März 2017, 18:01:26 CEST schrieb Krzysztof Kozlowski:
Hi Krzysztof,
> > > + if (slen < EXYNOS_RNG_SEED_SIZE) {
> > > + dev_warn(rng->dev, "Seed too short (only %u bytes)\n",
> > > slen); + return -EINVAL;
> > > + }
> >
> > Will it be helpfu
On Sun, Mar 26, 2017 at 08:50:42PM +0530, PrasannaKumar Muralidharan wrote:
> .Have some minor comments. Please feel free to correct if I am wrong.
>
> On 25 March 2017 at 21:56, Krzysztof Kozlowski wrote:
> > Replace existing hw_ranndom/exynos-rng driver with a new, reworked one.
> > This is a d
.Have some minor comments. Please feel free to correct if I am wrong.
On 25 March 2017 at 21:56, Krzysztof Kozlowski wrote:
> Replace existing hw_ranndom/exynos-rng driver with a new, reworked one.
> This is a driver for pseudo random number generator block which on
> Exynos4 chipsets must be see
I've got a few other races in padata, I think, that I'm working on
fixing. If these pan out, I'll submit them exclusively to -crypto
instead of -netdev, to avoid this confusion next time. Of course, if
I'm able to fix these, then I'll probably be bald from pulling my hair
out during this insane deb
22 matches
Mail list logo
