* Sebastian Andrzej Siewior | 2015-02-16 12:18:22 [+0100]:
>Known issues:
>
> - xor / raid_pq
>I had max latency jumping up to 67563us on one CPU while the next
>lower max was 58us. I tracked it down to module's init code of
>xor and raid_pq.
On 2016-09-26 21:18:21 [-0400], Paul Gortmaker wrote:
>
> ...and so it currently is not being built as a module by anyone.
that is correct.
Acked-by: Sebastian Andrzej Siewior
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body
RCE_RR_CPU=y.
Again, the preempt_disable() won't work here but lock which was
introduced will help.
In order to keep work-item on the local CPU (and avoid RR) I changed it
to queue_work_on().
Cc: sta...@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior
---
crypto/mcryptd
Users of rwlocks should include spinlock.h instead including this
header file. The current users of rwlocks_types.h are internal.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/crypto/ccp/ccp-dev.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/crypto/ccp/ccp-dev.c b/drivers
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior
---
include/linux/padata.h | 2 +-
kernel/padata.c| 92 --
2 files changed, 53 insertions(+), 41 deletions(-)
diff --git a/include/linux/padata.h b/include/linux/padat
On 2017-06-08 01:25:55 [+0200], Jason A. Donenfeld wrote:
> It's possible that get_random_{u32,u64} is used before the crng has
> initialized, in which case, its output might not be cryptographically
> secure. For this problem, directly, this patch set is introducing the
> *_wait variety of functio
On 2017-06-15 00:33:12 [+0200], Jason A. Donenfeld wrote:
> There's a potential race that I fixed in my v5 of that patch set, but
> Ted only took v4, and for whatever reason has been to busy to submit
> the additional patch I already posted showing the diff between v4&v5.
> Hopefully he actually ge
On 2017-06-15 00:45:26 [+0200], Jason A. Donenfeld wrote:
> Odd versions of gcc for the sh4 architecture will actually warn about
> flags being used while uninitialized, so we set them to zero. Non crazy
> gccs will optimize that out again, so it doesn't make a difference.
that is minor
> Next, o
On 2017-06-16 14:12:42 [+0200], Jason A. Donenfeld wrote:
> I actually figured that out myself after sending the initial email, so
> then I wrote a follow-up patch which I attached to this thread. You
> should have received it. Can you take a look?
replied to the patch.
Sebastian
On 2017-06-17 02:39:40 [+0200], Jason A. Donenfeld wrote:
> On Fri, Jun 16, 2017 at 4:35 PM, Sebastian Andrzej Siewior
> wrote:
> > I wouldn't just push the lock one up as is but move that write part to
> > crng_init to remain within the locked section. Like that:
>
On 2017-06-19 22:55:37 [+0200], Jason A. Donenfeld wrote:
> On Mon, Jun 19, 2017 at 9:45 AM, Sebastian Andrzej Siewior
> wrote:
> > ehm. You sure? I simply delayed the lock-dropping _after_ the state
> > variable was been modified. So it was basically what your patch did
On Wed, Feb 22, 2012 at 09:10:46PM +0100, Nikos Mavrogiannopoulos wrote:
> On 02/22/2012 02:03 PM, Frank wrote:
>
> > Hi,
> >
> > After doing some trials with hardware crypto offloading through usermode
> > interfaces (af_alg and cryptodev) to Marvell CESA accelerated ciphers and
> > hash funct
[crypto/arc4.ko] undefined!
Signed-off-by: Sebastian Andrzej Siewior
---
On a side note: do we pull in the blkcipher block mode for each cipher now to
gain some extra performance like the openssl project? I was under the
impression that is in general not worth it.
crypto/Kconfig |2 +-
On Wed, Jun 27, 2012 at 02:52:47PM +0800, Herbert Xu wrote:
> > On a side note: do we pull in the blkcipher block mode for each cipher now
> > to
> > gain some extra performance like the openssl project? I was under the
> > impression that is in general not worth it.
>
> You mean normal block cip
without it:
|drivers/built-in.o:(.data+0x14588): undefined reference to
`crypto_ablkcipher_type'
|drivers/built-in.o:(.data+0x14668): undefined reference to
`crypto_ablkcipher_type'
Not sure when this broke.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/crypto/Kconfig |1
* James Hsiao | 2008-10-27 18:55:32 [-0700]:
>Kim suggest us submit this to linuxppc-dev for more review.
so do I
>>
>> diff --git a/arch/powerpc/boot/dts/kilauea.dts
>> b/arch/powerpc/boot/dts/kilauea.dts
>> index dececc4..58b48a0 100644
>> --- a/arch/powerpc/boot/dts/kilauea.dts
>> +++ b/arch/
a multiple of 4 or the vectors can not be used due to some other
limitations that I've overseen.
Signed-off-by: Sebastian Andrzej Siewior <[EMAIL PROTECTED]>
---
crypto/tcrypt.c | 24
crypto/testmgr.c | 27 +
crypto/testm
* Jeff Garzik | 2008-11-02 20:44:40 [-0500]:
> Sebastian Andrzej Siewior wrote:
>> I grabed them from http://www.schneier.com/skein.html. The last test
>> vector
>> (3) in every category is currently deactivated because it failed always.
>> It is unlikely that I made a
* Jeff Garzik | 2008-11-02 20:44:40 [-0500]:
> Sebastian Andrzej Siewior wrote:
>> I grabed them from http://www.schneier.com/skein.html. The last test
>> vector
>> (3) in every category is currently deactivated because it failed always.
>> It is unlikely that I made a
* Huang Ying | 2008-12-12 12:08:46 [+0800]:
>Add support to Intel AES-NI instructions for x86_64 platform.
>
>Intel AES-NI is a new set of Single Instruction Multiple Data (SIMD)
>instructions that are going to be introduced in the next generation of
>Intel processor, as of 2009. These instruction
* Huang Ying | 2008-12-15 10:19:02 [+0800]:
>> Nice work. A few things:
>> - Did you rename the "old" x86 functions to avoid a clash?
>> So you bypass the crypto layer in case you can't handle the operation.
>> Does this improve the performace or just saves key strokes? Not sure
>> what the
* Huang Ying | 2008-12-23 16:49:26 [+0800]:
>If aes_x86_64 and aes_generic are compiled as builtin, the
>initialization order is undetermined. That is, aes_x86_64 may be
>initilized before aes_generic is initilized, but aes_x86_64 depends on
>tables generated in aes_generic initialization code. ae
* Herbert Xu | 2008-12-24 15:48:51 [+1100]:
>On Wed, Dec 24, 2008 at 09:43:41AM +0800, Huang Ying wrote:
>>
>> I think that is not easy. Not all architecture follow the same directory
>> structure arch//crypto. And arch/x86/crypto is used by user mode
>> linux too.
>
>Right, relying on link order
* Herbert Xu | 2009-02-26 14:06:18 [+0800]:
>As algorithms requiring fallbacks are a special case, we can fix
>this by giving them a different module alias than the rest. Then
>it's just a matter of using the right aliases according to what
>algorithms we're trying to find.
Yup. I am not sure if
From: Sebastian Andrzej Siewior
This is my current status of an async crypto driver for the Orion5X crypto
unit. The driver uses the crypto accelerator. The data is copied via
memcpy() and will be replaced with idma once the infrastructure around
it is working. This patch depends on "arm/or
* Jason | 2009-03-03 12:49:37 [-0500]:
> I found the nuts and bolts starting at page 174 of [3], with registers
> listed starting on page 634.
they look the same to me. The registers seem to be on the same spot, the
description is the same from what I recall.
> thx,
>
> Jason.
Sebastian
--
To u
* Ronen Shitrit | 2009-03-04 18:05:12 [+0200]:
>However a SW calculation is also possible.
>Chapter 11.1.4 in [1] says, that the decrypt key is the last 16/24/32 bytes
>created by the expansion algorithm. So I picked the key expand routine
>from generic aes module and just passed the crypto test f
almost everything stays the same, we need just to use the extended registers
on the bit variant.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/crypto/Kconfig |2 +-
drivers/crypto/padlock-aes.c | 13 +
2 files changed, 14 insertions(+), 1 deletions(-)
diff --git
To enable the padlock unit, two msr bits have to flipped. This is allready
done in the 32bit path and is missing in the other. Instead of copy paste
the code, I merged the 64bit part into the 32bit part. The things that
changed during the merge:
- the fixups from x86_64 (family 6, model >= 15) were
there should be no difference, except
* the 64bit variant now also initializes the padlock unit.
* ->c_early_init() is executed again from ->c_init()
* the 64bit fixups made into 32bit path.
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/Kconfig.cpu
* Ingo Molnar | 2009-03-14 12:47:32 [+0100]:
>thanks, looks good. We can apply #1 to -tip just fine - but a
>drivers/crypto/ change should go via the crypto tree. Can the
>crypto tree apply #2 without having #1 right away? [i.e. will it
>still build and boot fine - even though the padlock
>fun
to crash cryptsetup with
luksOpen. Got look into this...
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/crypto/Kconfig |9 +
drivers/crypto/Makefile |1 +
drivers/crypto/mav_crypto.c | 724 +++
3 files changed, 734 insertions(+), 0
* Evgeniy Polyakov | 2009-03-18 01:42:43 [+0300]:
>Hi.
Hi Evgeniy,
>On Tue, Mar 17, 2009 at 10:58:44PM +0100, Sebastian Andrzej Siewior
>(arm-ker...@ml.breakpoint.cc) wrote:
>> +struct crypto_priv {
>
>Please use less generic names over the file.
will do.
>
* Herbert Xu | 2009-04-21 13:56:13 [+0800]:
>On Tue, Apr 21, 2009 at 01:53:31PM +0800, Herbert Xu wrote:
>>
>> Thanks for the report. This patch should fix the problem.
>
>In fact, padlock-aes shouldn't have been aes-all in the first
>place so I'm going to add tihs patch too.
You changed all alg
* Herbert Xu | 2009-04-21 18:53:27 [+0800]:
>It was already renamed in the original patch. The problem here
>is that padlock-aes was incorrectly renamed as it doesn't require
>a fallback.
Right, just key computation which is not part of the crypto API.
>Cheers,
>--
Sebastian
--
To unsubscribe
update since last post, unfortunately not much:
- interrupt handler fix
- s/mav/mv
the dm-crypt still crashes but a few delays seem to help argh
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/crypto/Kconfig |9 +
drivers/crypto/Makefile |1 +
drivers/crypto
* Harald Welte | 2009-05-10 14:33:37 [+0800]:
>Maybe it is too early during kernel startup to create a platform_device?
possible. without a trace and the hw atm I can't tell.
>Does anyone have an idea how to solve the problem? Is there a better method
>than a platform device?
I don't thing platfo
* Chuck Ebbert | 2009-06-09 10:35:33 [-0400]:
>The VIA Nano has a bug that makes the padlock unit fetch extra data
>during encryption operations. Add workarounds for that, and enable
>the driver on x86_64.
Nice. The X86_64 padlock will make it mainline in next merge window so
I'm asking you kindly
* Chuck Ebbert | 2009-06-09 10:39:07 [-0400]:
>From: Sebastian Andrzej Siewior
>crypto: padlock-aes: enable on 64-bit kernels
>
>The only required change now is using the right push/pop instruction
>on x86-64. Taken from the original patch by Sebastian Andrzej Siewior.
>(Add
* Ben Dooks | 2009-05-07 22:39:22 [+0100]:
Sorry for the late reply.
>> diff --git a/drivers/crypto/mv_crypto.c b/drivers/crypto/mv_crypto.c
>> new file mode 100644
>> index 000..40eb083
>> --- /dev/null
>> +++ b/drivers/crypto/mv_crypto.c
>> +struct req_progress {
>> +struct sg_mapping_
find the ARM tree
but I've rebased this patch against the orion tree [0].
Since the driver got renamed, I'm going to send a delta if nothing else
comes up.
[0] git://git.marvell.com/orion for-rmk
From: Sebastian Andrzej Siewior
Subject: [PATCH] arm/orion5x: increment window counte
From: Sebastian Andrzej Siewior
init & register the crypto device.
Signed-off-by: Sebastian Andrzej Siewior
---
arch/arm/mach-orion5x/common.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
index eaf
* Nicolas Pitre | 2009-06-11 16:36:42 [-0400]:
>> Adding a revision history is good thing... I could not find the ARM tree
>> but I've rebased this patch against the orion tree [0].
>
>Actually, I'm leaning towards the removal of such dynamic mappings
>altogether and keep an unconditional static
* Nicolas Pitre | 2009-06-11 17:19:22 [-0400]:
>> >What is your plan for this driver? Submit it now and add incremental
>> >improvements afterward or wait until it is more functional?
>> I would like to get it squeezed into this merge window unless there are
>> any objections and improve it afte
* Erik Lotspeich | 2009-06-16 11:47:15 [-0500]:
>Hi,
Hi,
>
>I have a question about the meaning of the error codes returned by the
>Linux kernel crypto API. In particular, I am interested in the codes
>returned by crypto_ablkcipher_encrypt() & crypto_ablkcipher_decrypt().
>I am receiving a retur
* Huang Ying | 2009-06-11 15:10:26 [+0800]:
>GHASH is implemented as a shash algorithm. The actual implementation
>is copied from gcm.c. This makes it possible to add
>architecture/hardware accelerated GHASH implementation.
>
>Signed-off-by: Huang Ying
>
>---
> crypto/Kconfig |7 +
> c
* Huang Ying | 2009-06-11 15:10:28 [+0800]:
>Remove the dedicated GHASH implementation in GCM, and uses the GHASH
>digest algorithm instead. This will make GCM uses hardware accelerated
>GHASH implementation automatically if available.
>
>ahash instead of shash interface is used, because some hard
* Huang Ying | 2009-06-18 10:08:27 [+0800]:
>On Thu, 2009-06-18 at 04:04 +0800, Sebastian Andrzej Siewior wrote:
>> >+#include
>> >+#include
>> >+#include
>> >+#include
>> >+#include
>> >+#include
>> >+#include
>> Do y
* Eric Sesterhenn | 2009-06-29 15:17:05 [+0200]:
>[ 122.967099] BUG: sleeping function called from invalid context at
>kernel/rwsem.c:21
>[ 122.967398] in_atomic(): 1, irqs_disabled(): 0, pid: 4926, name:
>modprobe
>[ 122.967643] INFO: lockdep is turned off.
>[ 122.967858] Pid: 4926, comm: mod
From: Sebastian Andrzej Siewior
the current code uses a mix of sping_lock() & spin_lock_irqsave(). This can
lead to deadlock with the correct timming & cprng_get_random() + cprng_reset()
sequence.
I've converted them to bottom half locks since all three user grab just a BH
lock
From: Sebastian Andrzej Siewior
As reported by Eric Sesterhenn the re-allocation of the cipher in reset leads
to:
|BUG: sleeping function called from invalid context at kernel/rwsem.c:21
|in_atomic(): 1, irqs_disabled(): 0, pid: 4926, name: modprobe
|INFO: lockdep is turned off.
|Pid: 4926, comm
* Sebastian Andrzej Siewior | 2009-06-29 23:45:08 [+0200]:
>From: Sebastian Andrzej Siewior
>
>As reported by Eric Sesterhenn the re-allocation of the cipher in reset leads
Neil, the patches are untested. Could you please verify them?
Sebastian
--
To unsubscribe from this list: send
the cipher, the state is resetted in
->setkey(). This patches makes the cipher allocation a one time thing and
moves it to init.
Reported-by: Eric Sesterhenn
Signed-off-by: Sebastian Andrzej Siewior
---
v2: - remove crypto_free_cipher() from reset
- don'r return 0 in error case in
* Neil Horman | 2009-06-30 20:06:48 [-0400]:
>I think this looks better, yeah, have you tested this? If not, give it a quick
>run please, and I'll ack it.
I've built it and started
| modprobe tcrypt mode=150
and I ended up with:
| alg: No test for stdrng (ansi_cprng)
So this should be fine I gue
* Neil Horman | 2009-07-01 11:52:19 [-0400]:
>Fix crypto testmgr reference to rng self tests.
>
>It seems the ansi_cprng self tests get skipped currently. It appears this is
>because the test name is "ansi_cprng", but the test is looked up by the
>cra_name
>value of the algorithm in question, an
* Sebastian Andrzej Siewior | 2009-07-02 08:02:55 [+0200]:
>* Neil Horman | 2009-07-01 11:52:19 [-0400]:
>
>>index f9bea9d..3315a38 100644
>>--- a/crypto/testmgr.c
>>+++ b/crypto/testmgr.c
>>@@ -1480,7 +1480,7 @@ static int alg_test_cprng(const struct alg_test_des
* Herbert Xu | 2009-07-02 16:32:59 [+0800]:
>--- a/crypto/testmgr.c
>+++ b/crypto/testmgr.c
>@@ -2365,14 +2366,22 @@ int alg_test(const char *driver, const char *alg, u32
>type, u32 mask)
> }
>
> i = alg_find_test(alg);
>- if (i < 0)
>+ j = alg_find_test(driver);
>+ if
* Herbert Xu | 2009-07-11 18:19:58 [+0800]:
>As I don't have the hardware supporting padlock-sha, could someone
>with access to it please test this for me? In particular, I'd like
>to see this tested with an actual IPsec connection.
I have here a via nano so I should be able to test it.
Do you ha
* Herbert Xu | 2009-07-15 08:48:47 [+0800]:
>Yes, that should be enough. You don't even ipsec-tools, just
>a manual SA setup with ip xfrm should be good enough.
I did not get that far:
|alg: hash: Chunking test 1 failed for sha1-padlock
|: e9 95 22 0c 1b d1 0f 5f f1 fa ee 74 7d 27 cd b2
* Herbert Xu | 2009-07-16 10:34:13 [+0800]:
>On Thu, Jul 16, 2009 at 10:16:01AM +0800, Herbert Xu wrote:
>>
>> Can you please pull my tree again? There were quite a few bugs
>> that I fixed last night.
>
>Oh and please make sure you have this patch applied too:
It passes the testmgr with that pat
* Sebastian Andrzej Siewior | 2009-07-16 09:36:30 [+0200]:
>* Herbert Xu | 2009-07-16 10:34:13 [+0800]:
>
>>On Thu, Jul 16, 2009 at 10:16:01AM +0800, Herbert Xu wrote:
>>>
>>> Can you please pull my tree again? There were quite a few bugs
>>> that I fixed l
* Nico Erfurth | 2009-07-28 10:26:54 [+0200]:
> Does anybody have an idea how I could get the crashdump so I can send it to
> the list? If there is no other way I'll write it down next time.
If you have a serial port you could dump it there (console=ttyS0 in the
kernel command line).
Could you pl
* Nicolas Pitre | 2009-06-11 17:19:22 [-0400]:
>I have no problem with you submitting it now. It is not complete yet
>but what is there is plenty functional. However I'd prefer if you used
>the API based on sg_copy_buffer() which includes a call to
>flush_kernel_dcache_page() already for main
From: Sebastian Andrzej Siewior
This adds support for Marvell's Cryptographic Engines and Security
Accelerator (CESA) which can be found on a few SoC.
Tested with dm-crypt.
Signed-off-by: Sebastian Andrzej Siewior
---
* Nicolas Pitre | 2009-08-02 10:14:57 [-0400]:
>Please submit it wit
From: Sebastian Andrzej Siewior
This adds support for Marvell's Cryptographic Engines and Security
Accelerator (CESA) which can be found on a few SoC.
Tested with dm-crypt.
Acked-by: Nicolas Pitre
Signed-off-by: Sebastian Andrzej Siewior
---
v3..v4: change Kconfig help text & adde
* Milan Broz | 2009-08-05 15:09:59 [+0200]:
>There is apparently some problem in kernel, not sure if dm-crypt or crypto
>api one, This ARC4 configuration is allowed (no errors) but produces something
>more like random generator:-)
>
>one sector device:
># dmsetup create x --table "0 1 crypt arc4-c
* Milan Broz | 2009-08-06 09:46:59 [+0200]:
>yes, I understand why this happens. I do not want to use stream cipher,
>but apparently users will do that:-)
So once they discover that they have salsa20 in kernel they see another
problem.
>My question was why crypto allows this setting?
Well, WLAN i
* Randy Dunlap | 2009-08-27 12:34:01 [-0700]:
>> On 27/08/2009 Randy Dunlap wrote:
>> > On Tue, 25 Aug 2009 19:58:52 -0400 Celejar wrote:
>> >
>> > > I'm having a pretty bizarre problem with my kernel crypto
>> > > configuration. I need support for a bog standard LUKS (aes /
>> > > cbc-essiv:sha
* Sebastian Andrzej Siewior | 2009-08-28 10:00:56 [+0200]:
>>> the problem is not reproducible with a debian/unstable 2.6.30.6 kernel,
>>> even though it has cbc compiled as module as well. but if I recompile
>>> the same kernel sources with Celejars kernel .config, t
* Jonas Meurer | 2009-08-31 17:52:00 [+0200]:
>> Could someone please look at initramfs to figure out why those three
>> modules are not copied in this reduced setup?
>
>the reason is simply that no other crypto modules define depends on the
>listed ones:
Well yes, but aes cbc is placed in the new
* Jonas Meurer | 2009-09-01 02:51:20 [+0200]:
>as you already discovered, that's because the initramfs hook script for
>cryptroot adds some crypto modules manually in debian. currently these
>are dm-mod, dm-crypt, cbc, aes, sha256 and all the modules they depend
>on.
You could add something like
* Neil Horman | 2009-09-12 12:44:11 [-0400]:
>diff --git a/drivers/char/random.c b/drivers/char/random.c
>index d8a9255..6700248 100644
>--- a/drivers/char/random.c
>+++ b/drivers/char/random.c
>@@ -399,6 +399,12 @@ module_param(debug, bool, 0644);
> * storing entropy in an entropy pool.
> *
>
* Neil Horman | 2009-09-14 12:30:43 [-0400]:
>Ok, version 2 of the patch, taking comments into account
looks good.
Sebastian
--
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.
Signed-off-by: Sebastian Andrzej Siewior
---
* Frans Pop | 2009-09-16 16:01:34 [+0200]:
>Maybe it's a result of enabling the new config option CRYPTO_DEV_MV_CESA?
please don't blame my shiny new driver :)
Catalin: bisect leads to 8b592783a. I've renamed the macro in this
com
* avital sela | 2009-09-30 09:28:01 [+0200]:
>On Mon, Sep 28, 2009 at 5:31 PM, avital sela wrote:
>> Attached below is the source code for the sha driver.? Like I said
>> previously, if I add printk-s or delays in testmgr then the test passes and
>> all subsequent sha1 crypto operations are suc
* ?? ??? | 2009-10-20 18:28:34 [+0400]:
>Dear all, I have a couple of questions about crypto internals, please
>help me to understand some concepts. My drivers implements
>CRYPTO_ALG_TYPE_BLKCIPHER algorithm and has to perform encryption via
>DMA transfers.
In the end you might prefer to u
* Sergey Mironov | 2009-11-10 17:00:31 [+0300]:
> 116 static int geode_setkey_cip(struct crypto_tfm *tfm, const u8 *key,
> 117 unsigned int len)
> 118 {
>...
>
>/** BUG? Should it be 'op->fallback.cip' instead of 'op->fallback.blk' ? **/
>
> 138 op->fallback.blk->base.crt_
* Sergey Mironov | 2009-11-12 11:36:42 [+0300]:
>From 0a61b446585324a3041ef0a138515ef936a14eb7 Mon Sep 17 00:00:00 2001
>From: Sergey Mironov
>Date: Thu, 12 Nov 2009 11:30:02 +0300
>Subject: [PATCH] Fixed typo bugs in geod-aes.c
>
>
>Signed-off-by: Sergey Mironov
Acked-
* Sergey Mironov | 2009-11-12 11:43:20 [+0300]:
>I can't find any "s390" reference in my tree. Probably, i have not got
>this branch in my local copy.
If you want to fix this please look at arch/s390/crypto/aes_s390.c. That
is broken and I mixed it up in fallback_init_cip() as well :)
Sebastian
>From 0a61b446585324a3041ef0a138515ef936a14eb7 Mon Sep 17 00:00:00 2001
>From: Sergey Mironov
>Date: Thu, 12 Nov 2009 11:30:02 +0300
>Subject: [PATCH] Fixed typo bugs in geod-aes.c
On a second look could you please add something like:
crypto/geode: access fallback.cip cipher fallback mode
|The
>From 335b39e0c55a1dba13cda3e8222947f2cb4120ed Mon Sep 17 00:00:00 2001
>From: Sergey Mironov
>Date: Thu, 12 Nov 2009 13:10:05 +0300
>Subject: [PATCH 2/2] aes_s390: access fallback.cip cipher fallback mode
>
>|The fallback code in cipher mode touch the union fallback.blk instead
>|of fallback.cip.
* Roel Kluin | 2009-12-07 14:28:23 [+0100]:
>Return the PTR_ERR of the correct pointer.
>
>Signed-off-by: Roel Kluin
>---
> drivers/crypto/geode-aes.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
>diff --git a/drivers/crypto/geode-aes.c b/drivers/crypto/geode-aes.c
>index 480116
* Herbert Xu | 2009-12-11 23:03:49 [+0800]:
>On Mon, Dec 07, 2009 at 03:14:33PM +0100, Roel Kluin wrote:
>> Return the PTR_ERR of the correct pointer.
>>
>> Signed-off-by: Roel Kluin
>
>Patch applied. Thank you.
Martin picked an earlier version of this patch [0] which is allready in
Linus' tre
how any side effects yet because both types /
structs contain the same element right now.
[bige...@breakpoint: different commit message, split the patch in two and
rebase ]
Signed-off-by: Roel Kluin
Signed-off-by: Sebastian Andrzej Siewior
---
arch/s390/crypto/aes_s390.c |
how any side effects yet because both types /
structs contain the same element right now.
[bige...@breakpoint: different commit message, split the patch in two]
Signed-off-by: Roel Kluin
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/crypto/geode-aes.c |6 +++---
1 files changed
* Milan Broz | 2010-01-25 19:39:11 [+0100]:
>On 01/25/2010 07:29 PM, Mikulas Patocka wrote:
>> Hi
>>
>> When using arc4 to encrypt a block device, the resulting device is
>> unreliable. It reads garbage. That's because arc4 is a stream cipher, if
>> you write something, it advances its state an
* Mikulas Patocka | 2010-01-26 07:27:18 [-0500]:
>> yes, I think it is better.
>> (...and I just forgot to add that test to dm-crypt after that suggestion.)
>>
>> Milan
>
>Hmm, there is salsa20 that has block size 1, larger initialization
>vectors, and can be used to encrypt disks (although sals
* Roel Kluin | 2010-01-29 14:32:56 [+0100]:
>This was already discussed in december/januari but I still cannot find it in
>mainline, was it lost?
Isn't this patch [0] and [1] in Herbert's tree? If so Herbert is
probably going to merge in the next merge window because it is not
urgend enough.
[0]
* Bai Shuwei | 2010-01-28 17:12:46 [+0800]:
> When I add the hardware device driver for crypto, i get the bellow
>error information. My kernel is 2.6.26
>
>[ 319.938922] Call Trace:
>[ 319.938926] [] schedule+0x95/0x635
>[ 319.938934] [] :libfpga:fpga_dma_open+0xa5/0xab
>[ 319.938941] []
* Herbert Xu | 2010-02-09 18:37:18 [+1100]:
>Mikulas Patocka wrote:
>>
>> You should rather add a flag CRYPTO_ALG_CHANGES_STATE to determine that a
>> cipher can't be used to encrypt disks.
>
>No, please see my reply in the previous thread. What we should
>do is fix arc4. I just haven't got a
* Herbert Xu | 2010-02-10 07:45:19 [+1100]:
>> Herbert, what happend to the "check for streamcipher" idea you had? Is
>> it gone? On the other hand it wouldn't be probably that bad to have a
>
>Well again whether that should be done is up to the dm-crypt
>maintainers.
Milan liked that afaik.
>> s
* richih.mailingl...@gmail.com | 2010-02-10 02:17:39 [+0100]:
>From: Richard Hartmann
>
>
>Signed-off-by: Richard Hartmann
>---
> crypto/arc4.c |9 -
> 1 files changed, 4 insertions(+), 5 deletions(-)
I've made this whitespace fixes and a few others while re-writting it
yesterday. So
blkcipher itself,
I removed the select statement.
Signed-off-by: Sebastian Andrzej Siewior
---
I had it run with wireless and dm-crypt. No problems so far. Not sure if
it makes sense to rename it to arc4 and strip the ecb prefix. It would
make it consistent with salsa but would require another
* Adrian-Ken Rueegsegger | 2010-02-12 10:34:27 [+0100]:
>Hi,
Hi,
>Sebastian Andrzej Siewior schrieb:
>> The name is still ecb(aes) but since this is provided by the blkcipher
>> itself,
>Just to avoid any confusion you meant ecb(arc4) not ecb(aes) here right?
Yes, I do. N
* Sebastian Andrzej Siewior | 2010-02-12 09:42:28 [+0100]:
>+static void arc4_ivsetup(struct arc4_ctx *ctx, u8 *iv)
> {
>- struct arc4_ctx *ctx = crypto_tfm_ctx(tfm);
>+ if (unlikely(!ctx->new_key))
That should be likely(). Do you want me resend the whole thing?
* Herbert Xu | 2010-02-15 08:10:08 [+0800]:
>How about we just remove it? It's not on a hot path anyway.
Sure.
>I can do this when integrating the patch so you don't have to
>resend.
Okay, thanks.
>Thanks,
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
t
* Wang, Shane | 2010-02-21 13:32:49 [+0800]:
>--- a/crypto/vmac.cThu Feb 11 00:45:57 2010 -0800
>+++ b/crypto/vmac.cSun Feb 21 02:23:01 2010 -0800
>@@ -42,6 +42,8 @@ const u64 m63 = UINT64_C(0x7ff
> const u64 m63 = UINT64_C(0x7fff); /* 63-bit mask */
> const
* Herbert Xu | 2010-02-16 20:51:25 [+0800]:
>On Fri, Feb 12, 2010 at 09:42:28AM +0100, Sebastian Andrzej Siewior wrote:
>>
>> -static void arc4_crypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
>> +static void arc4_ivsetup(struct arc4_ctx *ctx, u8 *iv)
>> {
&
* Herbert Xu | 2010-02-22 08:52:17 [+0800]:
>On Mon, Feb 22, 2010 at 08:45:47AM +0800, Herbert Xu wrote:
>>
>> How about this? You extend the IV by one more byte, and use that
>> byte as a boolean flag to indicate whether the IV is valid. All
So I trick the crypto api to allocate more bytes than
kip.
the state has been moved from ctx into iv. That way encrypt()/decrypt() can
deliver the same result for a given IV. If the IV is supplied as a plain
key then it wil be converted into a different internal state.
The name is now arc4.
Signed-off-by: Sebastian Andrzej Siewior
1 - 100 of 172 matches
Mail list logo
