On Fri, 16 Nov 2018 at 17:29, Eric Biggers wrote:
>
> 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.o
On Fri, 16 Nov 2018 at 17:29, Eric Biggers wrote:
>
> 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
> perfor
On Fri, 16 Nov 2018 at 17:29, Eric Biggers wrote:
>
> 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
On Fri, 16 Nov 2018 at 17:29, Eric Biggers wrote:
>
> 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
On Fri, 16 Nov 2018 at 17:29, Eric Biggers wrote:
>
> From: Eric Biggers
>
> In preparation for exposing a low-level Poly1305 API which implements
> the ε-almost-∆-universal (εA∆U) hash function underlying the Poly1305
> MAC and supports block-aligned inputs only, create structures
> poly1305_key
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
chacha20-generic doesn't use SIMD instructions or otherwise disable
preemption, so passing atomic=true to skcipher_walk_virt() is
unnecessary.
Suggested-by: Ard Biesheuvel
Acked-by: Martin Willi
Signed-off-by: Eric Biggers
---
crypto/chacha20_generic.c | 2 +-
1 file chang
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
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
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
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
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 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
In preparation for exposing a low-level Poly1305 API which implements
the ε-almost-∆-universal (εA∆U) hash function underlying the Poly1305
MAC and supports block-aligned inputs only, create structures
poly1305_key and poly1305_state which hold the limbs of the Poly1305
"r" key
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. 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
From: Eric Biggers
In preparation for adding XChaCha12 support, rename/refactor the NEON
implementation of ChaCha20 to support different numbers of rounds.
Reviewed-by: Ard Biesheuvel
Signed-off-by: Eric Biggers
---
arch/arm/crypto/Makefile | 4 +-
...hacha20-neon-core.S
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
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
To improve responsivesess, disable preemption for each step of the walk
(which is at most PAGE_SIZE) rather than for the entire
encryption/decryption operation.
Suggested-by: Ard Biesheuvel
Signed-off-by: Eric Biggers
---
arch/arm/crypto/chacha20-neon-glue.c | 6 +++---
1 f
On Fri, 16 Nov 2018 at 16:17, Eric Biggers wrote:
>
> Hi Herbert,
>
> On Fri, Nov 16, 2018 at 02:02:27PM +0800, Herbert Xu wrote:
> > Hi Eric:
> >
> > On Mon, Nov 12, 2018 at 10:58:17AM -0800, Eric Biggers wrote:
> > >
> > > I prefer separate types so that the type system enforces that a key is
>
Hi Herbert,
On Fri, Nov 16, 2018 at 02:02:27PM +0800, Herbert Xu wrote:
> Hi Eric:
>
> On Mon, Nov 12, 2018 at 10:58:17AM -0800, Eric Biggers wrote:
> >
> > I prefer separate types so that the type system enforces that a key is never
> > accidentally used as an accumulator, and vice versa. Then
On Fri, Nov 16, 2018 at 02:18:54PM +0800, Herbert Xu wrote:
> On Wed, Nov 07, 2018 at 03:10:16PM +0800, Ryder Lee wrote:
> > This updates bindings for MT7629 RNG driver.
> >
> > Signed-off-by: Ryder Lee
>
> Who is meant to take this patch?
I've applied it.
Rob
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 with some easy tricks
> directly
> through cryptsetup/LUKS as well.
>
> I think we s
Add modsig support to the "sig" template field, allowing the the contents
of the modsig to be included in the measurement list.
Suggested-by: Mimi Zohar
Signed-off-by: Thiago Jung Bauermann
---
security/integrity/ima/ima.h | 7 +++
security/integrity/ima/ima_modsig.c | 1
If the IMA template contains the 'sig' field, then the modsig should be
added to the measurement list when the file is appraised, and that is what
normally happens.
But If a measurement rule caused a file containing a modsig to be measured
before a different rule causes it to be appraised, the res
Define new "d-sig" template field which holds the digest that is expected
to match the one contained in the modsig.
Suggested-by: Mimi Zohar
Signed-off-by: Thiago Jung Bauermann
---
Documentation/security/IMA-templates.rst | 5
security/integrity/ima/ima.h | 9 +++
secu
Introduce the modsig keyword to the IMA policy syntax to specify that
a given hook should expect the file to have the IMA signature appended
to it. Here is how it can be used in a rule:
appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig|modsig
With this rule, IMA will accept either a signature
Implement the appraise_type=imasig|modsig option, allowing IMA to read and
verify modsig signatures.
In case a file has both an xattr signature and an appended modsig, IMA will
only use the appended signature if the key used by the xattr signature
isn't present in the IMA keyring.
Signed-off-by:
With the introduction of another IMA signature type (modsig), some places
will need to check for both of them. It is cleaner to do that if there's a
helper function to tell whether an xattr_value represents an IMA
signature.
Suggested-by: Mimi Zohar
Signed-off-by: Thiago Jung Bauermann
---
secu
ima_read_modsig() will need it so that it can show an error message.
Signed-off-by: Thiago Jung Bauermann
---
security/integrity/ima/ima.h| 2 ++
security/integrity/ima/ima_policy.c | 12 ++--
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/security/integrity/ima/
This avoids a dependency cycle in soon-to-be-introduced
CONFIG_IMA_APPRAISE_MODSIG: it will select CONFIG_MODULE_SIG_FORMAT
which in turn selects CONFIG_KEYS. Kconfig then complains that
CONFIG_INTEGRITY_SIGNATURE depends on CONFIG_KEYS.
Signed-off-by: Thiago Jung Bauermann
Signed-off-by: Mimi Zo
IMA will only look for a modsig if the xattr sig references a key which is
not in the expected kernel keyring. To that end, introduce
asymmetric_sig_has_known_key().
The logic of extracting the key used in the xattr sig is factored out from
asymmetric_verify() so that it can be used by the new fun
IMA will need to obtain the keyring used to verify file signatures so that
it can verify the module-style signature appended to files.
Signed-off-by: Thiago Jung Bauermann
Signed-off-by: Mimi Zohar
---
security/integrity/digsig.c| 28 +---
security/integrity/integrit
Even though struct evm_ima_xattr_data includes a fixed-size array to hold a
SHA1 digest, most of the code ignores the array and uses the struct to mean
"type indicator followed by data of unspecified size" and tracks the real
size of what the struct represents in a separate length variable.
The on
IMA will need to verify a PKCS#7 which has already been parsed. For this
reason, factor out the code which does that from verify_pkcs7_signature()
into a new function which takes a struct pkcs7_message instead of a data
buffer.
In addition, IMA will need to know the key that signed a given PKCS#7
IMA will need to access the digest of the PKCS7 message (as calculated by
the kernel) before the signature is verified, so introduce
pkcs7_get_digest() for that purpose.
Also, modify pkcs7_digest() to detect when the digest was already
calculated so that it doesn't have to do redundant work. Verif
IMA will use the module_signature format for append signatures, so export
the relevant definitions and factor out the code which verifies that the
appended signature trailer is valid.
Also, create a CONFIG_MODULE_SIG_FORMAT option so that IMA can select it
and be able to use validate_module_sig()
Hello,
v8 is just a rebase on top of today's linux-integrity/next-integrity.
There aren't any noteworthy changes since v7, which is why I'm keeping its
description below:
The main difference in v7 is the addition of the last patch, which ensures
that there will always be a measurement entry conta
39 matches
Mail list logo
