Did you get my email from last week?
Let me know if you have photos for cutting out or retouching?
We are an image team who can do editing for your the web store photos,
industry photos or portrait photos.
Send photos, we will do testing for you to check quality.
Waiting for your reply soon.
Th
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
In preparation for adding XChaCha12 support, rename/refactor
chacha20-generic to support different numbers of rounds. The
justification for needing XChaCha12 support is explained in more detail
in the patch "crypto: chacha - add XChaCha12 support".
The only difference between
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
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 an XChaCha20 implementation that is hooked up to the ARM NEON
implementation of ChaCha20. This is needed for use in the Adiantum
encryption mode; see the generic code patch,
"crypto: chacha20-generic - add XChaCha20 support", for more details.
We also update the NEON code
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} | 36
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 12 instead of 20.
XChaCha12 is faster than XC
From: Eric Biggers
Add support for the Adiantum encryption mode to fscrypt. Adiantum is a
tweakable, length-preserving encryption mode with security provably
reducible to that of XChaCha12 and AES-256, subject to a security bound.
It's also a true wide-block mode, unlike XTS. See the paper
"Adi
From: Eric Biggers
Expose a low-level Poly1305 API which implements the
ε-almost-∆-universal (εA∆U) hash function underlying the Poly1305 MAC
and supports block-aligned inputs only.
This is needed for Adiantum hashing, which builds an εA∆U hash function
from NH and a polynomial evaluation in GF(
From: Eric Biggers
Add an ARM NEON implementation of NHPoly1305, an ε-almost-∆-universal
hash function used in the Adiantum encryption mode. For now, only the
NH portion is actually NEON-accelerated; the Poly1305 part is less
performance-critical so is just implemented in C.
Signed-off-by: Eric
From: Eric Biggers
Add a generic implementation of NHPoly1305, an ε-almost-∆-universal hash
function used in the Adiantum encryption mode.
CONFIG_NHPOLY1305 is not selectable by itself since there won't be any
real reason to enable it without also enabling Adiantum support.
Signed-off-by: Eric
From: Eric Biggers
Add support for the Adiantum encryption mode. Adiantum was designed by
Paul Crowley and is specified by our paper:
Adiantum: length-preserving encryption for entry-level processors
(https://eprint.iacr.org/2018/720.pdf)
See our paper for full details; this patch only
Hello,
We've been working to find a way to bring storage encryption to
entry-level Android devices like the inexpensive "Android Go" devices
sold in developing countries, and some smartwatches. Unfortunately,
often these devices still ship with no encryption, since for cost
reasons they have to u
Hello, all:
I have a request to add this list to be archived at lore.kernel.org. For
that to happen, I need to collect a complete (or as complete as
possible) archive of previous messages. If you've been subscribed to
this list for a long time and have an mbox or maildir archive of
messages previo
Hi Leonard,
> -Original Message-
> From: Leonard Crestez
> Sent: Monday, October 15, 2018 9:28 PM
[...]
> Subject: [PATCH v2 0/4] Port mxs-dcp to imx6ull and imx6sll
>
> The DCP block is present on 6sll and 6ull but not enabled. The hardware is
> mostly compatible with 6sl, the only im
On Mon, Oct 15, 2018 at 10:28 AM Leonard Crestez
wrote:
>
> This block is present in 6sl, 6sll and 6ull so it should be enabled in
> the default imx kernel config.
>
> Signed-off-by: Leonard Crestez
Reviewed-by: Fabio Estevam
On Mon, Oct 15, 2018 at 10:28 AM Leonard Crestez
wrote:
> diff --git a/arch/arm/boot/dts/imx6ull.dtsi b/arch/arm/boot/dts/imx6ull.dtsi
> index 796ed35d4ac9..be610339e933 100644
> --- a/arch/arm/boot/dts/imx6ull.dtsi
> +++ b/arch/arm/boot/dts/imx6ull.dtsi
> @@ -37,10 +37,20 @@
>
On Mon, Oct 15, 2018 at 10:28 AM Leonard Crestez
wrote:
> + /* DCP clock is optional, only used on some SOCs */
> + sdcp->dcp_clk = devm_clk_get(dev, "dcp");
> + if (IS_ERR(sdcp->dcp_clk)) {
> + if (sdcp->dcp_clk != ERR_PTR(-ENOENT))
> + retur
On Mon, Oct 15, 2018 at 10:28 AM Leonard Crestez
wrote:
>
> Explicit clock enabling is required on 6sll and 6ull so mention that
> standard clock bindings are used.
>
> Signed-off-by: Leonard Crestez
Reviewed-by: Fabio Estevam
This block is present in 6sl, 6sll and 6ull so it should be enabled in
the default imx kernel config.
Signed-off-by: Leonard Crestez
---
arch/arm/configs/imx_v6_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig
b/arch/arm/configs/imx_v6_v7_def
Explicit clock enabling is required on 6sll and 6ull so mention that
standard clock bindings are used.
Signed-off-by: Leonard Crestez
---
Documentation/devicetree/bindings/crypto/fsl-dcp.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/crypto/fsl-dcp.tx
The DCP block on 6ull has no major differences other than requiring
explicit clock enabling.
Signed-off-by: Leonard Crestez
---
arch/arm/boot/dts/imx6ull.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/imx6ull.dtsi b/arch/arm/boot/dts/imx6ull.dtsi
index 796
On 6ull and 6sll the DCP block has a clock which needs to be explicitly
enabled.
Add minimal handling for this at probe/remove time.
Signed-off-by: Leonard Crestez
---
drivers/crypto/mxs-dcp.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/crypto/mxs-dcp.c b/dri
The DCP block is present on 6sll and 6ull but not enabled. The hardware is
mostly compatible with 6sl, the only important difference is that explicit
clock enabling is required.
There were several issues with the functionality of this driver (it didn't
even probe properly) but they are fixed in cr
On Thu, Oct 11, 2018 at 02:10:42PM +0300, Dan Carpenter wrote:
> Hello Corentin Labbe,
>
> The patch cac5818c25d0: "crypto: user - Implement a generic crypto
> statistics" from Sep 19, 2018, leads to the following static checker
> warning:
>
> crypto/crypto_user_stat.c:53 crypto_report_aead
26 matches
Mail list logo
