On 7 August 2018 at 08:22, Jason A. Donenfeld wrote:
> These are unused, undesired, and have never actually been used by
> anybody. The original authors of this code have changed their mind about
> its inclusion. While originally proposed for disk encryption on low-end
> devices, the idea was disc
These are unused, undesired, and have never actually been used by
anybody. The original authors of this code have changed their mind about
its inclusion. While originally proposed for disk encryption on low-end
devices, the idea was discarded [1] in favor of something else before
that could really
On Mon, Aug 06, 2018 at 08:12:38PM -0700, Eric Biggers wrote:
> I mention this because people are naturally going to be curious about that,
> e.g.
> speculating that Google found a "backdoor" -- remember that we do have some
> good
> cryptographers! I'm just stating what we know, out of honesty
On Mon, Aug 06, 2018 at 10:38:23PM -0400, Jason A. Donenfeld wrote:
> On 8/6/18, Eric Biggers wrote:
> >
> > For context, in your commit message can you include a link to my email
> > mentioning Android's Speck decision
> > (https://marc.info/?l=linux-crypto-vger&m=153359499015659)?
>
> Sure.
>
On 8/6/18, Eric Biggers wrote:
>
> For context, in your commit message can you include a link to my email
> mentioning Android's Speck decision
> (https://marc.info/?l=linux-crypto-vger&m=153359499015659)?
Sure.
>
> Also: "speck" => "Speck".
Ack.
>
> Also I think the fscrypt code points should
Hi Jason,
On Tue, Aug 07, 2018 at 01:04:37AM +0200, Jason A. Donenfeld wrote:
> These are unused, undesired, and have never actually been used by
> anybody. The original authors of this code have changed their mind about
> its inclusion. Therefore, this patch removes it.
>
> Signed-off-by: Jason
We've done enough performance testing to know that the short answer
is: HPolyC is still a lot slower than I'm happy with, and encryption
still has a quite noticeable effect on the feel of low end devices.
Indeed, this proposal may change if I find a faster way to do the
first and last rounds. We do
On Mon, Aug 6, 2018 at 7:04 PM, Jason A. Donenfeld wrote:
> These are unused, undesired, and have never actually been used by
> anybody. The original authors of this code have changed their mind about
> its inclusion. Therefore, this patch removes it.
I think it may be unwise to completely discar
Hi Paul,
On 8/6/18, Paul Crowley wrote:
> Salsa20 was one of the earlier ARX proposals, and set a very
> conservative number of rounds as befits our state of knowledge at the
> time. Since then we've learned a lot more about cryptanalysis of such
> offerings, and I think we can be comfortable wit
Salsa20 was one of the earlier ARX proposals, and set a very
conservative number of rounds as befits our state of knowledge at the
time. Since then we've learned a lot more about cryptanalysis of such
offerings, and I think we can be comfortable with fewer rounds. The
best attack on ChaCha breaks 7
Hey Eric,
On Tue, Aug 7, 2018 at 12:35 AM Eric Biggers wrote:
> In preparation for adding XChaCha12 support, rename/refactor
> chacha20-generic to support different numbers of rounds.
I'm interested in learning the motivation behind going with ChaCha12.
So far, the vast majority of users of ChaC
These are unused, undesired, and have never actually been used by
anybody. The original authors of this code have changed their mind about
its inclusion. Therefore, this patch removes it.
Signed-off-by: Jason A. Donenfeld
Cc: sta...@vger.kernel.org
---
Documentation/filesystems/fscrypt.rst | 10
From: Eric Biggers
Hi all,
(Please note that this patchset is a true RFC, i.e. we're not ready for
it to be merged quite yet!)
It was officially decided to *not* allow Android devices to use Speck
encryption [1]. We've been working to find an alternative way to bring
storage encryption to entr
From: Eric Biggers
Refactor the unkeyed permutation part of chacha20_block() into its own
function, then add hchacha20_block() which is the ChaCha equivalent of
HSalsa20 and is an intermediate step towards XChaCha20 (see
https://cr.yp.to/snuffle/xsalsa-20081128.pdf). HChaCha20 skips the
final ad
From: Eric Biggers
In preparation for adding XChaCha12 support, rename/refactor the NEON
implementation of ChaCha20 to support different numbers of rounds.
Signed-off-by: Eric Biggers
---
arch/arm/crypto/Makefile | 4 +-
...hacha20-neon-core.S => chacha-neon-core.S} | 51
From: Eric Biggers
Add support for the XChaCha20 stream cipher. XChaCha20 is the
application of the XSalsa20 construction
(https://cr.yp.to/snuffle/xsalsa-20081128.pdf) to ChaCha20 rather than
to Salsa20. XChaCha20 extends ChaCha20's nonce length from 64 bits (or
96 bits, depending on conventio
From: Eric Biggers
Now that the 32-bit ARM NEON implementation of ChaCha20 and XChaCha20
has been refactored to support varying the number of rounds, add support
for XChaCha12. This is identical to XChaCha20 except for the number of
rounds, which is reduced from 20 to 12.
As I explained in more
From: Eric Biggers
Now that the generic implementation of ChaCha20 has been refactored to
allow varying the number of rounds, add support for XChaCha12, which is
the XSalsa construction applied to ChaCha12. ChaCha12 is one of the
three ciphers specified by the original ChaCha paper
(https://cr.y
From: Eric Biggers
Add the Poly1305 code from OpenSSL, which was written by Andy Polyakov.
I took the .S file from WireGuard, whose author has made the needed
tweaks for Linux kernel integration and verified that Andy had given
permission for GPLv2 distribution. I didn't make any additional chan
From: Eric Biggers
Add support for HPolyC, which is a tweakable, length-preserving
encryption mode that encrypts each message using XChaCha sandwiched
between two passes of Poly1305, and one invocation of a block cipher
such as AES. HPolyC was designed by Paul Crowley and is fully specified
by o
From: Eric Biggers
In preparation for adding XChaCha12 support, rename/refactor
chacha20-generic to support different numbers of rounds.
The only difference between ChaCha{8,12,20} are the number of rounds
itself; all other parts of the algorithm are the same. Therefore,
remove the "20" from al
From: Eric Biggers
Add an XChaCha20 implementation that is hooked up to the ARM NEON
implementation of ChaCha20. This is needed for use in the HPolyC
construction for disk/file encryption; see the generic code patch,
"crypto: chacha20-generic - add XChaCha20 support", for more details.
We also
Hello Jonathan Cameron,
The patch 915e4e8413da: "crypto: hisilicon - SEC security accelerator
driver" from Jul 23, 2018, leads to the following static checker
warning:
drivers/crypto/hisilicon/sec/sec_algs.c:865 sec_alg_skcipher_crypto()
error: double free of 'split_sizes'
driver
On Fri, Aug 3, 2018 at 6:44 AM, Lars Ellenberg
wrote:
> On Thu, Aug 02, 2018 at 04:43:19PM -0700, Kees Cook wrote:
>> On Tue, Jul 24, 2018 at 9:49 AM, Kees Cook wrote:
>> > In preparing to remove all stack VLA usage from the kernel[1], this
>> > removes the discouraged use of AHASH_REQUEST_ON_STA
On Mon, 6 Aug 2018 09:34:28 -0700
"Raj, Ashok" wrote:
> On Mon, Aug 06, 2018 at 09:49:40AM -0600, Alex Williamson wrote:
> > On Mon, 6 Aug 2018 09:40:04 +0800
> > Kenneth Lee wrote:
> > >
> > > 1. It supports thousands of processes. Take zip accelerator as an
> > > example, any
> > > applica
On Mon, Aug 06, 2018 at 09:49:40AM -0600, Alex Williamson wrote:
> On Mon, 6 Aug 2018 09:40:04 +0800
> Kenneth Lee wrote:
> >
> > 1. It supports thousands of processes. Take zip accelerator as an example,
> > any
> > application need data compression/decompression will need to interact with
> >
On Mon, 6 Aug 2018 09:40:04 +0800
Kenneth Lee wrote:
> On Thu, Aug 02, 2018 at 12:43:27PM -0600, Alex Williamson wrote:
> > Date: Thu, 2 Aug 2018 12:43:27 -0600
> > From: Alex Williamson
> > To: Cornelia Huck
> > CC: Kenneth Lee , "Tian, Kevin"
> > , Kenneth Lee , Jonathan Corbet
> > , Herber
On Mon, Aug 06, 2018 at 11:12:52AM +0800, Kenneth Lee wrote:
> On Fri, Aug 03, 2018 at 10:39:44AM -0400, Jerome Glisse wrote:
> > On Fri, Aug 03, 2018 at 11:47:21AM +0800, Kenneth Lee wrote:
> > > On Thu, Aug 02, 2018 at 10:22:43AM -0400, Jerome Glisse wrote:
> > > > On Thu, Aug 02, 2018 at 12:05:5
--
Hello
I am Craig Donaldson, the personal account office to our late customer
with our Bank Name Withheld for security reasons, a national of your
country, who used to work with Shell Oil - development company in here
in UK as a contractor.
On the 21st of April 2016, my client, his wife and th
IV generation is done only at AEAD level.
Support in ablkcipher is not needed, thus remove the dead code.
Link:
https://www.mail-archive.com/search?l=mid&q=20160901101257.ga3...@gondor.apana.org.au
Signed-off-by: Horia Geantă
---
drivers/crypto/caam/caamalg.c | 275 ++---
This patch set converts caam/jr and caam/qi top level drivers
from ablkcipher API to skcipher.
First two patches remove the unused ablkcipher algorithms with
support for IV generation.
The following two patches deal with the conversion.
Note: There is a dependency for the patch set - a fix sent s
Convert driver from deprecated ablkcipher API to skcipher.
Link:
https://www.mail-archive.com/search?l=mid&q=20170728085622.gc19...@gondor.apana.org.au
Signed-off-by: Horia Geantă
---
drivers/crypto/caam/caamalg.c | 12 +-
drivers/crypto/caam/caamalg_desc.c | 61 +++---
drivers/crypto/ca
Convert driver from deprecated ablkcipher API to skcipher.
Link:
https://www.mail-archive.com/search?l=mid&q=20170728085622.gc19...@gondor.apana.org.au
Signed-off-by: Horia Geantă
---
drivers/crypto/caam/caamalg.c | 448 +++---
drivers/crypto/caam/compat.h |
IV generation is done only at AEAD level.
Support in ablkcipher is not needed, thus remove the dead code.
Link:
https://www.mail-archive.com/search?l=mid&q=20160901101257.ga3...@gondor.apana.org.a
Signed-off-by: Horia Geantă
---
drivers/crypto/caam/caamalg_desc.c | 81
drivers/cry
Crypto engine needs some temporary locations in external memory for
running RSA decrypt forms 2 and 3 (CRT).
These are named "tmp1" and "tmp2" in the PDB.
Update DMA mapping direction of tmp1 and tmp2 from TO_DEVICE to
BIDIRECTIONAL, since engine needs r/w access.
Cc: # 4.13+
Fixes: 52e26d77b8b3
xts setkey callback returns 0 on some error paths.
Fix this by returning -EINVAL.
Cc: # 4.12+
Fixes: b189817cf789 ("crypto: caam/qi - add ablkcipher and authenc algorithms")
Signed-off-by: Horia Geantă
---
drivers/crypto/caam/caamalg_qi.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions
Descriptor address needs to be swapped to CPU endianness before being
DMA unmapped.
Cc: # 4.8+
Fixes: 261ea058f016 ("crypto: caam - handle core endianness != caam endianness")
Reported-by: Laurentiu Tudor
Signed-off-by: Horia Geantă
---
drivers/crypto/caam/jr.c | 3 ++-
1 file changed, 2 inser
Hi!
> WarpDrive is a common user space accelerator framework. Its main component
> in Kernel is called spimdev, Share Parent IOMMU Mediated Device. It exposes
spimdev is really unfortunate name. It looks like it has something to do with
SPI, but
it does not.
> +++ b/Documentation/warpdrive/war
Signed-off-by: Robert P. J. Day
---
diff --git a/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
b/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
index 5e2ba385b8c9..53e39d5f94e7 100644
--- a/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
+++ b/Documen
On Mon, Aug 06, 2018 at 04:45:34PM +0800, Yu Chen wrote:
> Hi Pavel,
> On Sun, Aug 05, 2018 at 12:02:00PM +0200, Pavel Machek wrote:
> > Hi!
> >
> > > > User space doesn't need to involve. The EFI root key is generated by
> > > > EFI boot stub and be transfer to kernel. It's stored in EFI boot ser
On 03/08/18 13:37, Ondrej Mosnacek wrote:
> It turns out I had misunderstood how the x86_match_cpu() function works.
> It evaluates a logical OR of the matching conditions, not logical AND.
> This caused the CPU feature checks for AEGIS to pass even if only SSE2
> (but not AES-NI) was supported (or
On Wednesday, July 25, 2018 8:01:47 PM CEST Kees Cook wrote:
> On Wed, Jul 25, 2018 at 4:32 AM, Rafael J. Wysocki wrote:
> > On Tue, Jul 24, 2018 at 6:49 PM, Kees Cook wrote:
> >> In the quest to remove all stack VLA usage from the kernel[1], this
> >> removes the discouraged use of AHASH_REQUEST
On Mo, 2018-08-06 at 15:57 +0800, Yu Chen wrote:
> Hi Oliver,
> On Thu, Jul 26, 2018 at 09:30:46AM +0200, Oliver Neukum wrote:
> > On Di, 2018-07-24 at 00:23 +0800, Yu Chen wrote:
> > >
> > > Good point, we once tried to generate key in kernel, but people
> > > suggest to generate key in userspace
On Mon, Aug 06, 2018 at 05:48:04PM +0800, joeyli wrote:
> On Mon, Aug 06, 2018 at 03:57:54PM +0800, Yu Chen wrote:
> > Hi Oliver,
> > On Thu, Jul 26, 2018 at 09:30:46AM +0200, Oliver Neukum wrote:
> > > On Di, 2018-07-24 at 00:23 +0800, Yu Chen wrote:
> > > >
> > > > Good point, we once tried to g
On Mon, Aug 06, 2018 at 03:57:54PM +0800, Yu Chen wrote:
> Hi Oliver,
> On Thu, Jul 26, 2018 at 09:30:46AM +0200, Oliver Neukum wrote:
> > On Di, 2018-07-24 at 00:23 +0800, Yu Chen wrote:
> > >
> > > Good point, we once tried to generate key in kernel, but people
> > > suggest to generate key in u
Hi Pavel,
On Sun, Aug 05, 2018 at 12:02:00PM +0200, Pavel Machek wrote:
> Hi!
>
> > > User space doesn't need to involve. The EFI root key is generated by
> > > EFI boot stub and be transfer to kernel. It's stored in EFI boot service
> > > variable that it can only be accessed by trusted EFI binar
Hi Oliver,
On Thu, Jul 26, 2018 at 09:30:46AM +0200, Oliver Neukum wrote:
> On Di, 2018-07-24 at 00:23 +0800, Yu Chen wrote:
> >
> > Good point, we once tried to generate key in kernel, but people
> > suggest to generate key in userspace and provide it to the
> > kernel, which is what ecryptfs do
47 matches
Mail list logo
