On 05.02.2013 23:58:30, +0100, Kyle McMartin wrote:
Hi Kyle,
> fips mode needs to prevent unsigned modules from registering crypto
> algorithms, and currently panics if an unsigned module is attempted to
> be loaded. Instead, forbid (by returning -EINVAL) registering a crypto
> alg or template i
On 06.02.2013 17:15:57, +0100, Kyle McMartin wrote:
Hi Kyle,
> On Wed, Feb 06, 2013 at 09:02:46AM +0100, Stephan Mueller wrote:
>> On 05.02.2013 23:58:30, +0100, Kyle McMartin wrote:
>>
>> Hi Kyle,
>>
>
> Thanks for the review, Stephan.
>
>> Just re
Hi crypto hackers,
[1] patch at http://www.chronox.de/jitterentropy-0.1.tar.gz
The Linux kernel RNG which we all use via /dev/random or /dev/urandom
received a lot of merits over the long years it exists. In particular
it was subject to countless researches and assessments and was determined
to d
On 09.02.2013 19:06:29, +0100, Theodore Ts'o wrote:
Hi Ted,
thank you for the review.
> On Fri, Feb 08, 2013 at 11:04:54PM +0100, Stephan Mueller wrote:
>> * an array of statistical test suites pass the output of the entropy
>> collector
>> (again, the output is not
On 10.02.2013 02:57:51, +0100, Jeff Epler wrote:
Hi Jeff,
> On Sat, Feb 09, 2013 at 01:06:29PM -0500, Theodore Ts'o wrote:
>> For that reasons, what I would suggest doing first is generate a
>> series of outputs of jitterentropy_get_nstime() followed by
>> schedule(). Look and see if there is an
On 10.02.2013 19:50:02, +0100, Theodore Ts'o wrote:
Hi Ted,
> On Sun, Feb 10, 2013 at 01:46:18PM +0100, Stephan Mueller wrote:
>> However, the CPU has timing jitter in the execution of instruction. And
>> I try to harvest that jitter. The good thing is that this jitter is
&
On 24.01.2013 15:59:07, +0100, Kyle McMartin wrote:
Hi Kyle,
> On Wed, Jan 23, 2013 at 04:18:32PM +0100, Stephan Mueller wrote:
>> 3. in the cipher initialization code of the crypto API (i.e. the one
>> behind crypto_register_alg()), you check the signature check flag --
>>
On 24.01.2013 20:06:10, +0100, Kyle McMartin wrote:
Hi Kyle,
> After thinking about it a while, this seems like the best way to solve
> the problem, although it does still kind of offend my delicate
> sensibilities...
>
> Doing this check in the crypto layer seems kind of like a layering
> viola
On 25.01.2013 04:20:07, +0100, Matthew Garrett wrote:
Hi Matthew,
> On Fri, Jan 25, 2013 at 12:14:54AM +, David Howells wrote:
>
>> You can't rely on someone trying to sneak a dodgy crypto module in to set the
>> flag when they build it. The detection thus needs to be done in the kernel
>>
far too polite. This patch was horrible, partial and ugly.
Well, in another email I suggested you may want to think about some
marker that the code of the module would contain, similar to the GPL
flag for the module (whose absence sets the tainted flag).
>
> Stephan Mueller wrote:
>> FIPS
.
Signed-off-by: Stephan Mueller
--- Kconfig.orig2013-01-25 13:42:54.649705380 +0100
+++ Kconfig 2013-01-25 13:43:16.737705712 +0100
@@ -22,11 +22,11 @@
comment "Crypto core or helper"
config CRYPTO_FIPS
- bool "FIPS 200 compliance"
+ bool &q
On 21.02.2013 15:07:12, +0100, Phil Carmody wrote:
Hi Phil,
> Apologies if this is misthreaded, I had to hand-craft the headers.
>
>> The patch offers an entropy generator based on CPU timing jitter. The
>> entropy collector has the following properties:
>>
>> * it does not maintain any state an
Am Freitag, 13. September 2013, 14:59:31 schrieb Theodore Ts'o:
Hi Theodore,
>On Fri, Sep 13, 2013 at 07:36:20AM +0200, Stephan Mueller wrote:
>
>However, if you are worried about a malicious entropy source, things
>are a little bit different. Suppose RDRAND == AES(i++, NSA_KEY
call to get_cycles on an x86_64 system to verify
that clocksource delivers data.
Ciao
Stephan
Signed-off-by: Stephan Mueller
---
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 0d91fe5..d2d14a1 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -255,6 +255,7
Am Dienstag, 10. September 2013, 11:04:19 schrieb Theodore Ts'o:
Hi Theodore,
>On Tue, Sep 10, 2013 at 01:31:41PM +0200, Stephan Mueller wrote:
>> Hi,
>>
>> /dev/random uses the get_cycles() function to obtain entropy in
>> addition to jiffies and th
Am Dienstag, 10. September 2013, 14:25:24 schrieb Theodore Ts'o:
Hi Theodore,
>
>Also note that the clocksource is not necessarily be the best choice;
>it may not be the most fine grained sampling that we have available
>(that is certainly be true for MIPS). So doing something hacky
>doesn't abs
Am Dienstag, 10. September 2013, 12:38:56 schrieb John Stultz:
Hi John,
>On Tue, Sep 10, 2013 at 4:31 AM, Stephan Mueller
wrote:
>> Hi,
>>
>> /dev/random uses the get_cycles() function to obtain entropy in
>> addition to jiffies and the event value of hardware e
Am Dienstag, 10. September 2013, 17:14:54 schrieb Theodore Ts'o:
Hi Theodore,
>On Tue, Sep 10, 2013 at 10:48:00PM +0200, Geert Uytterhoeven wrote:
>> So the first importance for random_get_fast_cycles() is that it needs
>> to be fast. What's most important next: number of bits or
>> high-frequenc
Am Donnerstag, 12. September 2013, 13:59:04 schrieb Geert Uytterhoeven:
Hi Geert,
>On Wed, Sep 11, 2013 at 8:49 AM, Stephan Mueller
wrote:
>> __u64 tmp = random_get_fast_cycles() - random_get_fast_cycles();
>> if(0 == tmp)
>>
>> return fail;
>>
>
Am Donnerstag, 12. September 2013, 14:15:35 schrieb Geert Uytterhoeven:
Hi Geert,
>On Thu, Sep 12, 2013 at 2:08 PM, Stephan Mueller
wrote:
>>>BTW, I prefer a different name than "random_get_fast_cycles()", as
>>>it's better to have something that returns di
Am Donnerstag, 12. September 2013, 14:47:23 schrieb Geert Uytterhoeven:
Hi Geert,
>On Thu, Sep 12, 2013 at 2:35 PM, Stephan Mueller
wrote:
>>>On Thu, Sep 12, 2013 at 2:08 PM, Stephan Mueller
>>>
>>>
>> wrote:
>>>>>BTW, I prefer a different
Am Donnerstag, 12. September 2013, 17:31:48 schrieb Jörn Engel:
Hi Jörn,
>On Tue, 10 September 2013 15:08:12 -0700, John Stultz wrote:
>> Though
>> I probably should be hesitant with my suggestions, as I'm not well
>> versed in RNG theory.
>
>The basic principle of Ted's RNG is very simple and qu
Am Sonntag, 22. September 2013, 16:38:53 schrieb Theodore Ts'o:
Hi Theodore,
>Allow architectures which have a disabled get_cycles() function to
>provide a random_get_entropy() function which provides a fine-grained,
>rapidly changing counter that can be used by the /dev/random driver.
Are there
nks
Stephan
Signed-off-by: Stephan Mueller
---
diff -purN linux-3.6/drivers/char/random.c linux-3.6-sm/drivers/char/random.c
--- linux-3.6/drivers/char/random.c 2012-10-01 01:47:46.0 +0200
+++ linux-3.6-sm/drivers/char/random.c 2012-12-11 11:51:58.997172447 +0100
@@ -404,11 +404
On 08.11.2012 12:47:08, +0100, Theodore Ts'o wrote:
Hi Theodore,
> On Thu, Nov 08, 2012 at 01:32:38AM +0100, Stephan Mueller wrote:
>>
>> However, due to the fact that jiffies provides very few entropy, the
>> event value provides (almost) none, the majority of
On 14.11.2012 18:52:53, +0100, H. Peter Anvin wrote:
Hi Peter,
> On 11/14/2012 08:15 AM, Stephan Mueller wrote:
>>
>> I agree with the argument of correlation.
>>
>> So, if the reduction of values with a known lack of entropy is of
>> interest, why not cha
Hi,
the function add_timer_randomness currently defines:
struct {
...
unsigned cycles;
...
} sample;
Cycles used to be of type cycles_t. The inline get_cycles that fills
cycles is still of type cycles_t.
Unsigned is 32 bit whereas get_cycles is 64 bit. This means
Hi Sandy, Ted,
(this is a reply to [3])
I prepared a new release of the CPU Jitter RNG available at [1]. The
core of the RNG remains unchanged. However, there are the following
changes:
- addition of a patch to integrate the RNG into /dev/random as explained
in appendix B.3 of [2], although t
Am Sonntag, 18. August 2013, 20:05:52 schrieb Stephan Mueller:
Hi Ted, Sandy,
For FIPS 140-2, there is currently a draft of an Implementation Guidance
discussed covering the requirements of seed sources for deterministic
random number generators. The standard seed source when having no
Am Dienstag, 21. Mai 2013, 17:39:49 schrieb Sandy Harris:
Hi Sandy, Ted,
I prepared a new release of the CPU Jitter RNG available at [1]. The
core of the RNG remains unchanged. However, there are the following
changes:
- addition of a patch to integrate the RNG into /dev/random as explained
i
the
web site as well.
Note: for the kernel crypto API, please read the provided Kconfig file
for the provided switches and which of them are recommended in regular
operation. These switches must currently be set manually in the
Makefile.
Ciao
Stephan
Signed-off-by: Stephan Mueller
--
To
documentation are available at the
web site as well.
Note: for the kernel crypto API, please read the provided Kconfig file
for the switches and which of them are recommended in regular
operation. These switches must currently be set manually in the
Makefile.
Ciao
Stephan
Signed-off-by: Stephan Mueller
On Tue, 21 May 2013 12:09:02 -0400
Sandy Harris wrote:
Hi Sandy,
> I very much like the basic notion here. The existing random(4) driver
> may not get enough entropy in a VM or on a device like a Linux router
> and I think work such as yours or HAVEGE (
> http://www.irisa.fr/caps/projects/hipsor
On Tue, 21 May 2013 17:39:49 -0400
Sandy Harris wrote:
Hi Sandy,
> On Tue, May 21, 2013 at 3:01 PM, Theodore Ts'o wrote:
>
> > I continue to be suspicious about claims that userspace timing
> > measurements are measuring anything other than OS behaviour.
>
> Yes, but they do seem to contain s
On Wed, 22 May 2013 13:40:04 -0400
Sandy Harris wrote:
Hi Sandy,
> Stephan Mueller wrote:
>
> > Ted is right that the non-deterministic behavior is caused by the OS
> > due to its complexity. ...
>
> >> > For VM's, it means we should definitel
y-base.c, jitterentropy.h and jitterentropy-base-kernel.h
from the tarball available at http://www.chronox.de.
This patch would only use the CPU Jitter RNG if there is no more
entropy in the entropy pool. Thus, the CPU Jitter RNG is only used as a
fallback.
The patch is tested with 3.9.
Si
which need to deny module loading such as secure boot already set
>> sig_enforce, so there's no issue here.
>>
>> Reported-by: Jan Stancek
>> Signed-off-by: Kyle McMartin
>
> Fine by me, but adding Stephan Mueller for his input.
FIPS requires the module (in our case
27;s some
> indication that the crypto stuff is compromised, the box should be shut down
> immediately.
>
> I've added Stephan Mueller to see if he can illuminate further.
>
> David
>
The requirement for a FIPS 140-2 module is to disable the entire module
if any comp
On 11.12.2012 13:33:04, +0100, Stephan Mueller wrote:
Hi,
I just noticed a misuse of a variable in my initial patch
> + if (r->limit == 2 && r->entropy_count >= r->poolinfo->poolwords)
Instead of r->entropy_count, the code should use entropy_count.
Please se
On 13.12.2012 01:43:21, +0100, Andrew Morton
wrote:
Hi Andrew,
> On Tue, 11 Dec 2012 13:33:04 +0100
> Stephan Mueller wrote:
>
>> Some time ago, I noticed the fact that for every newly
>> executed process, the function create_elf_tables requests 16 bytes of
>> rando
On 13.12.2012 08:44:36, +0100, Stephan Mueller wrote:
Hi Andrew,
> On 13.12.2012 01:43:21, +0100, Andrew Morton
> wrote:
>
> Hi Andrew,
>> On Tue, 11 Dec 2012 13:33:04 +0100
>> Stephan Mueller wrote:
>>
>>> Some time ago, I noticed the fact that fo
Am Sonntag, 19. Juni 2016, 21:36:14 schrieb Pavel Machek:
Hi Pavel,
> On Sun 2016-06-19 17:58:41, Stephan Mueller wrote:
> > Hi Herbert, Ted,
> >
> > The following patch set provides a different approach to /dev/random which
> > I call Linux Random Number Generato
Am Montag, 20. Juni 2016, 11:28:38 schrieb Theodore Ts'o:
Hi Theodore,
> On Mon, Jun 20, 2016 at 07:51:59AM +0200, Stephan Mueller wrote:
> > - Correlation of noise sources: as outlined in [1] chapter 1, the three
> > noise sources of the legacy /dev/random implem
Am Montag, 20. Juni 2016, 11:01:47 schrieb Theodore Ts'o:
Hi Theodore,
>
> So simply doing chacha20 encryption in a tight loop in the kernel
> might not be a good proxy for what would actually happen in real life
> when someone calls getrandom(2). (Another good question to ask is
> when someone
Am Montag, 20. Juni 2016, 13:07:32 schrieb Austin S. Hemmelgarn:
Hi Austin,
> On 2016-06-18 12:31, Stephan Mueller wrote:
> > Am Samstag, 18. Juni 2016, 10:44:08 schrieb Theodore Ts'o:
> >
> > Hi Theodore,
> >
> >> At the end of the day, with these devi
Am Montag, 20. Juni 2016, 14:44:03 schrieb George Spelvin:
Hi George,
> > With that being said, wouldn't it make sense to:
> >
> > - Get rid of the entropy heuristic entirely and just assume a fixed value
> > of entropy for a given event?
>
> What does that gain you? You can always impose an u
Am Dienstag, 21. Juni 2016, 01:12:55 schrieb Theodore Ts'o:
Hi Theodore,
> On Mon, Jun 20, 2016 at 09:00:49PM +0200, Stephan Mueller wrote:
> > The time stamp maintenance is the exact cause for the correlation: one HID
> > event triggers:
> >
> > - add_interrupt
Am Freitag, 17. Juni 2016, 17:59:41 schrieb Arnd Bergmann:
Hi Arnd,
> The jent_get_nstime() function uses __getnstimeofday() to get
> something similar to a 64-bit nanosecond counter. As we want
> to get rid of struct timespec to fix the y2038 overflow,
> this patch changes the code to use __getn
Am Dienstag, 21. Juni 2016, 09:12:07 schrieb Nikos Mavrogiannopoulos:
Hi Nikos,
> On Mon, Jun 20, 2016 at 5:43 PM, Stephan Mueller
wrote:
> >> Personally, I don't really use /dev/random, nor would I recommend it
> >> for most application programmers. At this point, g
Am Dienstag, 21. Juni 2016, 10:32:23 schrieb Arnd Bergmann:
Hi Arnd,
> On Tuesday, June 21, 2016 8:20:10 AM CEST Stephan Mueller wrote:
> > Am Freitag, 17. Juni 2016, 17:59:41 schrieb Arnd Bergmann:
> >
> > Hi Arnd,
> >
> > > The jent_get_nstime() fun
Am Dienstag, 21. Juni 2016, 09:05:55 schrieb Austin S. Hemmelgarn:
Hi Austin,
> On 2016-06-20 14:32, Stephan Mueller wrote:
> > Am Montag, 20. Juni 2016, 13:07:32 schrieb Austin S. Hemmelgarn:
> >
> > Hi Austin,
> >
> >> On 2016-06-18 12:31, Stephan Muell
Am Dienstag, 21. Juni 2016, 12:03:56 schrieb Austin S. Hemmelgarn:
Hi Austin,
> On 2016-06-21 03:32, Stephan Mueller wrote:
> > Am Dienstag, 21. Juni 2016, 09:12:07 schrieb Nikos Mavrogiannopoulos:
> >
> > Hi Nikos,
> >
> >> On Mon, Jun 20, 2016 at 5:43
Am Dienstag, 21. Juni 2016, 09:22:31 schrieb John Stultz:
Hi John,
> On Tue, Jun 21, 2016 at 1:32 AM, Arnd Bergmann wrote:
> > On Tuesday, June 21, 2016 8:20:10 AM CEST Stephan Mueller wrote:
> >> Am Freitag, 17. Juni 2016, 17:59:41 schrieb Arnd Bergmann:
> >
Am Dienstag, 21. Juni 2016, 09:47:23 schrieb John Stultz:
Hi John,
> On Tue, Jun 21, 2016 at 9:34 AM, Stephan Mueller
wrote:
> > Am Dienstag, 21. Juni 2016, 09:22:31 schrieb John Stultz:
> >
> > Hi John,
> >
> >> On Tue, Jun 21, 2016 at 1:32 AM, Arnd Berg
Am Dienstag, 21. Juni 2016, 10:12:24 schrieb John Stultz:
Hi John,
>
> So this is definitely more clear then what was described earlier, and
> worries me because on many x86 machines (though fewer I guess these
> days then in the past) the clocksource will often not be the TSC (and
> have lower r
Am Dienstag, 21. Juni 2016, 13:18:33 schrieb Austin S. Hemmelgarn:
Hi Austin,
> > You have to trust the host for anything, not just for the entropy in
> > timings. This is completely invalid argument unless you can present a
> > method that one guest can manipulate timings in other guest in such
Am Dienstag, 21. Juni 2016, 18:51:32 schrieb Stephan Mueller:
Hi,
> > So.. again, I'd avoid using the "fast" accessor unless there is a
> > clear need or obvious benefit. Which should be documented.
>
> So, you suggest ktime_get_raw_ns? If yes, let me test
Am Dienstag, 21. Juni 2016, 13:54:13 schrieb Austin S. Hemmelgarn:
Hi Austin,
> On 2016-06-21 13:23, Stephan Mueller wrote:
> > Am Dienstag, 21. Juni 2016, 13:18:33 schrieb Austin S. Hemmelgarn:
> >
> > Hi Austin,
> >
> >>> You have to trust the host fo
Am Dienstag, 21. Juni 2016, 13:51:15 schrieb Austin S. Hemmelgarn:
Hi Austin,
>
> >> 2. Quite a few systems have a rather distressingly low lower bound and
> >> still get accepted by your algorithm (a number of the S/390 systems, and
> >> a handful of the AMD processors in particular).
> >
> >
execution time of the heart of the
RNG:
jent_get_nstime(&time);
jent_memaccess(ec, min);
jent_fold_time(NULL, time, &folded, min);
jent_get_nstime(&time2);
return ((time2 - time));
Signed-off-by: Stephan Mueller
---
crypto/jitterentropy-
Am Dienstag, 21. Juni 2016, 14:22:48 schrieb Austin S. Hemmelgarn:
Hi Austin,
> On 2016-06-21 12:28, Stephan Mueller wrote:
> > Am Dienstag, 21. Juni 2016, 12:03:56 schrieb Austin S. Hemmelgarn:
> >
> > Hi Austin,
> >
> >> On 2016-06-21 03:32, Stephan Muelle
Am Dienstag, 21. Juni 2016, 11:11:42 schrieb John Stultz:
Hi John,
> I don't see in the above an explanation of *why* you're using
> ktime_get_raw_ns() instead of ktime_get_ns().
Could you help me understand what the difference is or point me to some
documentation? I understood that we only tal
Am Dienstag, 21. Juni 2016, 15:31:07 schrieb Austin S. Hemmelgarn:
Hi Austin,
> > Little data, interesting statement for results on 200+ systems including
> > all major CPU arches all showing information leading in the same
> > directions.
> Let me try rephrasing this to make it a bit clearer:
>
Am Dienstag, 27. September 2016, 16:44:16 CEST schrieb Kalle Valo:
Hi Kalle,
> Stephan Mueller wrote:
> > The ATH9K driver implements an RNG which is completely bypassing the
> > standard Linux HW generator logic.
> >
> > The RNG may or may not deliver entropy. C
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
---
drivers/net/wireless/ath/ath9k/rng.c | 3 +--
Am Samstag, 6. August 2016, 19:45:51 CEST schrieb Jason Cooper:
Hi Jason,
> 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
. 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.
Reviewed-by: Jason Cooper
Signed-off-by: Stephan
pin, please help and offer another solution.
>
> --
> Miaoqing
>
> -Original Message-
> From: Stephan Mueller [mailto:smuel...@chronox.de]
> Sent: Sunday, August 07, 2016 5:36 PM
> To: Ted Tso
> Cc: herb...@gondor.apana.org.au; linux-kernel@vger.kernel.org
Am Mittwoch, 16. August 2017, 13:19:48 CEST schrieb Ryder Lee:
Hi Ryder,
> Currently, empty messages are not supported in GCM mode, hence add
> a check to prevent producing incorrect results.
In case the caller would provide empty messages, would there be just wrong
data or a real problem? Note
Am Dienstag, 15. August 2017, 17:12:24 CEST schrieb Theodore Ts'o:
Hi Theodore,
>
> Stephan, if you have any comments on the proposal made by David
> Fontaine and Olivier Vivolo, I'd appreciate hearing them!
I think I have some news: The magma code I used for GF(2^32) testing was not
correct.
Am Dienstag, 15. August 2017, 17:12:24 CEST schrieb Theodore Ts'o:
Hi Theodore, Jeffrey,
>
> Stephan, if you have any comments on the proposal made by David
> Fontaine and Olivier Vivolo, I'd appreciate hearing them!
(from Jefferey):
> This may be helpful, too. I use it to look up minimal weigh
Am Dienstag, 16. Juni 2015, 11:46:46 schrieb Boris Brezillon:
Hi Herbert,
>The crypto drivers are supposed to update the IV passed to the crypto
>request before calling the completion callback.
>Test for the IV value before considering the test as successful.
May I ask whether there is anything
updated SGL-based akcipher API
* allow mix-n-match of sendmsg and vmsplice calls
[1] http://www.chronox.de/libkcapi.html
Stephan Mueller (5):
MPI: fix off by one in mpi_read_raw_from_sgl
crypto: AF_ALG -- add sign/verify API
crypto: AF_ALG -- add setpubkey setsockopt call
crypto: AF_ALG
Add the Makefile and Kconfig updates to allow algif_akcipher to be
compiled.
Signed-off-by: Stephan Mueller
---
crypto/Kconfig | 9 +
crypto/Makefile | 1 +
2 files changed, 10 insertions(+)
diff --git a/crypto/Kconfig b/crypto/Kconfig
index fc93444..aa5d3aa 100644
--- a/crypto
This patch adds the user space interface for asymmetric ciphers. The
interface allows the use of sendmsg as well as vmsplice to provide data.
Signed-off-by: Stephan Mueller
---
crypto/algif_akcipher.c | 542
1 file changed, 542 insertions
The patch fixes the analysis of the input data which contains an off
by one.
The issue is visible when the SGL contains one byte per SG entry.
The code for checking for zero bytes does not operate on the data byte.
Signed-off-by: Stephan Mueller
---
lib/mpi/mpicoder.c | 5 -
1 file changed
Add the flags for handling signature generation and signature
verification.
Also, the patch adds the interface for setting a public key.
Signed-off-by: Stephan Mueller
---
include/uapi/linux/if_alg.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/uapi/linux/if_alg.h b/include
For supporting asymmetric ciphers, user space must be able to set the
public key. The patch adds a new setsockopt call for setting the public
key.
Signed-off-by: Stephan Mueller
---
crypto/af_alg.c | 14 +++---
include/crypto/if_alg.h | 1 +
2 files changed, 12 insertions(+), 3
Am Montag, 19. Oktober 2015, 09:32:30 schrieb Herbert Xu:
Hi Herbert,
> On Sun, Oct 18, 2015 at 12:44:00PM +0200, Stephan Mueller wrote:
> > Hi,
> >
> > This patch set adds the AF_ALG user space API to externalize the
> > asymmetric cipher API recently add
Am Dienstag, 20. Oktober 2015, 09:34:01 schrieb LABBE Corentin:
Hi LABBE,
>Fix numerous spelling error in include/crypto/akcipher.h
>
>Signed-off-by: LABBE Corentin
>---
> include/crypto/akcipher.h | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
>diff --git a/include/cryp
Am Dienstag, 27. Oktober 2015, 13:54:30 schrieb Marcel Holtmann:
Hi Marcel,
>Hi Stephan,
>
>> This patch set adds the AF_ALG user space API to externalize the
>> asymmetric cipher API recently added to the kernel crypto API.
>>
>> The patch set is tested with the user space library of libkcapi [
Am Dienstag, 27. Oktober 2015, 18:19:01 schrieb David Woodhouse:
Hi David,
>
>That's largely orthogonal to the point Marcel was making.
>
>The point is that akcipher is limited to using keys for which we have
>the private key material available directly in software. We cannot
Agreed.
>expose tha
Am Donnerstag, 11. Januar 2018, 10:17:10 CET schrieb Gilad Ben-Yossef:
Hi Gilad,
> + // verify weak keys
> + if (ctx_p->flow_mode == S_DIN_to_DES) {
> + if (!des_ekey(tmp, key) &&
> + (crypto_tfm_get_flags(tfm) & CRYPTO_TFM_REQ_WEAK_KEY)) {
> +
Am Donnerstag, 11. Januar 2018, 20:56:56 CET schrieb Corentin Labbe:
Hi Corentin,
> This patch implement a generic way to get statistics about all crypto
> usages.
>
> Signed-off-by: Corentin Labbe
> ---
> crypto/Kconfig | 11
> crypto/ablkcipher.c | 9 ++
Am Freitag, 12. Januar 2018, 10:07:30 CET schrieb LABBE Corentin:
Hi LABBE,
>
> > > diff --git a/include/uapi/linux/cryptouser.h
> > > b/include/uapi/linux/cryptouser.h index 19bf0ca6d635..15e51ccb3679
> > > 100644
> > > --- a/include/uapi/linux/cryptouser.h
> > > +++ b/include/uapi/linux/crypto
e enough for use
> in real world applications.
>
> Signed-off-by: Björn Esser
Considering NR_FILE defining the default maximum number of file descriptors,
at max 335 MB of RAM (32 bit) or 670 MB (64 bit) could be allocated which I
would assume to be ok in current systems.
Reviewed-by: Stephan Mueller
Ciao
Stephan
Am Mittwoch, 17. Januar 2018, 20:22:13 CET schrieb Christoph Hellwig:
Hi Christoph,
> On Sun, Jan 14, 2018 at 09:01:00AM +0100, Stephan Müller wrote:
> > The syscall io_submit sends data to the kernel and invokes the respective
> > handler function in the kernel such as the recvmsg handler. What
Am Dienstag, 27. Februar 2018, 17:37:45 CET schrieb Stephan Mueller:
Hi Jiri, Dimity, Henrik,
> Am Sonntag, 21. Januar 2018, 23:06:55 CET schrieb Stephan Müller:
>
> Hi Jiri, Dimity, Henrik,
>
> > Hi,
> >
> > Changes v3:
> > * port to 4.15-rc8
> >
Am Mittwoch, 11. April 2018, 14:29:45 CEST schrieb Dmitry Vyukov:
Hi Dmitry,
>
> What do you mean by description of the fault?
> It's kernel standard FAULT_INJECTION facility, it injects faults
> mainly into kmalloc/slab_alloc (also in a bunch of other things, but
> in this case this seems to be
Am Freitag, 13. April 2018, 03:30:42 CEST schrieb Theodore Ts'o:
Hi Theodore,
> The crng_init variable has three states:
>
> 0: The CRNG is not initialized at all
> 1: The CRNG has a small amount of entropy, hopefully good enough for
>early-boot, non-cryptographical use cases
> 2: The CRNG i
Am Freitag, 13. April 2018, 14:53:13 CEST schrieb Theodore Y. Ts'o:
Hi Theodore,
>
> This was always the original design intent, but I screwed up and no
> one noticed until Jann reached out to be and said, "Hey this
> doesn't seem to make much sense".
I disagree, but I guess you would have e
Am Montag, 9. April 2018, 00:46:03 CEST schrieb Theodore Y. Ts'o:
Hi Theodore,
>
> So the syzbot will run while the patch goes through the normal e-mail
> review process, which is kind of neat. :-)
Thank you very much for the hint. That is a neat feature indeed.
As I came late to the party and
Am Montag, 9. April 2018, 09:51:13 CEST schrieb Dmitry Vyukov:
Hi Dmitry,
> You can ask syzbot to test by replying to its report email with a test
> command, see:
> https://github.com/google/syzkaller/blob/master/docs/syzbot.md#communication
> -with-syzbot
>
> Note that all testing of KMSAN bugs
Am Dienstag, 10. April 2018, 17:23:46 CEST schrieb Dmitry Vyukov:
Hi Dmitry,
> Stephan,
>
> Do you have any hypothesis as to why this is not detected by KASAN and
> causes silent corruptions?
> We generally try to understand such cases and improve KASAN so that it
> catches such cases more relia
Am Mittwoch, 14. März 2018, 14:17:30 CET schrieb Salvatore Mesoraca:
Hi Salvatore,
> if (walk.nbytes) {
> - crypto_ctr_crypt_final(&walk, child);
> - err = blkcipher_walk_done(desc, &walk, 0);
> + err = crypto_ctr_crypt_final(&walk, child);
> +
Am Mittwoch, 14. März 2018, 14:46:29 CET schrieb Salvatore Mesoraca:
Hi Salvatore,
> 2018-03-14 14:31 GMT+01:00 Stephan Mueller :
> > Am Mittwoch, 14. März 2018, 14:17:30 CET schrieb Salvatore Mesoraca:
> >
> > Hi Salvatore,
> >
Am Donnerstag, 3. Januar 2019, 15:32:24 CET schrieb Lee, Chun-Yi:
Hi Chun,
> +int snapshot_image_verify_decrypt(void)
> +{
> + int ret, i;
> +
> + if (!h_buf) {
> + ret = -ENOMEM;
> + goto error;
> + }
> +
> + ret = snapshot_key_init();
> + if (ret)
> +
Am Donnerstag, 3. Januar 2019, 15:32:23 CET schrieb Lee, Chun-Yi:
Hi Chun,
> This patch adds a snapshot keys handler for using the key retention
> service api to create keys for snapshot image encryption and
> authentication.
>
> This handler uses TPM trusted key as the snapshot master key, and
Am Donnerstag, 3. Januar 2019, 15:32:25 CET schrieb Lee, Chun-Yi:
Hi Chun,
> To protect the secret in memory snapshot image, this patch adds the
> logic to encrypt snapshot pages by AES-CTR. Using AES-CTR is because
> it's simple, fast and parallelizable. But this patch didn't implement
> paralle
Am Sonntag, 6. Januar 2019, 09:01:27 CET schrieb Stephan Mueller:
Hi,
> > + memcpy(skey.key, ukp->data, ukp->datalen);
>
> Where would skey.key be destroyed again?
Now I see it - it is in patch 4. Please disregard my comment.
Ciao
Stephan
1 - 100 of 938 matches
Mail list logo
