Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)
Hello, On Fri, 2016-12-23 at 20:17 -0500, George Spelvin wrote: > Hannes Frederic Sowa wrote: > > On 24.12.2016 00:39, George Spelvin wrote: > > > We just finished discussing why 8 bytes isn't enough. If you only > > > feed back 8 bytes, an attacker who can do 2^64 computation can find it > > > (by guessing and computing forward to verify the guess) and recover the > > > previous state. You need to feed back at least as much output as your > > > security targete. For /dev/urandom's ChaCha20, that's 256 bits. > > I followed the discussion but it appeared to me that this has the > > additional constraint of time until the next reseeding event happenes, > > which is 300s (under the assumption that calls to get_random_int happen > > regularly, which I expect right now). After that the existing reseeding > > mechansim will ensure enough backtracking protection. The number of > > bytes can easily be increased here, given that reseeding was shown to be > > quite fast already and we produce enough output. But I am not sure if > > this is a bit overengineered in the end? > > I'm not following your description of how the time-based and call-based > mechanisms interact, but for any mix-back, you should either do enough > or none at all. (Also called "catastrophic reseeding".) We call extract_crng when we run out of batched entropy and reseed. How often we call down to extract_crng depends on how much entropy we extracted by calls to get_random_int/long, so the number of calls into those functions matter. In extract_crng we have a timer which reseeds every 300s the CPRNG and either uses completely new entropy from the CRNG or calls down into the CPRNG while also doing backtracing protection (which feeds chacha's block size / 2 back into chacha, if I read the code correctly, thus 1024 bits, which should be enough). > For example, two mix-backs of 64 bits gives you 65 bit security, not 128. > (Because each mixback can be guessed and verified separately.) Exactly, but the full reseed after running out of entropy is strong enough to not be defeated by your argumentation. Neither the reseed from the CRNG. > > Also agreed. Given your solution below to prandom_u32, I do think it > > might also work without the seqlock now. > > It's not technically a seqlock; in particular the reader doesn't > spin. But the write side, and general logic is so similar it's > a good mental model. > > Basically, assume a 64-byte buffer. The reader has gone through > 32 bytes of it, and has 32 left, and when he reads another 8 bytes, > has to distinguish three cases: > > 1) No update; we read the old bytes and there are now 32 - 24 bytes left. > 2) Update completed while we weren't looking. There are now new >bytes in the buffer, and we took 8 leaving 64 - 8 = 56. > 3) Update in progress at the time of the read. We don't know if we >are seeing old bytes or new bytes, so we have to assume the worst >and not proceeed unless 32 >= 8, but assume at the end there are >64 - 8 = 56 new bytes left. > > > I wouldn't have added a disable irqs, but given that I really like your > > proposal, I would take it in my todo branch and submit it when net-next > > window opens. > > If you want that, I have a pile of patches to prandom I really > should push upstream. Shall I refresh them and send them to you? I would like to have a look at them in the new year, certainly! I can also take care about the core prandom patches, but don't know if I have time to submit the others to the different subsystems. Maybe, if David would be okay with that, we can submit all patches through his tree, as he is also the dedicated maintainer for prandom. > [... patch descriptions ...] Thanks, Hannes -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/8] random: remove unused branch in hot code path
The variable ip is defined to be a __u64 which is always 8 bytes on any architecture. Thus, the check for sizeof(ip) > 4 will always be true. As the check happens in a hot code path, remove the branch. Signed-off-by: Stephan Mueller--- drivers/char/random.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index 5c26b1c..8d4d720 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -1136,8 +1136,7 @@ void add_interrupt_randomness(int irq, int irq_flags) fast_pool->pool[1] ^= now ^ c_high; ip = regs ? instruction_pointer(regs) : _RET_IP_; fast_pool->pool[2] ^= ip; - fast_pool->pool[3] ^= (sizeof(ip) > 4) ? ip >> 32 : - get_reg(fast_pool, regs); + fast_pool->pool[3] ^= ip >> 32; fast_mix(fast_pool); add_interrupt_bench(cycles); -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/8] random: remove stale maybe_reseed_primary_crng
>From 5e84a71d4c4b3c7f015878c0907102634603d270 Mon Sep 17 00:00:00 2001 From: Stephan MuellerDate: Thu, 15 Dec 2016 12:42:33 +0100 Subject: The function maybe_reseed_primary_crng is not used anywhere and thus can be removed. Besides, it contains the check crng_init > 2 which will never become true and thus would never trigger a reseed of the ChaCha20 primary DRNG. Signed-off-by: Stephan Mueller --- drivers/char/random.c | 7 --- 1 file changed, 7 deletions(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index 1ef2640..8e5ab20 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -855,13 +855,6 @@ static void crng_reseed(struct crng_state *crng, struct entropy_store *r) spin_unlock_irqrestore(_crng.lock, flags); } -static inline void maybe_reseed_primary_crng(void) -{ - if (crng_init > 2 && - time_after(jiffies, primary_crng.init_time + CRNG_RESEED_INTERVAL)) - crng_reseed(_crng, _pool); -} - static inline void crng_wait_ready(void) { wait_event_interruptible(crng_init_wait, crng_ready()); -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/8] random: fix comment for unused random_min_urandom_seed
The variable random_min_urandom_seed is not needed any more as it defined the reseeding behavior of the nonblocking pool. Though it is not needed any more, it is left in the code for user space interface compatibility. Signed-off-by: Stephan Mueller--- drivers/char/random.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index d19108c..89d67c0 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -313,9 +313,7 @@ static int random_read_wakeup_bits = 64; static int random_write_wakeup_bits = 28 * OUTPUT_POOL_WORDS; /* - * The minimum number of seconds between urandom pool reseeding. We - * do this to limit the amount of entropy that can be drained from the - * input pool even if there are heavy demands on /dev/urandom. + * Variable is currently unused by left for user space compatibility. */ static int random_min_urandom_seed = 60; -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/8] random: cleanup of code after removal of nonblocking pool
Hi Ted, with the removal of the nonblocking_pool, several code paths are now unused which were only applicable to the nonblocking pool. This patch set removes these unused code paths. Also, a code path in the add_interrupt_randomness function that is never used is removed. In addition, the FIPS 140-2 continuous self tests are required to process the output data of the RNG given to a caller. A patch is added to cover this requirement. Ciao Stephan Stephan Mueller (8): random: remove stale maybe_reseed_primary_crng random: remove stale urandom_init_wait random: trigger random_ready callback upon crng_init == 1 random: remove unused branch in hot code path random: remove variable limit random: fix comment for unused random_min_urandom_seed random: remove noop function call to xfer_secondary_pool random: move FIPS continuous test to output functions drivers/char/random.c | 118 +++--- 1 file changed, 53 insertions(+), 65 deletions(-) -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/8] random: remove variable limit
The variable limit was used to identify the nonblocking pool's unlimited random number generation. As the nonblocking pool is a thing of the past, remove the limit variable and any conditions around it (i.e. preserve the branches for limit == 1). Signed-off-by: Stephan Mueller--- drivers/char/random.c | 30 +++--- 1 file changed, 7 insertions(+), 23 deletions(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index 8d4d720..d19108c 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -466,7 +466,6 @@ struct entropy_store { int entropy_count; int entropy_total; unsigned int initialized:1; - unsigned int limit:1; unsigned int last_data_init:1; __u8 last_data[EXTRACT_SIZE]; }; @@ -484,7 +483,6 @@ static __u32 blocking_pool_data[OUTPUT_POOL_WORDS] __latent_entropy; static struct entropy_store input_pool = { .poolinfo = _table[0], .name = "input", - .limit = 1, .lock = __SPIN_LOCK_UNLOCKED(input_pool.lock), .pool = input_pool_data }; @@ -492,7 +490,6 @@ static struct entropy_store input_pool = { static struct entropy_store blocking_pool = { .poolinfo = _table[1], .name = "blocking", - .limit = 1, .pull = _pool, .lock = __SPIN_LOCK_UNLOCKED(blocking_pool.lock), .pool = blocking_pool_data, @@ -1212,15 +1209,6 @@ static void xfer_secondary_pool(struct entropy_store *r, size_t nbytes) r->entropy_count > r->poolinfo->poolfracbits) return; - if (r->limit == 0 && random_min_urandom_seed) { - unsigned long now = jiffies; - - if (time_before(now, - r->last_pulled + random_min_urandom_seed * HZ)) - return; - r->last_pulled = now; - } - _xfer_secondary_pool(r, nbytes); } @@ -1228,8 +1216,6 @@ static void _xfer_secondary_pool(struct entropy_store *r, size_t nbytes) { __u32 tmp[OUTPUT_POOL_WORDS]; - /* For /dev/random's pool, always leave two wakeups' worth */ - int rsvd_bytes = r->limit ? 0 : random_read_wakeup_bits / 4; int bytes = nbytes; /* pull at least as much as a wakeup */ @@ -1240,7 +1226,7 @@ static void _xfer_secondary_pool(struct entropy_store *r, size_t nbytes) trace_xfer_secondary_pool(r->name, bytes * 8, nbytes * 8, ENTROPY_BITS(r), ENTROPY_BITS(r->pull)); bytes = extract_entropy(r->pull, tmp, bytes, - random_read_wakeup_bits / 8, rsvd_bytes); + random_read_wakeup_bits / 8, 0); mix_pool_bytes(r, tmp, bytes); credit_entropy_bits(r, bytes*8); } @@ -1268,7 +1254,7 @@ static void push_to_pool(struct work_struct *work) static size_t account(struct entropy_store *r, size_t nbytes, int min, int reserved) { - int entropy_count, orig; + int entropy_count, orig, have_bytes; size_t ibytes, nfrac; BUG_ON(r->entropy_count > r->poolinfo->poolfracbits); @@ -1277,14 +1263,12 @@ static size_t account(struct entropy_store *r, size_t nbytes, int min, retry: entropy_count = orig = ACCESS_ONCE(r->entropy_count); ibytes = nbytes; - /* If limited, never pull more than available */ - if (r->limit) { - int have_bytes = entropy_count >> (ENTROPY_SHIFT + 3); + /* never pull more than available */ + have_bytes = entropy_count >> (ENTROPY_SHIFT + 3); - if ((have_bytes -= reserved) < 0) - have_bytes = 0; - ibytes = min_t(size_t, ibytes, have_bytes); - } + if ((have_bytes -= reserved) < 0) + have_bytes = 0; + ibytes = min_t(size_t, ibytes, have_bytes); if (ibytes < min) ibytes = 0; -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/8] random: trigger random_ready callback upon crng_init == 1
The random_ready callback mechanism is intended to replicate the getrandom system call behavior to in-kernel users. As the getrandom system call unblocks with crng_init == 1, trigger the random_ready wakeup call at the same time. Signed-off-by: Stephan Mueller--- drivers/char/random.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/char/random.c b/drivers/char/random.c index 482531d..5c26b1c 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -810,6 +810,7 @@ static int crng_fast_load(const char *cp, size_t len) } if (crng_init_cnt >= CRNG_INIT_CNT_THRESH) { crng_init = 1; + process_random_ready_list(); wake_up_interruptible(_init_wait); pr_notice("random: fast init done\n"); } -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/8] random: remove stale urandom_init_wait
The urandom_init_wait wait queue is a left over from the pre-ChaCha20 times and can therefore be savely removed. Signed-off-by: Stephan Mueller--- drivers/char/random.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index 8e5ab20..482531d 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -409,7 +409,6 @@ static struct poolinfo { */ static DECLARE_WAIT_QUEUE_HEAD(random_read_wait); static DECLARE_WAIT_QUEUE_HEAD(random_write_wait); -static DECLARE_WAIT_QUEUE_HEAD(urandom_init_wait); static struct fasync_struct *fasync; static DEFINE_SPINLOCK(random_ready_list_lock); -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/8] random: move FIPS continuous test to output functions
The current lockation of the FIPS continuous self test covers the input_pool only. However, the FIPS continuous self test shall cover the output of the random number generator, i.e. the blocking pool and the ChaCha20 DRNG. This patch therefore moves the continuous test to the output function used for /dev/random. In addition, it adds the continuous test to the ChaCha20 output function. Signed-off-by: Stephan Mueller--- drivers/char/random.c | 71 +++ 1 file changed, 43 insertions(+), 28 deletions(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index 7b72a01..d185d1f 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -416,6 +416,8 @@ struct crng_state { __u32 state[16]; unsigned long init_time; spinlock_t lock; + unsigned int last_data_init:1; + __u8 last_data[CHACHA20_BLOCK_SIZE]; }; struct crng_state primary_crng = { @@ -471,7 +473,7 @@ struct entropy_store { static ssize_t extract_entropy(struct entropy_store *r, void *buf, size_t nbytes, int min, int rsvd); static ssize_t _extract_entropy(struct entropy_store *r, void *buf, - size_t nbytes, int fips); + size_t nbytes); static void crng_reseed(struct crng_state *crng, struct entropy_store *r); static void push_to_pool(struct work_struct *work); @@ -775,7 +777,7 @@ static void crng_initialize(struct crng_state *crng) memcpy(>state[0], "expand 32-byte k", 16); if (crng == _crng) _extract_entropy(_pool, >state[4], -sizeof(__u32) * 12, 0); +sizeof(__u32) * 12); else get_random_bytes(>state[4], sizeof(__u32) * 12); for (i = 4; i < 16; i++) { @@ -864,11 +866,25 @@ static void _extract_crng(struct crng_state *crng, time_after(jiffies, crng->init_time + CRNG_RESEED_INTERVAL)) crng_reseed(crng, crng == _crng ? _pool : NULL); spin_lock_irqsave(>lock, flags); + + if (fips_enabled && !crng->last_data_init) { + crng->last_data_init = 1; + chacha20_block(>state[0], out); + memcpy(crng->last_data, out, CHACHA20_BLOCK_SIZE); + } + if (arch_get_random_long()) crng->state[14] ^= v; chacha20_block(>state[0], out); if (crng->state[12] == 0) crng->state[13]++; + + if (fips_enabled) { + if (!memcmp(out, crng->last_data, CHACHA20_BLOCK_SIZE)) + panic("ChaCha20 RNG duplicated output!\n"); + memcpy(crng->last_data, out, CHACHA20_BLOCK_SIZE); + } + spin_unlock_irqrestore(>lock, flags); } @@ -1356,22 +1372,14 @@ static void extract_buf(struct entropy_store *r, __u8 *out) } static ssize_t _extract_entropy(struct entropy_store *r, void *buf, - size_t nbytes, int fips) + size_t nbytes) { ssize_t ret = 0, i; __u8 tmp[EXTRACT_SIZE]; - unsigned long flags; while (nbytes) { extract_buf(r, tmp); - if (fips) { - spin_lock_irqsave(>lock, flags); - if (!memcmp(tmp, r->last_data, EXTRACT_SIZE)) - panic("Hardware RNG duplicated output!\n"); - memcpy(r->last_data, tmp, EXTRACT_SIZE); - spin_unlock_irqrestore(>lock, flags); - } i = min_t(int, nbytes, EXTRACT_SIZE); memcpy(buf, tmp, i); nbytes -= i; @@ -1397,7 +1405,22 @@ static ssize_t _extract_entropy(struct entropy_store *r, void *buf, static ssize_t extract_entropy(struct entropy_store *r, void *buf, size_t nbytes, int min, int reserved) { + trace_extract_entropy(r->name, nbytes, ENTROPY_BITS(r), _RET_IP_); + nbytes = account(r, nbytes, min, reserved); + + return _extract_entropy(r, buf, nbytes); +} + +/* + * This function extracts randomness from the "entropy pool", and + * returns it in a userspace buffer. + */ +static ssize_t extract_entropy_user(struct entropy_store *r, void __user *buf, + size_t nbytes) +{ + ssize_t ret = 0, i; __u8 tmp[EXTRACT_SIZE]; + int large_request = (nbytes > 256); unsigned long flags; /* if last_data isn't primed, we need EXTRACT_SIZE extra bytes */ @@ -1416,23 +1439,6 @@ static ssize_t extract_entropy(struct entropy_store *r, void *buf, spin_unlock_irqrestore(>lock, flags); } - trace_extract_entropy(r->name, nbytes, ENTROPY_BITS(r), _RET_IP_); - nbytes = account(r, nbytes, min, reserved); - - return _extract_entropy(r, buf, nbytes, fips_enabled);
[PATCH 7/8] random: remove noop function call to xfer_secondary_pool
Since the introduction of the ChaCha20 DRNG, extract_entropy is only invoked with the input_pool. For this entropy pool, xfer_secondary_pool is a no-op and can therefore be safely removed. Signed-off-by: Stephan Mueller--- drivers/char/random.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index 89d67c0..7b72a01 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -1417,7 +1417,6 @@ static ssize_t extract_entropy(struct entropy_store *r, void *buf, } trace_extract_entropy(r->name, nbytes, ENTROPY_BITS(r), _RET_IP_); - xfer_secondary_pool(r, nbytes); nbytes = account(r, nbytes, min, reserved); return _extract_entropy(r, buf, nbytes, fips_enabled); -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] crypto: arm64/ARM: NEON accelerated ChaCha20
On 27 December 2016 at 15:36, Jeffrey Waltonwrote: >> ChaCha20 is a stream cipher described in RFC 7539, and is intended to be >> an efficient software implementable 'standby cipher', in case AES cannot >> be used. > > That's not quite correct. > > The IETF changed the algorithm a bit, and its not compatible with > Bernstein's ChaCha. They probably should have differentiated the name > to avoid this sort of confusion. > > You can find Bernstein's specification for ChaCha at > https://cr.yp.to/chacha.html, and the test vectors for Bernstein's > specification at > http://tools.ietf.org/html/draft-strombergson-chacha-test-vectors. > Thanks for the clarification. However, this should not affect the content of the patches: they simply reimplement in ARM SIMD what the kernel already knows as "chacha20", which is the IETF derivative rather than djb's original. I will mention this in the cover letter of the next respin (given that I need to respin these anyway) -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be used without shash
On Tue, Dec 27, 2016 at 6:16 AM, Daniel Borkmannwrote: > On 12/27/2016 10:58 AM, Herbert Xu wrote: >> >> On Mon, Dec 26, 2016 at 10:08:48AM -0800, Andy Lutomirski wrote: >>> >>> >>> According to Daniel, the networking folks want to let embedded systems >>> include BPF without requiring the crypto core. >> >> >> Last I checked the IPv4 stack depended on the crypto API so this >> sounds bogus. > > > I think there's a bit of a mixup here with what I said. To clarify, > requirement back then from tracing folks was that bpf engine and > therefore bpf syscall can be build w/o networking enabled for small > devices, so dependencies preferably need to be kept on a absolute > minimum, same counts for either making it suddenly a depend on > CRYPTO or a select CRYPTO for just those few lines that can be > pulled in from lib/ code instead. Somehow I had that in my head as "networking" not "tracing", probably because of the TCA stuff. Whoops. Anyway, I'm rewriting the crypto part of the patch completely based on Ard's feedback. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: arm/aes-neonbs - process 8 blocks in parallel if we can
On 27 December 2016 at 08:57, Herbert Xuwrote: > On Fri, Dec 09, 2016 at 01:47:26PM +, Ard Biesheuvel wrote: >> The bit-sliced NEON implementation of AES only performs optimally if >> it can process 8 blocks of input in parallel. This is due to the nature >> of bit slicing, where the n-th bit of each byte of AES state of each input >> block is collected into NEON register 'n', for registers q0 - q7. >> >> This implies that the amount of work for the transform is fixed, >> regardless of whether we are handling just one block or 8 in parallel. >> >> So let's try a bit harder to iterate over the input in suitably sized >> chunks, by increasing the chunksize to 8 * AES_BLOCK_SIZE, and tweaking >> the loops to only process multiples of the chunk size, unless we are >> handling the last chunk in the input stream. >> >> Note that the skcipher walk API guarantees that a step in the walk never >> returns less that 'chunksize' bytes if there are at least that many bytes >> of input still available. However, it does *not* guarantee that those steps >> produce an exact multiple of the chunk size. >> >> Signed-off-by: Ard Biesheuvel > > I like this patch. However, I had different plans for the chunksize > attribute. It's primarily meant to be a hint to the upper layer > in case it does partial updates. It's meant to provide the minimum > number of bytes a partial update can carry without screwing up > subsequent updates. > > It just happens to be the same value that we were using during > an skcipher walk. > > So I think for your case we should add a new attribute, perhaps > walk_chunksize or walksize, which doesn't need to be exported to > the outside at all and can then be used by the walk interface. > OK, I will try to hack something up. One thing to keep in mind though is that stacked chaining modes should present the data with the same granularity for optimal performance. E.g., xts(ecb(aes)) should pass 8 blocks at a time. How should this requirement be incorporated according to you? -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] crypto: arm64/ARM: NEON accelerated ChaCha20
> ChaCha20 is a stream cipher described in RFC 7539, and is intended to be > an efficient software implementable 'standby cipher', in case AES cannot > be used. That's not quite correct. The IETF changed the algorithm a bit, and its not compatible with Bernstein's ChaCha. They probably should have differentiated the name to avoid this sort of confusion. You can find Bernstein's specification for ChaCha at https://cr.yp.to/chacha.html, and the test vectors for Bernstein's specification at http://tools.ietf.org/html/draft-strombergson-chacha-test-vectors. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] crypto: arm64/ARM: NEON accelerated ChaCha20
> On 27 Dec 2016, at 10:04, Herbert Xuwrote: > >> On Thu, Dec 08, 2016 at 02:28:57PM +, Ard Biesheuvel wrote: >> Another port of existing x86 SSE code to NEON, again both for arm64 and ARM. >> >> ChaCha20 is a stream cipher described in RFC 7539, and is intended to be >> an efficient software implementable 'standby cipher', in case AES cannot >> be used. >> >> This NEON implementation is almost 2x as fast as the generic C code >> (measured on Cortex-A57 using the arm64 version) >> >> I'm aware that blkciphers are deprecated in favor of skciphers, but this >> code (like the x86 version) uses the init and setkey routines of the generic >> version, so it is probably better to port all implementations at once. >> >> Ard Biesheuvel (2): >> crypto: arm64/chacha20 - implement NEON version based on SSE3 code >> crypto: arm/chacha20 - implement NEON version based on SSE3 code > > Both patches applied. Thanks. You just nacked the v2 of this series (due to the chunksize/walksize) and i rewrote them as skciphers as well > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be used without shash
On 12/27/2016 10:58 AM, Herbert Xu wrote: On Mon, Dec 26, 2016 at 10:08:48AM -0800, Andy Lutomirski wrote: According to Daniel, the networking folks want to let embedded systems include BPF without requiring the crypto core. Last I checked the IPv4 stack depended on the crypto API so this sounds bogus. I think there's a bit of a mixup here with what I said. To clarify, requirement back then from tracing folks was that bpf engine and therefore bpf syscall can be build w/o networking enabled for small devices, so dependencies preferably need to be kept on a absolute minimum, same counts for either making it suddenly a depend on CRYPTO or a select CRYPTO for just those few lines that can be pulled in from lib/ code instead. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/3] Cavium ThunderX ZIP driver
Hi Herbert, Thanks for your response >Hi Jan: On Mon, Dec 12, 2016 at 04:04:36PM +0100, Jan Glauber wrote: > > > >this series adds support for hardware accelerated compression & decompression > >as found on ThunderX (arm64) SOCs. I've been reviewing this driver internally > >for some time and would like to get feedback on the RFC to see if this goes > >into the right direction and to see if there are any concerns. > > > >We've discussed switching to the new acomp algorithm but for the time being > >decided against acomp because our test cases are not yet supported with it. > OK. Do you see any major problems in converting this over to acomp? Mahipal: One major issue is, the kernel use cases to validate the Cavium ThunderX ZIP driver are "ZSWAP" and "IPComp" which are not yet supported with scomp-acomp framework. Regards, -Mahipal From: Herbert XuSent: Tuesday, December 27, 2016 2:32 PM To: Jan Glauber Cc: linux-crypto@vger.kernel.org; linux-ker...@vger.kernel.org; David S . Miller; Challa, Mahipal; Nair, Vishnu Subject: Re: [RFC PATCH 0/3] Cavium ThunderX ZIP driver Hi Jan: On Mon, Dec 12, 2016 at 04:04:36PM +0100, Jan Glauber wrote: > > this series adds support for hardware accelerated compression & decompression > as found on ThunderX (arm64) SOCs. I've been reviewing this driver internally > for some time and would like to get feedback on the RFC to see if this goes > into the right direction and to see if there are any concerns. > > We've discussed switching to the new acomp algorithm but for the time being > decided against acomp because our test cases are not yet supported with it. OK. Do you see any major problems in converting this over to acomp? Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cryptodev:master 4/17] arch/arm/crypto/chacha20-neon-glue.c:68:32: error: passing argument 1 of 'crypto_chacha20_crypt' from incompatible pointer type
tree: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master head: fb91a661d99f460f2ea4c7f23ed47f56863ca1d1 commit: 9ae433bc79f97bae221d53bb1a8e21415ea58625 [4/17] crypto: chacha20 - convert generic and x86 versions to skcipher config: arm-allmodconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 9ae433bc79f97bae221d53bb1a8e21415ea58625 # save the attached .config to linux build tree make.cross ARCH=arm All errors (new ones prefixed by >>): arch/arm/crypto/chacha20-neon-glue.c: In function 'chacha20_simd': >> arch/arm/crypto/chacha20-neon-glue.c:68:32: error: passing argument 1 of >> 'crypto_chacha20_crypt' from incompatible pointer type >> [-Werror=incompatible-pointer-types] return crypto_chacha20_crypt(desc, dst, src, nbytes); ^~~~ In file included from arch/arm/crypto/chacha20-neon-glue.c:22:0: include/crypto/chacha20.h:24:5: note: expected 'struct skcipher_request *' but argument is of type 'struct blkcipher_desc *' int crypto_chacha20_crypt(struct skcipher_request *req); ^ >> arch/arm/crypto/chacha20-neon-glue.c:68:10: error: too many arguments to >> function 'crypto_chacha20_crypt' return crypto_chacha20_crypt(desc, dst, src, nbytes); ^ In file included from arch/arm/crypto/chacha20-neon-glue.c:22:0: include/crypto/chacha20.h:24:5: note: declared here int crypto_chacha20_crypt(struct skcipher_request *req); ^ arch/arm/crypto/chacha20-neon-glue.c: At top level: >> arch/arm/crypto/chacha20-neon-glue.c:111:15: error: initialization from >> incompatible pointer type [-Werror=incompatible-pointer-types] .setkey = crypto_chacha20_setkey, ^~ arch/arm/crypto/chacha20-neon-glue.c:111:15: note: (near initialization for 'alg.cra_u.blkcipher.setkey') cc1: some warnings being treated as errors vim +/crypto_chacha20_crypt +68 arch/arm/crypto/chacha20-neon-glue.c 80966672 Ard Biesheuvel 2016-12-08 62 { 80966672 Ard Biesheuvel 2016-12-08 63 struct blkcipher_walk walk; 80966672 Ard Biesheuvel 2016-12-08 64 u32 state[16]; 80966672 Ard Biesheuvel 2016-12-08 65 int err; 80966672 Ard Biesheuvel 2016-12-08 66 80966672 Ard Biesheuvel 2016-12-08 67 if (nbytes <= CHACHA20_BLOCK_SIZE || !may_use_simd()) 80966672 Ard Biesheuvel 2016-12-08 @68 return crypto_chacha20_crypt(desc, dst, src, nbytes); 80966672 Ard Biesheuvel 2016-12-08 69 80966672 Ard Biesheuvel 2016-12-08 70 blkcipher_walk_init(, dst, src, nbytes); 80966672 Ard Biesheuvel 2016-12-08 71 err = blkcipher_walk_virt_block(desc, , CHACHA20_BLOCK_SIZE); 80966672 Ard Biesheuvel 2016-12-08 72 80966672 Ard Biesheuvel 2016-12-08 73 crypto_chacha20_init(state, crypto_blkcipher_ctx(desc->tfm), walk.iv); 80966672 Ard Biesheuvel 2016-12-08 74 80966672 Ard Biesheuvel 2016-12-08 75 kernel_neon_begin(); 80966672 Ard Biesheuvel 2016-12-08 76 80966672 Ard Biesheuvel 2016-12-08 77 while (walk.nbytes >= CHACHA20_BLOCK_SIZE) { 80966672 Ard Biesheuvel 2016-12-08 78 chacha20_dosimd(state, walk.dst.virt.addr, walk.src.virt.addr, 80966672 Ard Biesheuvel 2016-12-08 79 rounddown(walk.nbytes, CHACHA20_BLOCK_SIZE)); 80966672 Ard Biesheuvel 2016-12-08 80 err = blkcipher_walk_done(desc, , 80966672 Ard Biesheuvel 2016-12-08 81 walk.nbytes % CHACHA20_BLOCK_SIZE); 80966672 Ard Biesheuvel 2016-12-08 82 } 80966672 Ard Biesheuvel 2016-12-08 83 80966672 Ard Biesheuvel 2016-12-08 84 if (walk.nbytes) { 80966672 Ard Biesheuvel 2016-12-08 85 chacha20_dosimd(state, walk.dst.virt.addr, walk.src.virt.addr, 80966672 Ard Biesheuvel 2016-12-08 86 walk.nbytes); 80966672 Ard Biesheuvel 2016-12-08 87 err = blkcipher_walk_done(desc, , 0); 80966672 Ard Biesheuvel 2016-12-08 88 } 80966672 Ard Biesheuvel 2016-12-08 89 80966672 Ard Biesheuvel 2016-12-08 90 kernel_neon_end(); 80966672 Ard Biesheuvel 2016-12-08 91 80966672 Ard Biesheuvel 2016-12-08 92 return err; 80966672 Ard Biesheuvel 2016-12-08 93 } 80966672 Ard Biesheuvel 2016-12-08 94 80966672 Ard Biesheuvel 2016-12-08 95 static struct crypto_alg alg = { 80966672 Ard Biesheuvel 2016-12-08 96 .cra_name = "chacha20", 80966672 Ard Biesheuvel 2016-12-08 97 .cra_driver_name= "chacha20-neon", 80966672 Ard Biesheuvel 2016-12-08 98
[cryptodev:master 4/17] arch/arm64/crypto/chacha20-neon-glue.c:66:32: error: passing argument 1 of 'crypto_chacha20_crypt' from incompatible pointer type
tree: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master head: fb91a661d99f460f2ea4c7f23ed47f56863ca1d1 commit: 9ae433bc79f97bae221d53bb1a8e21415ea58625 [4/17] crypto: chacha20 - convert generic and x86 versions to skcipher config: arm64-allmodconfig (attached as .config) compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 9ae433bc79f97bae221d53bb1a8e21415ea58625 # save the attached .config to linux build tree make.cross ARCH=arm64 All errors (new ones prefixed by >>): arch/arm64/crypto/chacha20-neon-glue.c: In function 'chacha20_simd': >> arch/arm64/crypto/chacha20-neon-glue.c:66:32: error: passing argument 1 of >> 'crypto_chacha20_crypt' from incompatible pointer type >> [-Werror=incompatible-pointer-types] return crypto_chacha20_crypt(desc, dst, src, nbytes); ^~~~ In file included from arch/arm64/crypto/chacha20-neon-glue.c:22:0: include/crypto/chacha20.h:24:5: note: expected 'struct skcipher_request *' but argument is of type 'struct blkcipher_desc *' int crypto_chacha20_crypt(struct skcipher_request *req); ^ >> arch/arm64/crypto/chacha20-neon-glue.c:66:10: error: too many arguments to >> function 'crypto_chacha20_crypt' return crypto_chacha20_crypt(desc, dst, src, nbytes); ^ In file included from arch/arm64/crypto/chacha20-neon-glue.c:22:0: include/crypto/chacha20.h:24:5: note: declared here int crypto_chacha20_crypt(struct skcipher_request *req); ^ arch/arm64/crypto/chacha20-neon-glue.c: At top level: >> arch/arm64/crypto/chacha20-neon-glue.c:109:15: error: initialization from >> incompatible pointer type [-Werror=incompatible-pointer-types] .setkey = crypto_chacha20_setkey, ^~ arch/arm64/crypto/chacha20-neon-glue.c:109:15: note: (near initialization for 'alg.cra_u.blkcipher.setkey') cc1: some warnings being treated as errors vim +/crypto_chacha20_crypt +66 arch/arm64/crypto/chacha20-neon-glue.c 8621caa0 Ard Biesheuvel 2016-12-08 60 { 8621caa0 Ard Biesheuvel 2016-12-08 61 struct blkcipher_walk walk; 8621caa0 Ard Biesheuvel 2016-12-08 62 u32 state[16]; 8621caa0 Ard Biesheuvel 2016-12-08 63 int err; 8621caa0 Ard Biesheuvel 2016-12-08 64 8621caa0 Ard Biesheuvel 2016-12-08 65 if (nbytes <= CHACHA20_BLOCK_SIZE) 8621caa0 Ard Biesheuvel 2016-12-08 @66 return crypto_chacha20_crypt(desc, dst, src, nbytes); 8621caa0 Ard Biesheuvel 2016-12-08 67 8621caa0 Ard Biesheuvel 2016-12-08 68 blkcipher_walk_init(, dst, src, nbytes); 8621caa0 Ard Biesheuvel 2016-12-08 69 err = blkcipher_walk_virt_block(desc, , CHACHA20_BLOCK_SIZE); 8621caa0 Ard Biesheuvel 2016-12-08 70 8621caa0 Ard Biesheuvel 2016-12-08 71 crypto_chacha20_init(state, crypto_blkcipher_ctx(desc->tfm), walk.iv); 8621caa0 Ard Biesheuvel 2016-12-08 72 8621caa0 Ard Biesheuvel 2016-12-08 73 kernel_neon_begin(); 8621caa0 Ard Biesheuvel 2016-12-08 74 8621caa0 Ard Biesheuvel 2016-12-08 75 while (walk.nbytes >= CHACHA20_BLOCK_SIZE) { 8621caa0 Ard Biesheuvel 2016-12-08 76 chacha20_dosimd(state, walk.dst.virt.addr, walk.src.virt.addr, 8621caa0 Ard Biesheuvel 2016-12-08 77 rounddown(walk.nbytes, CHACHA20_BLOCK_SIZE)); 8621caa0 Ard Biesheuvel 2016-12-08 78 err = blkcipher_walk_done(desc, , 8621caa0 Ard Biesheuvel 2016-12-08 79 walk.nbytes % CHACHA20_BLOCK_SIZE); 8621caa0 Ard Biesheuvel 2016-12-08 80 } 8621caa0 Ard Biesheuvel 2016-12-08 81 8621caa0 Ard Biesheuvel 2016-12-08 82 if (walk.nbytes) { 8621caa0 Ard Biesheuvel 2016-12-08 83 chacha20_dosimd(state, walk.dst.virt.addr, walk.src.virt.addr, 8621caa0 Ard Biesheuvel 2016-12-08 84 walk.nbytes); 8621caa0 Ard Biesheuvel 2016-12-08 85 err = blkcipher_walk_done(desc, , 0); 8621caa0 Ard Biesheuvel 2016-12-08 86 } 8621caa0 Ard Biesheuvel 2016-12-08 87 8621caa0 Ard Biesheuvel 2016-12-08 88 kernel_neon_end(); 8621caa0 Ard Biesheuvel 2016-12-08 89 8621caa0 Ard Biesheuvel 2016-12-08 90 return err; 8621caa0 Ard Biesheuvel 2016-12-08 91 } 8621caa0 Ard Biesheuvel 2016-12-08 92 8621caa0 Ard Biesheuvel 2016-12-08 93 static struct crypto_alg alg = { 8621caa0 Ard Biesheuvel 2016-12-08 94 .cra_name = "chacha20", 8621caa0 Ard Biesheuvel 2016-12-08 95 .cra_driver_name= "chacha20-neon", 8621caa0 Ard Biesheuvel 2016-12-08 96
Re: [PATCHv2] crypto: testmgr: Use heap buffer for acomp test input
On Wed, Dec 21, 2016 at 12:32:54PM -0800, Laura Abbott wrote: > > Christopher Covington reported a crash on aarch64 on recent Fedora > kernels: > > kernel BUG at ./include/linux/scatterlist.h:140! > Internal error: Oops - BUG: 0 [#1] PREEMPT SMP > Modules linked in: > CPU: 2 PID: 752 Comm: cryptomgr_test Not tainted 4.9.0-11815-ge93b1cc #162 > Hardware name: linux,dummy-virt (DT) > task: 80007c650080 task.stack: 8891 > PC is at sg_init_one+0xa0/0xb8 > LR is at sg_init_one+0x24/0xb8 > ... > [] sg_init_one+0xa0/0xb8 > [] test_acomp+0x10c/0x438 > [] alg_test_comp+0xb0/0x118 > [] alg_test+0x17c/0x2f0 > [] cryptomgr_test+0x44/0x50 > [] kthread+0xf8/0x128 > [] ret_from_fork+0x10/0x50 > > The test vectors used for input are part of the kernel image. These > inputs are passed as a buffer to sg_init_one which eventually blows up > with BUG_ON(!virt_addr_valid(buf)). On arm64, virt_addr_valid returns > false for the kernel image since virt_to_page will not return the > correct page. Fix this by copying the input vectors to heap buffer > before setting up the scatterlist. > > Reported-by: Christopher Covington> Fixes: d7db7a882deb ("crypto: acomp - update testmgr with support for acomp") > Signed-off-by: Laura Abbott Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/2] Add MediaTek crypto accelerator driver
On Mon, Dec 19, 2016 at 10:20:43AM +0800, Ryder Lee wrote: > Hello, > > This adds support for the MediaTek hardware accelerator on > some SoCs. > > This driver currently implement: > - SHA1 and SHA2 family(HMAC) hash algorithms. > - AES block cipher in CBC/ECB mode with 128/196/256 bits keys. > > Chances since v3: > -remove unused structure member > -drop interrupt-parent from DT bindings documentation > > Changes since v2: > - use byteorder conversion macros and type identifiers for descriptors > - revise register definition macros to make it more clear > - revise DT compatiable string > > Changes since v1: > - remove EXPORT_SYMBOL > - remove unused PRNG setting > - sort headers in alphabetical order > - add a definition for IRQ unmber > - replace ambiguous definition > - add more annotation and function comment > - add COMPILE_TEST in Kconfig > > Ryder Lee (2): > Add crypto driver support for some MediaTek chips > crypto: mediatek - add DT bindings documentation All applied. Thanks. -- Email: Herbert XuHome Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -resend with CC] crypto: algif_hash, avoid zero-sized array
On Thu, Dec 15, 2016 at 02:31:01PM +0100, Jiri Slaby wrote: > With this reproducer: > struct sockaddr_alg alg = { > .salg_family = 0x26, > .salg_type = "hash", > .salg_feat = 0xf, > .salg_mask = 0x5, > .salg_name = "digest_null", > }; > int sock, sock2; > > sock = socket(AF_ALG, SOCK_SEQPACKET, 0); > bind(sock, (struct sockaddr *), sizeof(alg)); > sock2 = accept(sock, NULL, NULL); > setsockopt(sock, SOL_ALG, ALG_SET_KEY, "\x9b\xca", 2); > accept(sock2, NULL, NULL); Patch applied. Thanks. -- Email: Herbert XuHome Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7] hwrng: core: do not use multiple blank lines
On Tue, Dec 13, 2016 at 03:51:09PM +0100, Corentin Labbe wrote: > This patch fix the checkpatch warning "Please don't use multiple blank lines" > > Signed-off-by: Corentin LabbePatches 1-6 applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: aesni-intel - RFC4106 can zero copy when !PageHighMem
On Tue, Dec 13, 2016 at 04:32:06PM +0200, Ilya Lesokhin wrote: > In the common case of !PageHighMem we can do zero copy crypto > even if sg crosses a pages boundary. > > Signed-off-by: Ilya LesokhinPatch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] crypto: chacha20 - convert generic and x86 versions to skcipher
On Fri, Dec 09, 2016 at 02:33:51PM +, Ard Biesheuvel wrote: > This converts the ChaCha20 code from a blkcipher to a skcipher, which > is now the preferred way to implement symmetric block and stream ciphers. > > This ports the generic and x86 versions at the same time because the > latter reuses routines of the former. > > Note that the skcipher_walk() API guarantees that all presented blocks > except the final one are a multiple of the chunk size, so we can simplify > the encrypt() routine somewhat. > > Signed-off-by: Ard BiesheuvelPatch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: bring back alphabetical order of Makefile
On Tue, Dec 13, 2016 at 03:30:59PM +0100, Corentin Labbe wrote: > THe major content of drivers/crypto/Makefile is sorted, only recent > addition break this sort. > > This patch bring back this alphabetical sorting. > > Signed-off-by: Corentin LabbePatch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] crypto: arm64/ARM: NEON accelerated ChaCha20
On Thu, Dec 08, 2016 at 02:28:57PM +, Ard Biesheuvel wrote: > Another port of existing x86 SSE code to NEON, again both for arm64 and ARM. > > ChaCha20 is a stream cipher described in RFC 7539, and is intended to be > an efficient software implementable 'standby cipher', in case AES cannot > be used. > > This NEON implementation is almost 2x as fast as the generic C code > (measured on Cortex-A57 using the arm64 version) > > I'm aware that blkciphers are deprecated in favor of skciphers, but this > code (like the x86 version) uses the init and setkey routines of the generic > version, so it is probably better to port all implementations at once. > > Ard Biesheuvel (2): > crypto: arm64/chacha20 - implement NEON version based on SSE3 code > crypto: arm/chacha20 - implement NEON version based on SSE3 code Both patches applied. Thanks. -- Email: Herbert XuHome Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be used without shash
On Mon, Dec 26, 2016 at 10:08:48AM -0800, Andy Lutomirski wrote: > > According to Daniel, the networking folks want to let embedded systems > include BPF without requiring the crypto core. Last I checked the IPv4 stack depended on the crypto API so this sounds bogus. Cheers, -- Email: Herbert XuHome Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [sparc64] cryptomgr_test OOPS kernel 4.9.0+
On Mon, Dec 26, 2016 at 05:26:19PM -0500, David Miller wrote: > From: Anatoly Pugachev> Date: Sun, 25 Dec 2016 20:56:08 +0300 > > > Disabling kernel config option > > CRYPTO_MANAGER_DISABLE_TESTS > > i.e. enable run-time self tests, makes kernel unbootable: > > > > tested with git kernels v4.9-8648-g5cc60aeedf31 and v4.9-12259-g7c0f6ba682b9 > > I think the testing code for the new synchronous compression module is > putting kernel image pointers into scatterlists, which in turn we > attempt to transform to and from page structs. > > That doesn't work. > > It's coming from the test input buffers: > > static int test_acomp(struct crypto_acomp *tfm, struct comp_testvec > *ctemplate, > struct comp_testvec *dtemplate, int ctcount, int dtcount) > { > ... > sg_init_one(, ctemplate[i].input, ilen); > > These have to be copied into kmalloc() buffers or similar, just like > the skchiper tests do. > > The crash on sparc64 shows that we try to dereference a page struct at > a bogus vmemmap address for a page that doesn't exist. > > I hacked up the following and this makes the crashes go away: Thanks Dave. I've just applied the patch https://patchwork.kernel.org/patch/9483763/ which should fix this. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Crypto Fixes for 4.10
Hi Linus: This push fixes a hash corruption bug in the marvell driver. Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus Romain Perier (1): crypto: marvell - Copy IVDIG before launching partial DMA ahash requests drivers/crypto/marvell/cesa.h |3 ++- drivers/crypto/marvell/hash.c | 34 +- drivers/crypto/marvell/tdma.c |9 - 3 files changed, 43 insertions(+), 3 deletions(-) Thanks, -- Email: Herbert XuHome Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/3] Cavium ThunderX ZIP driver
Hi Jan: On Mon, Dec 12, 2016 at 04:04:36PM +0100, Jan Glauber wrote: > > this series adds support for hardware accelerated compression & decompression > as found on ThunderX (arm64) SOCs. I've been reviewing this driver internally > for some time and would like to get feedback on the RFC to see if this goes > into the right direction and to see if there are any concerns. > > We've discussed switching to the new acomp algorithm but for the time being > decided against acomp because our test cases are not yet supported with it. OK. Do you see any major problems in converting this over to acomp? Thanks, -- Email: Herbert XuHome Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 7/7] hwrng: core: Remove linux/sched.h from includes
On Tue, Dec 13, 2016 at 03:51:15PM +0100, Corentin Labbe wrote: > linux/sched.h is useless for hw_random/core.c. > This patch remove it. I see a schedule_timeout_interruptible call in core.c. Cheers, -- Email: Herbert XuHome Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: arm64/aes: reimplement bit-sliced ARM/NEON implementation for arm64
On Mon, Dec 12, 2016 at 05:45:58PM +, Ard Biesheuvel wrote: > > + .chunksize = 8 * AES_BLOCK_SIZE, Same comment as to the previous patches regarding chunksize. Cheers, -- Email: Herbert XuHome Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] crypto: arm64/chacha20 - implement NEON version based on SSE3 code
On Fri, Dec 09, 2016 at 02:33:52PM +, Ard Biesheuvel wrote: > > + .chunksize = 4 * CHACHA20_BLOCK_SIZE, This should use a new attribute specific to the walk interface. Cheers, -- Email: Herbert XuHome Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: arm/aes-neonbs - process 8 blocks in parallel if we can
On Fri, Dec 09, 2016 at 01:47:26PM +, Ard Biesheuvel wrote: > The bit-sliced NEON implementation of AES only performs optimally if > it can process 8 blocks of input in parallel. This is due to the nature > of bit slicing, where the n-th bit of each byte of AES state of each input > block is collected into NEON register 'n', for registers q0 - q7. > > This implies that the amount of work for the transform is fixed, > regardless of whether we are handling just one block or 8 in parallel. > > So let's try a bit harder to iterate over the input in suitably sized > chunks, by increasing the chunksize to 8 * AES_BLOCK_SIZE, and tweaking > the loops to only process multiples of the chunk size, unless we are > handling the last chunk in the input stream. > > Note that the skcipher walk API guarantees that a step in the walk never > returns less that 'chunksize' bytes if there are at least that many bytes > of input still available. However, it does *not* guarantee that those steps > produce an exact multiple of the chunk size. > > Signed-off-by: Ard BiesheuvelI like this patch. However, I had different plans for the chunksize attribute. It's primarily meant to be a hint to the upper layer in case it does partial updates. It's meant to provide the minimum number of bytes a partial update can carry without screwing up subsequent updates. It just happens to be the same value that we were using during an skcipher walk. So I think for your case we should add a new attribute, perhaps walk_chunksize or walksize, which doesn't need to be exported to the outside at all and can then be used by the walk interface. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html