On 21/01/2021 19:09, Ard Biesheuvel wrote:
> On Thu, 21 Jan 2021 at 19:05, Eric Biggers wrote:
>>
>> On Thu, Jan 21, 2021 at 02:07:33PM +0100, Ard Biesheuvel wrote:
>>> Salsa20 is not used anywhere in the kernel, is not suitable for disk
>>> encryption, and widely considered to have been supersede
On 23/12/2020 23:38, Ard Biesheuvel wrote:
> After applying my performance fixes for AES-NI in XTS mode, the only
> remaining users of the x86 glue helper module are the niche algorithms
> camellia, cast6, serpent and twofish.
>
> It is not clear from the history why all these different versions o
On 29/10/2020 11:05, Gilad Ben-Yossef wrote:
>
> +config CRYPTO_EBOIV
> + tristate "EBOIV support for block encryption"
> + default DM_CRYPT
> + select CRYPTO_CBC
> + help
> + Encrypted byte-offset initialization vector (EBOIV) is an IV
> + generation method that is us
On 27/10/2020 07:59, Gilad Ben-Yossef wrote:
> On Mon, Oct 26, 2020 at 9:04 PM Milan Broz wrote:
...
>> We had all of disk-IV inside dmcrypt before - but once it is partially moved
>> into crypto API
>> (ESSIV, EBOIV for now), it becomes much more complicated for user to sel
On 26/10/2020 19:39, Eric Biggers wrote:
> On Mon, Oct 26, 2020 at 07:29:57PM +0100, Milan Broz wrote:
>> On 26/10/2020 18:52, Eric Biggers wrote:
>>> On Mon, Oct 26, 2020 at 03:04:46PM +0200, Gilad Ben-Yossef wrote:
>>>> Replace the explicit EBOIV handling in
On 26/10/2020 18:52, Eric Biggers wrote:
> On Mon, Oct 26, 2020 at 03:04:46PM +0200, Gilad Ben-Yossef wrote:
>> Replace the explicit EBOIV handling in the dm-crypt driver with calls
>> into the crypto API, which now possesses the capability to perform
>> this processing within the crypto subsystem.
On 11/09/2020 18:30, Ard Biesheuvel wrote:
> (cc Milan and dm-devel)
>
> On Fri, 11 Sep 2020 at 19:24, Van Leeuwen, Pascal
> wrote:
>>
>>> -Original Message-
>>> From: linux-crypto-ow...@vger.kernel.org
>>> On Behalf Of Ard Biesheuvel
>>> Sent: Friday, September 11, 2020 4:11 PM
>>> To:
On 09/08/2019 08:31, Ard Biesheuvel wrote:
> Add support for the missing ciphertext stealing part of the XTS-AES
> specification, which permits inputs of any size >= the block size.
>
> Cc: Pascal van Leeuwen
> Cc: Ondrej Mosnacek
> Cc: Milan Broz
> Signed-off-by: Ard
On 08/08/2019 12:37, Ard Biesheuvel wrote:
>>> True. Which is another historical mistake imo, since XTS is only
>>> specified for AES, but I digress ... :-)
>>>
>> Yes, I was also surprised by the use of XTS with other blockciphers.
>> It sort of violates the don't roll your own crypto paradigm ...
Hi,
On 07/08/2019 23:13, Pascal Van Leeuwen wrote:
>> It is a bit confusing, but it is the only reasonable way to support
>> variably sized context and at the same time keep the whole request in
>> a single allocation.
Yes, and the reason here it was detected only for aesni_intel is that
it is su
On 07/08/2019 17:13, Pascal Van Leeuwen wrote:
Seems there is no mistake in your code, it is some bug in aesni_intel
implementation.
If I disable this module, it works as expected (with aes generic and
aes_i586).
>>> That's odd though, considering there is a dedicated xts
On 07/08/2019 13:27, Pascal Van Leeuwen wrote:
>> On 07/08/2019 10:15, Pascal Van Leeuwen wrote:
>>> I went through the code a couple of times, but I cannot spot any mistakes in
>>> the lengths I'm using. Is it possible that your application is supplying a
>>> buffer that is just not large enough?
Hi,
On 07/08/2019 10:15, Pascal Van Leeuwen wrote:
> I went through the code a couple of times, but I cannot spot any mistakes in
> the lengths I'm using. Is it possible that your application is supplying a
> buffer that is just not large enough?
Seems there is no mistake in your code, it is some
On 06/08/2019 08:55, Pascal van Leeuwen wrote:
> This adds support for Cipher Text Stealing for data blocks that are not an
> integer multiple of the cipher block size in size, bringing it fully in
> line with the IEEE P1619/D16 standard.
>
> This has been tested with the AES-XTS test vectors from
On 27/06/2019 09:42, Ard Biesheuvel wrote:
> On Wed, 26 Jun 2019 at 23:11, Samuel Neves wrote:
>>
>> , On Wed, Jun 26, 2019 at 8:40 AM Milan Broz wrote:
>>>
>>> On 26/06/2019 09:15, Ard Biesheuvel wrote:
>>>
>>>> Thanks for the insight.
On 26/06/2019 09:15, Ard Biesheuvel wrote:
> Thanks for the insight. So I guess we have consensus that MORUS should
> be removed. How about aegis128l and aegis256, which have been
> disregarded in favor of aegis128 by CAESAR (note that I sent an
> accelerated ARM/arm64 version of aegis128 based on
On 25/06/2019 20:37, Ard Biesheuvel wrote:
> On Tue, 25 Jun 2019 at 19:12, Eric Biggers wrote:
>>
>> [+Cc Milan]
I was discussing this with Ondra before he sent the reply, anyway comments
below:
>> On Tue, Jun 25, 2019 at 04:52:54PM +0200, Ard Biesheuvel wrote:
>>> MORUS was not selected as a w
Hi,
On 21/05/2019 12:00, Ondrej Mosnacek wrote:
> This patch adds new socket options to AF_ALG that allow setting key from
> kernel keyring. For simplicity, each keyring key type (logon, user,
> trusted, encrypted) has its own socket option name and the value is just
> the key description string t
On 25/05/2019 05:10, Eric Biggers wrote:
> On Tue, May 21, 2019 at 12:00:34PM +0200, Ondrej Mosnacek wrote:
>> This patch adds new socket options to AF_ALG that allow setting key from
>> kernel keyring. For simplicity, each keyring key type (logon, user,
>> trusted, encrypted) has its own socket op
: Milan Broz
---
crypto/testmgr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 0f684a414acb..82bc0398bbbf 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -2735,6 +2735,7 @@ static const struct alg_test_desc alg_test_descs
Hi,
On 19/11/2018 20:28, Eric Biggers wrote:
> Note that Adiantum benchmarks on x86 are misleading at the moment, since the
> initial kernel patchset doesn't include SSE2 and AVX2 optimized XChaCha and
> NHPoly1305. To start, only C and arm32 NEON implementations are included.
> Hence, on x86 Adi
On 16/11/2018 22:52, Eric Biggers wrote:
> Hi Milan,
>
> On Sat, Oct 20, 2018 at 12:26:20PM +0200, Milan Broz wrote:
>>
>> Adiantum (as in your current git branches on kernel.org) can be used for
>> dm-crypt
>> without any changes (yes, I played with it :) and w
On 19/10/2018 21:04, Eric Biggers wrote:
> Hi Jason,
>
> On Fri, Oct 19, 2018 at 05:58:35PM +0200, Jason A. Donenfeld wrote:
>> Hello Eric,
>>
>>> As before, some of these patches conflict with the new "Zinc" crypto
>>> library. But I don't know when Zinc will be merged, so for now I've
>>> conti
On 13/09/18 01:45, Andy Lutomirski wrote:
> On Wed, Sep 12, 2018 at 3:56 PM, Ard Biesheuvel
...
> b) Crypto that is used dynamically. This includes dm-crypt
> (aes-xts-plain64, aes-cbc-essiv, etc), all the ALG_IF interfaces, a
> lot of IPSEC stuff, possibly KCM, and probably many more. These wil
MORUS implementations")
> Signed-off-by: Ondrej Mosnacek
I tried this patch on x86_64 with AES-NI and also on system with
SSE but without AES-NI and it works as expected now
(module is loaded only on demand and optimized one is used if available).
If it is worth it, add
Tested-by: Milan
On 03/31/2018 07:30 PM, Gilad Ben-Yossef wrote:
...
>> Are there other crypto drivers doing this?
>
> I thought the exact same thing until I ran into a presentation about the s390
> secure keys implementation. I basically imitated their use (or abuse?)
> of the Crypto API
> assuming it is the way
Mike and others,
did anyone even try to run veritysetup tests?
We have verity-compat-test in our testsuite, is has even basic FEC tests
included.
We just added userspace verification of FEC RS codes to compare if kernel
behaves the same.
I tried to apply three last dm-verity patches from your
benchmark -c null
Signed-off-by: Milan Broz
---
crypto/testmgr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index f9c378af3907..5075e4d982ee 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -2875,6 +2875,7 @@ static const struct alg_test_desc
On 04/07/2017 12:47 PM, Binoy Jayan wrote:
> ===
> dm-crypt optimization for larger block sizes
> ===
...
> Tests with dd [direct i/o]
>
> Sequent
Patch below should be backported to 4.10 stable
(only 4.10, older kernels are ok).
We have reports some systems fail to boot from LUKS now
(missing ecb module in initramdisk) ...
Upstream commit is 12cb3a1c4184f891d965d1f39f8cfcc9ef617647
Thanks,
Milan
On 02/23/2017 08:38 AM, Milan Broz wrote
On 03/01/2017 02:04 PM, Milan Broz wrote:
> On 03/01/2017 01:42 PM, Gilad Ben-Yossef wrote:
> ...
>
>> I can certainly understand if you don't wont to take the patch until
>> we have results with
>> dm-crypt itself but the difference between 8 separate inv
On 03/01/2017 01:42 PM, Gilad Ben-Yossef wrote:
...
> I can certainly understand if you don't wont to take the patch until
> we have results with
> dm-crypt itself but the difference between 8 separate invocation of
> the engine for 512
> bytes of XTS and a single invocation for 4KB are pretty big
On 03/01/2017 09:30 AM, Gilad Ben-Yossef wrote:
> On Tue, Feb 28, 2017 at 11:05 PM, Milan Broz wrote:
>>
>> On 02/22/2017 07:12 AM, Binoy Jayan wrote:
>>>
>>> I was wondering if this is near to be ready for submission (apart from
>>> the testmgr.c
>
On 02/22/2017 07:12 AM, Binoy Jayan wrote:
>
> I was wondering if this is near to be ready for submission (apart from
> the testmgr.c
> changes) or I need to make some changes to make it similar to the IPSec
> offload?
I just tried this and except it registers the IV for every new device again,
Since the
commit f1c131b45410a202eb45cc55980a7a9e4e4b4f40
crypto: xts - Convert to skcipher
the XTS mode is based on ECB, so the mode must select
ECB otherwise it can fail to initialize.
Signed-off-by: Milan Broz
---
crypto/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a
On 02/22/2017 12:17 AM, Nicolas Porcel wrote:
> Hello,
>
> I am using aes-xts-plain64 with LUKS headers to crypt the root. In 4.10,
> the partition cannot be opened and I have the following errors when
> booting:
>
> device-mapper: table: 253:0: crypt: Error allocating crypto tfm
> device
gt;
> This can reduce performance per Watt in situations such as during
> boot time when a lot of concurrent file accesses are made to the
> protected volume.
>
> Move DM_VERITY to the asynchronous hash API.
>
> Signed-off-by: Gilad Ben-Yossef
> CC: Eric Biggers
On 02/06/2017 02:58 PM, Gilad Ben-Yossef wrote:
> Use of the synchronous digest API limits dm-verity to using pure
> CPU based algorithm providers and rules out the use of off CPU
> algorithm providers which are normally asynchronous by nature,
> potentially freeing CPU cycles.
>
> This can reduce
On 12/20/2016 10:41 AM, Binoy Jayan wrote:
> At a high level the goal is to maximize the size of data blocks that get
> passed
> to hardware accelerators, minimizing the overhead from setting up and tearing
> down operations in the hardware. Currently dm-crypt itself is a big blocker as
> it manua
t;buffer == walk->page, it appears to be the intention
>> that walk->buffer point to walk->page after skcipher_next_slow(), so
>> ensure that is the case.
>>
>> Signed-off-by: Ard Biesheuvel
>
> Patch applied. Thanks.
Fixed problem here as well...
Tested-by: Mila
On 12/13/2016 09:49 AM, Binoy Jayan wrote:
> Currently, the iv generation algorithms are implemented in dm-crypt.c.
> The goal is to move these algorithms from the dm layer to the kernel
> crypto layer by implementing them as template ciphers so they can be
> implemented in hardware for performance
On 05/27/2016 09:04 AM, Baolin Wang wrote:
> Hi Milan,
>
> On 27 May 2016 at 14:31, Milan Broz wrote:
>> On 05/25/2016 08:12 AM, Baolin Wang wrote:
>>> Now some cipher hardware engines prefer to handle bulk block rather than one
>>> sector (512 bytes) create
On 05/25/2016 08:12 AM, Baolin Wang wrote:
> Now some cipher hardware engines prefer to handle bulk block rather than one
> sector (512 bytes) created by dm-crypt, cause these cipher engines can handle
> the intermediate values (IV) by themselves in one bulk block. This means we
> can increase the
f discussion was
> relative to your proposal to train the dm-crypt target (which is
> bio-based) to also provide request-based support, see:
> https://www.redhat.com/archives/dm-devel/2015-November/msg00112.html
>
> But follow-up discussion occured, primarily with Milan Broz, which
On 04/18/2016 02:54 PM, Sasha Levin wrote:
> On 04/18/2016 05:48 AM, Thomas D. wrote:
>> Hi,
>>
>> Milan's patches apply against 3.18.30, however I am getting build errors:
>
> Milan, Herbert, should I just be reverting the offending patches:
>
> bcfa841 crypto: af_alg - Forbid bind(2) when nokey
On 03/01/2016 03:58 AM, Greg KH wrote:
> On Tue, Mar 01, 2016 at 01:32:05AM +, Eric Wheeler wrote:
>> Hello all,
>>
>> We updated from 4.1.17 to 4.1.18 (same .config) and now get the following
>> error when trying to open a LUKS volume. We've reverted to 4.1.17 and it
>> still works, so exce
On 02/27/2016 10:40 PM, Sasha Levin wrote:
> On 02/26/2016 06:44 AM, Milan Broz wrote:
>> From: Herbert Xu
>>
>> commit dd504589577d8e8e70f51f997ad487a4cb6c026f upstream.
>>
>> Some cipher implementations will crash if you try to use them
>> wi
From: Herbert Xu
commit d7b65aee1e7b4c87922b0232eaba56a8a143a4a0 upstream.
This patch removes the custom release parent function as the
generic af_alg_release_parent now works for nokey sockets too.
Cc: sta...@vger.kernel.org
Signed-off-by: Herbert Xu
---
crypto/algif_skci
n the socket yet.
Cc: sta...@vger.kernel.org
Reported-by: Dmitry Vyukov
Signed-off-by: Herbert Xu
Tested-by: Dmitry Vyukov
[backported to 4.1 by Milan Broz ]
---
crypto/algif_skcipher.c | 48 +---
1 file changed, 41 insertions(
From: Herbert Xu
commit a0fa2d037129a9849918a92d91b79ed6c7bd2818 upstream.
This patch adds a compatibility path to support old applications
that do acept(2) before setkey.
Cc: sta...@vger.kernel.org
Signed-off-by: Herbert Xu
---
crypto/algif_skcipher.c | 149 ++
From: Herbert Xu
commit 1822793a523e5d5730b19cc21160ff1717421bc8 upstream.
We need to lock the child socket in skcipher_check_key as otherwise
two simultaneous calls can cause the parent socket to be freed.
Cc: sta...@vger.kernel.org
Signed-off-by: Herbert Xu
---
crypto/al
On 02/24/2016 06:12 PM, Greg KH wrote:
> On Wed, Feb 24, 2016 at 09:54:48AM +0100, Milan Broz wrote:
>> On 02/24/2016 09:32 AM, Jiri Slaby wrote:
>>>> + af_alg_release_parent(sk);
>>>
>>> and this occurs to me like a double release?
>>
>> yes,
On 02/24/2016 09:32 AM, Jiri Slaby wrote:
>> +af_alg_release_parent(sk);
>
> and this occurs to me like a double release?
yes, my copy&paste mistake.
Anyway, there should be also two more patches from series.
If it helps, I copied proper backport here (upstream commit is referenced in
head
On 02/21/2016 05:40 PM, Milan Broz wrote:
> On 02/20/2016 03:33 PM, Thomas D. wrote:
>> Hi,
>>
>> FYI: v3.10.97, v3.14.61 and 3.18.27 are also affected.
>>
>> v4.3.6 works. Looks like the patch set is only compatible with >=linux-4.3.
>>
>> v3.12.
On 02/20/2016 03:33 PM, Thomas D. wrote:
> Hi,
>
> FYI: v3.10.97, v3.14.61 and 3.18.27 are also affected.
>
> v4.3.6 works. Looks like the patch set is only compatible with >=linux-4.3.
>
> v3.12.54 works because it doesn't contain the patch in question.
Hi,
indeed, because whoever backported
On 01/04/2016 05:35 AM, Herbert Xu wrote:
> On Sun, Jan 03, 2016 at 10:42:28AM +0100, Milan Broz wrote:
>>
>> yes, basically it prepares socket()/bind()/accept() and then it calls setkey
>> once.
>> (I'll try to fix in next releases to call setkey first thoug
On 01/03/2016 06:34 AM, Valdis Kletnieks wrote:
> So booting into a next-20151222 kernel, I can mount an external drive
> that uses cryptLuks. I try -1231, and I get this failure:
>
> Failed to setup dm-crypt key mapping for device /dev/sdb2.
> Check that kernel supports aes-cbc-essiv:sha256 ciph
On 01/03/2016 02:31 AM, Herbert Xu wrote:
> On Sat, Jan 02, 2016 at 09:18:30PM +0100, Milan Broz wrote:
>>
>> But I cannot change thousands of cryptsetup installations that are actively
>> using that code.
>> This is clear userspace breakage which should not happen thi
On 01/02/2016 09:03 PM, Stephan Mueller wrote:
> Am Samstag, 2. Januar 2016, 15:41:34 schrieb Milan Broz:
>
> Hi Milan,
>
...
>>> Hi Herbert,
>>>
>>> this patch breaks userspace in cryptsetup...
>>>
>>> We use algif_skcipher in cryptsetu
On 01/02/2016 12:52 PM, Milan Broz wrote:
> On 12/25/2015 08:40 AM, Herbert Xu wrote:
>> Dmitry Vyukov wrote:
>>>
>>> I am testing with your two patches:
>>> crypto: algif_skcipher - Use new skcipher interface
>>> crypto: algif_skcipher -
On 12/25/2015 08:40 AM, Herbert Xu wrote:
> Dmitry Vyukov wrote:
>>
>> I am testing with your two patches:
>> crypto: algif_skcipher - Use new skcipher interface
>> crypto: algif_skcipher - Require setkey before accept(2)
>> on top of a88164345b81292b55a8d4829fdd35c8d611cd7d (Dec 23).
>
> You sen
On 04/21/2015 09:27 AM, jonathan.thieul...@gmail.com wrote:
> I'm implementing a new cipher block within the kernel and I'm stuck into a
> problem. My algorithm works pretty well, it can cipher and decipher a block.
> The
> algorithm also works with ECB, CBC, and CTR modes, however when I try to u
On 03/02/2015 02:25 PM, Horia Geantă wrote:
> On 2/20/2015 7:00 PM, Martin Hicks wrote:
>> This adds the AES-XTS mode, supported by the Freescale SEC 3.3.2.
>>
>> One of the nice things about this hardware is that it knows how to deal
>> with encrypt/decrypt requests that are larger than sector siz
and aes-arm-bs module is used).
After applying this patch it works as expected.
I did not have time to check it more in detail (we are always encrypting
the whole sector so this should not happen... but apparently it does.)
Tested-by: Milan Broz
Thanks,
Milan
>
> Thanks,
> Ard.
&g
On 02/24/2015 12:02 AM, Johannes Ernst wrote:
> All in one place:
>
>> dd if=/dev/zero of=./test.img count=8 bs=1M
>
>> cryptsetup --hash sha512 --key-size 512 -v luksFormat ./test.img
> Used password ‘asdf’ (no quotes)
>
>> cryptsetup open test.img test
> Enter passphrase for test.img:
> No ke
On 02/23/2015 07:44 PM, Johannes Ernst wrote:
> 1. There was a (cryptic, to me) comment by one of the core Arch Linux
> ARM developers on my post. He said "Something on my mind about kernel
> mode neon on imx6, can't find it now”
> (http://archlinuxarm.org/forum/viewtopic.php?f=60&t=8489&p=45395#p4
On 09/04/2014 09:08 AM, Herbert Xu wrote:
> On Mon, Aug 25, 2014 at 11:49:54AM +0200, Ondrej Kozina wrote:
>> On archs with PAGE_SIZE >= 64 KiB the function skcipher_alloc_sgl()
>> fails with -ENOMEM no matter what user space actually requested.
>> This is caused by the fact sock_kmalloc call insid
On 09/07/2014 06:46 PM, Daniel Borkmann wrote:
> Recently, in commit 13aa93c70e71 ("random: add and use memzero_explicit()
> for clearing data"), we have found that GCC may optimize some memset()
> cases away when it detects a stack variable is not being used anymore
> and going out of scope. This
On 08/20/2014 03:25 PM, Jussi Kivilinna wrote:
>> One to four GB per second for XTS? 12 GB per second for AES CBC? Somehow
>> that
>> does not sound right.
>
> Agreed, those do not look correct... I wonder what happened there. On
> new run, I got more sane results:
Which cryptsetup version are
27;s label from the parent sock
and resolves the issue (similar to AF_BLUETOOTH protocol family).
Cc: sta...@vger.kernel.org
Signed-off-by: Milan Broz
---
crypto/af_alg.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index 966f893..6a3ad80 100644
--- a/
On 04/14/2013 06:12 PM, Milan Broz wrote:
> When user requests encryption (or decryption) of block which
> is not aligned to cipher block size through userspace crypto
> interface, an OOps like this can happen
And this is a reproducer for the problem above...
Milan
/*
* Check for
/0x90
[ 112.742578] [] sysenter_do_call+0x12/0x32
Patch fixes it by simply rejecting buffer which is not multiple of cipher block.
(Bug is present in all stable kernels as well.)
Signed-off-by: Milan Broz
---
crypto/algif_skcipher.c |2 +-
1 file changed, 1 insertion(+), 1 deletion
On 11/21/2012 12:29 PM, Zhang, Sonic wrote:
> Is there a policy that the CRC test vector
> in testmgr.h should support all CRC drivers?
> If so, I am fine to drop this test vector.
Question for Herbert...
But the problem I see is that it confuses people, it simply
returns fail everytime (except B
Hi,
commit a482b081a2d4d74d16bc9ea8779f9f6055f95852
Author: Sonic Zhang
Date: Fri May 25 17:54:13 2012 +0800
crypto: testmgr - Add new test cases for Blackfin CRC crypto driver
added tcrypt mode=110 test for hmac(crc32)
It seems, that this mode is only directly implemented by Blackfin
dri
managed by testmgr.
Signed-off-by: Milan Broz
---
crypto/testmgr.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 941d75c..02bc58f 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -2383,6 +2383,7 @@ static const struct alg_test_desc
rejecting buffer which is not multiple of cipher block.
Signed-off-by: Milan Broz
---
crypto/algif_skcipher.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index 6a6dfc0..5f7713b 100644
--- a/crypto/algif_skcipher.c
+++ b
On 09/24/2012 06:20 PM, Kasatkin, Dmitry wrote:
>> So it can provide confidentiality but it CANNOT provide integrity protection.
>>
> Yes, it provides confidentiality and via encryption it provides
> certain level of integrity protection.
> Data cannot be modified without being detected.
> Decryp
On 09/24/2012 11:55 AM, Dmitry Kasatkin wrote:
> Both dm-verity and dm-crypt provide block level integrity protection.
This is not correct. dm-crypt is transparent block encryption target,
where always size of plaintext == size of ciphertext.
So it can provide confidentiality but it CANNOT provid
ise system complains with
alg: No test for __cbc-aes-aesni (cryptd(__driver-cbc-aes-aesni))
alg: No test for __gcm-aes-aesni (cryptd(__driver-gcm-aes-aesni))
Signed-off-by: Milan Broz
Signed-off-by: Paul Wouters
---
crypto/testmgr.c | 38 ++
1 file changed, 38
kfree(new_key_mem) in rfc4106_set_key() should be called on malloced pointer,
not on aligned one, otherwise it can cause invalid pointer on free.
(Seen at least once when running tcrypt tests with debug kernel.)
Signed-off-by: Milan Broz
---
arch/x86/crypto/aesni-intel_glue.c |8
On 03/28/2012 10:42 PM, Dale Amon wrote:
So does anyone have a suggestion as to where I have
gone wrong? It's been over half a decade since I've
gone through this and even longer since I was doing
the magic dance with patching and building my own
losetup, mount, etc...
If you want something sim
On 05/07/2011 04:21 AM, Andrew Lutomirski wrote:
> I just moved my boot disk from an old machine to a new machine. The
> new machine has AES-NI and it failed to boot.
>
> The problem appears to be that aesni-intel, when loaded as a module,
> makes cryptsetup fail on an aes-xts-plain drive. The e
On 04/12/2010 12:52 AM, john terragon wrote:
> My system has a core i5 520M and supports AES-NI. I wanted to do a
> rude performance test and so I ran these commands on a small (4GB) partition
> and on the dm-crypt device backed by it:
>
> 1) using the aesni-intel module: dd if=/dev/dev/mapper/vo
On 02/06/2010 04:32 AM, Bai Shuwei wrote:
>I port the xts-aes algorithm to FPGA board and use it to
> encrypt/decrypt the disc. i will get the bellow information
>
>But when excute the bellow commands
>cryptsetup luksFormat -c aes-xts-plain -s 256 /dev/loop0
> or
>cryptsetup luk
On 01/27/2010 04:21 AM, Bai Shuwei wrote:
> On Tue, Jan 26, 2010 at 4:58 PM, Milan Broz wrote:
> I use "dmsetup table --showkeys" get the bellow information.
>
> disk$ sudo dmsetup table --showkeys /dev/mapper/dsi0
> 0
On 01/26/2010 10:22 AM, Sebastian Andrzej Siewior wrote:
> * Milan Broz | 2010-01-25 19:39:11 [+0100]:
>> On 01/25/2010 07:29 PM, Mikulas Patocka wrote:
>>> When using arc4 to encrypt a block device, the resulting device is
>>> unreliable. It reads garbage. That's
On 01/26/2010 09:41 AM, Bai Shuwei wrote:
> Hello, everyone:
> i add one line in the setkey function which is in xts.c file to
> print the in_key value. I find the key value not same i set in the
> keyfile by cryptsetup
>
>my command is
> # cryptsetup luksFormat -d my_keyfile -c xts-aes-
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 and if you attempt to decrypt
> the same sector, it
On 12/29/2009 10:21 AM, Richard Zidlicky wrote:
> On Mon, Dec 28, 2009 at 08:37:43PM +0100, Milan Broz wrote:
> While we are at it - are you aware of any documentation of the "mainline"
> dm-crypt
> implementation? I have not seen anything, much less any explanation if it
On 12/28/2009 07:59 PM, Max Vozeler wrote:
> The original code used cc->cipher for two things:
> @@ -1014,6 +1014,7 @@ static int crypt_ctr(struct dm_target *ti, unsigned int
> argc, char **argv)
> char *ivopts;
> unsigned int key_size;
> unsigned long long tmpll;
> + char c
Sebastian Andrzej Siewior wrote:
> Don't use this as a block cipher in dm-crypt, it is a bad idea.
>
> The long story:
> ARC4 is a stream cipher and not a block cipher. Its internal state is
> reseted in setkey() and every crypto request (encrypt/decrypt don't
> matter) update the internal state
Stelios Bounanos wrote:
> I was surprised to see arc4 perform so badly, particularly since
> "openssl speed" results tell a very different story. I decided to do
> some simple benchmarking of my own but I can't seem to get cryptsetup to
> work with arc4:
>
> # cryptsetup luksFormat --align-payl
Herbert Xu wrote:
> On Fri, Jul 31, 2009 at 10:54:45PM +0200, Michael Buesch wrote:
>> [15577.988608] NIP [c00b8034] .mempool_alloc+0x74/0x1a0
>> [15577.988614] LR [c0139bdc] .bio_alloc_bioset+0x4c/0x130
>> [15577.988616] Call Trace:
>> [15577.988619] [c001f022fb60] [c001f02
Melchior FRANZ wrote:
>
> umount ...
> cryptsetup remove ...
> losetup -d ...
>
> BUG: unable to handle kernel NULL pointer dereference at 0004
> IP: [] mempool_free+0xd/0x9a
...
Yes, I know about that problem and I am almost sure that
it is fixed by patch I sent there http://lkml.org/
Melchior FRANZ wrote:
> I was about to report an oops in the crypt module (NULL pointer
> dereferencing), but when I was half-way through entering the bug
> in bugzilla, I read that people with nvidia tainted kernels aren't
> supposed to file bug reports.
>
> So the bug is going to remain unfixed!
Herbert Xu wrote:
> On Fri, Feb 27, 2009 at 01:28:46PM +0100, Milan Broz wrote:
>> Like this?
>>
>> struct ablkcipher_request *req = (char *)dmreq - cc->dmreq_start;
>> mempool_free(req, cc->req_pool);
>
> Exactly. You could also embed the ablkciph
Herbert Xu wrote:
> On Fri, Feb 27, 2009 at 12:52:05PM +0100, Milan Broz wrote:
>> Herbert Xu wrote:
>>> On Fri, Feb 27, 2009 at 04:56:11PM +0800, Huang Ying wrote:
>>>> @@ -830,7 +838,7 @@ static void kcryptd_async_done(struct cr
>>>>ret
Herbert Xu wrote:
> On Fri, Feb 27, 2009 at 04:56:11PM +0800, Huang Ying wrote:
>> @@ -830,7 +838,7 @@ static void kcryptd_async_done(struct cr
>> return;
>> }
>>
>> -mempool_free(ablkcipher_request_cast(async_req), cc->req_pool);
>> +mempool_free(dmreq->req, cc->req_poo
Herbert Xu wrote:
> On Fri, Feb 27, 2009 at 01:31:56PM +0800, Huang Ying wrote:
>> I had ever heard from you that the only thing guaranteed in the
>> completion function of async ablkcipher cryption is the req->data has
>> the value you set before. The request pointer itself may be changed. But
>>
Andrew Morton wrote:
> (cc dm-devel)
>
> On Wed, 11 Feb 2009 17:27:42 +0100 Valentin QUEQUET
> wrote:
>
>> I've finally found why my computer seems to hang (pause) quite lengthy
>> when I boot Pristine Linux 2.6.29-rcX... instead of Pristine Linux
>> 2.6.28.4 (for example).
>>
>> The reason i
1 - 100 of 102 matches
Mail list logo
