On Thu, Apr 23, 2015 at 02:27:36PM +0800, kbuild test robot wrote:
> tree:
> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
> head: 8a1a2b717e0d4d5f3e3bb59b7dee5079a15ab24b
> commit: 59afdc7b32143528524455039e7557a46b60e4c8 [42/56] crypto: api - Move
> module s
This patch adds documentation for Device-Tree bindings for the Security System
cryptographic accelerator driver.
Signed-off-by: LABBE Corentin
---
Documentation/devicetree/bindings/crypto/sunxi-ss.txt | 9 +
1 file changed, 9 insertions(+)
create mode 100644 Documentation/devicetree/bi
Add support for the Security System included in Allwinner SoC A20.
The Security System is a hardware cryptographic accelerator that support:
- MD5 and SHA1 hash algorithms
- AES block cipher in CBC/ECB mode with 128/196/256bits keys.
- DES and 3DES block cipher in CBC/ECB mode
Signed-off-by: LABBE
The Security System is a hardware cryptographic accelerator that support
AES/MD5/SHA1/DES/3DES/PRNG algorithms.
It could be found on many Allwinner SoC.
This patch enable the Security System on the Allwinner A20 SoC Device-tree.
Signed-off-by: LABBE Corentin
---
arch/arm/boot/dts/sun7i-a20.dtsi
Signed-off-by: LABBE Corentin
---
MAINTAINERS | 6 ++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index b4b131a..b678265 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -555,6 +555,12 @@ S: Maintained
F: Documentation/i2c/busses/i2c-ali1563
F: drivers/i2c/b
Hello
This is the driver for the Security System included in Allwinner SoC A20.
The Security System (SS for short) is a hardware cryptographic accelerator that
support AES/MD5/SHA1/DES/3DES/PRNG algorithms.
It could be found on others Allwinner SoC:
- A10, A10s, A13, A31 and A33 manual give the s
From: Herbert Xu
Date: Thu, 23 Apr 2015 11:26:20 +0800
> In order to fix this without breaking backwards compatibility,
> my plan is to introduce new templates such as rfc4106v2 which
> implement the RFC correctly. The existing templates will be
> retained so that current users aren't broken by
Hi:
It looks like our IPsec implementations of CCM and GCM are buggy
in that they don't include the IV in the authentication calculation.
This definitely breaks interoperability with anyone who implements
them correctly. The fact that there have been no reports on this
probably means that nobody
On Thu, Apr 23, 2015 at 04:51:56AM +0200, Stephan Mueller wrote:
>
> Encrypt input: IV, plaintext
>
> Encrypt output: processed IV, ciphertext
>
> Decrypt input: processed IV, ciphertext, IV to use for compare operation
>
> Decrypt output: plaintext
Actually it is
Decrypt input: processed IV,
Am Donnerstag, 23. April 2015, 09:46:09 schrieb Herbert Xu:
Hi Herbert,
> On Thu, Apr 23, 2015 at 03:39:11AM +0200, Stephan Mueller wrote:
> > The KW does not return an IV. The IV is used for encryption to stir the
> > encryption a bit. The resulting ciphertext now contains the mixed in IV.
> > F
On Thu, Apr 23, 2015 at 03:58:37AM +0200, Stephan Mueller wrote:
>
> So we have another memcpy just to copy that block into the IV field just to
> have the KW cipher implementation copy it to some other location again? I do
> not see the value of it.
But you already do that extra copy anyway:
+
Am Donnerstag, 23. April 2015, 09:46:09 schrieb Herbert Xu:
Hi Herbert,
> On Thu, Apr 23, 2015 at 03:39:11AM +0200, Stephan Mueller wrote:
> > The KW does not return an IV. The IV is used for encryption to stir the
> > encryption a bit. The resulting ciphertext now contains the mixed in IV.
> > F
On Thu, Apr 23, 2015 at 03:39:11AM +0200, Stephan Mueller wrote:
>
> The KW does not return an IV. The IV is used for encryption to stir the
> encryption a bit. The resulting ciphertext now contains the mixed in IV. For
> decryption, the IV is only used to verify that the one block in the
> decr
Am Donnerstag, 23. April 2015, 09:33:37 schrieb Herbert Xu:
Hi Herbert,
> On Wed, Apr 22, 2015 at 02:23:04PM +0200, Stephan Mueller wrote:
> > Isn't it a basic assumption to ablkcipher is that the ciphertext is equal
> > in size as the plaintext?
>
> Not necessarily since a blkcipher also output
Am Donnerstag, 23. April 2015, 09:39:28 schrieb Herbert Xu:
Hi Herbert,
> On Wed, Apr 22, 2015 at 02:44:08PM +0200, Stephan Mueller wrote:
> > > Where does this 8-byte alignment requirement come from?
> >
> > Well, I am accessing the data in 8-byte chunks. Moreover, in the
> > scatterwalk copy f
On Wed, Apr 22, 2015 at 02:44:08PM +0200, Stephan Mueller wrote:
>
> > Where does this 8-byte alignment requirement come from?
>
> Well, I am accessing the data in 8-byte chunks. Moreover, in the scatterwalk
> copy functions, I search through the scatterlists in 8 byte increments. If,
> say, a s
On Wed, Apr 22, 2015 at 04:11:08PM +0200, Stephan Mueller wrote:
>
> One more issue to consider: the key wrapping is an authenticated encryption /
> decryption. Thus, decryption can return EBADMSG, a feature a normal blkcipher
> does not do.
We currently have a givdecrypt function that's complet
On Wed, Apr 22, 2015 at 02:23:04PM +0200, Stephan Mueller wrote:
>
> Isn't it a basic assumption to ablkcipher is that the ciphertext is equal in
> size as the plaintext?
Not necessarily since a blkcipher also outputs IV which is exactly
what's happening in KW.
For the fixed IV value you could u
On Wed, Apr 22, 2015 at 02:33:03PM +0200, Stephan Mueller wrote:
>
> With this removal of crypto_proc_fips_* from crypto_*_proc, wouldn't you have
> broken the link from algapi.c? There, crypto_*_proc is called where now the
> FIPS logic may not be initialized any more.
This code does not provid
The CPU Jitter RNG provides a source of good entropy by
collecting CPU executing time jitter. The entropy in the CPU
execution time jitter is magnified by the CPU Jitter Random
Number Generator. The CPU Jitter Random Number Generator uses
the CPU execution timing jitter to generate a bit stream
whi
The async seeding operation is triggered during initalization right
after the first non-blocking seeding is completed. As required by the
asynchronous operation of random.c, a callback function is provided that
is triggered by random.c once entropy is available. That callback
function performs the
The kernel_pool is intended to be the in-kernel equivalent to the
blocking_pool, i.e. requests for random data may be blocked if
insufficient entropy is present.
The added API calls provide a synchronous function call
get_blocking_random_bytes where the caller is blocked.
In addition, an asynchro
In order to prepare for the addition of the asynchronous seeding call,
the invocation of seeding the DRBG is moved out into a helper function.
In addition, a block of memory is allocated during initialization time
that will be used as a scratchpad for obtaining entropy. That scratchpad
is used for
The kernel pool is intended to serve kernel-internal callers only.
Its purpose and usage is identical to the blocking_pool.
As the kernel_pool is not available to user space, user space cannot
directly interfere with the blocking behavior when obtaining
data from the kernel_pool. Thus, if entropy
Hi,
as of now, the DRBG is only seeded from get_random_bytes. In various
circumstances, the nonblocking_pool behind get_random_bytes may not be fully
seeded from hardware events at the time the DRBG requires to be seeded.
Based on the discussion in [1], the DRBG seeding is updated such that it
doe
During initialization, the DRBG now tries to allocate a handle of the
Jitter RNG. If such a Jitter RNG is available during seeding, the DRBG
pulls the required entropy/nonce string from get_random_bytes and
concatenates it with a string of equal size from the Jitter RNG. That
combined string is now
From: Herbert Xu
Date: Wed, 22 Apr 2015 15:04:55 +0800
> This series adds inclusions of aead.h to all AEAD users including
> AEAD implementors (where it's internal/aead.h). This is necessary
> because I'll be adding an updated AEAD interface and that will live
> in aead.h instead of crypto.h.
>
Am Mittwoch, 22. April 2015, 14:23:04 schrieb Stephan Mueller:
Hi,
> Am Mittwoch, 22. April 2015, 14:13:54 schrieb Herbert Xu:
>
> Hi Herbert,
>
> > On Wed, Apr 22, 2015 at 01:53:24PM +0800, Herbert Xu wrote:
> > > On Wed, Apr 22, 2015 at 06:36:59AM +0200, Stephan Mueller wrote:
> > > > The key
Am Mittwoch, 22. April 2015, 13:48:46 schrieb Herbert Xu:
Hi Herbert,
> On Wed, Apr 22, 2015 at 06:36:59AM +0200, Stephan Mueller wrote:
> > +static int crypto_kw_decrypt(struct aead_request *req)
> > +{
> > + struct crypto_aead *aead = crypto_aead_reqtfm(req);
> > + struct crypto_kw_ctx *ctx
Am Mittwoch, 22. April 2015, 13:02:22 schrieb Herbert Xu:
Hi Herbert,
> There is currently a large ifdef FIPS code section in proc.c.
> Ostensibly it's there because the fips_enabled sysctl sits under
> /proc/sys/crypto. However, no other crypto sysctls exist.
>
> In fact, the whole ethos of th
Am Mittwoch, 22. April 2015, 14:13:54 schrieb Herbert Xu:
Hi Herbert,
> On Wed, Apr 22, 2015 at 01:53:24PM +0800, Herbert Xu wrote:
> > On Wed, Apr 22, 2015 at 06:36:59AM +0200, Stephan Mueller wrote:
> > > The key wrapping is an authenticated encryption operation without
> > > associated data. T
On Wed, Apr 22, 2015 at 04:29:16PM +0930, Rusty Russell wrote:
> Herbert Xu writes:
> > Currently we're hiding mod->sig_ok under an ifdef in open code.
> > This patch adds a module_sig_ok accessor function and removes that
> > ifdef.
> >
> > Cc: Rusty Russell
> > Signed-off-by: Herbert Xu
>
Herbert Xu writes:
> Currently we're hiding mod->sig_ok under an ifdef in open code.
> This patch adds a module_sig_ok accessor function and removes that
> ifdef.
>
> Cc: Rusty Russell
> Signed-off-by: Herbert Xu
Did you want me to take this via modules-next? Assuming not.
So:
Ac
On Tue, Apr 21, 2015 at 04:43:35PM +0200, Stephan Mueller wrote:
>
> After updating to the current cryptodev-2.6 tree from today, this issue
> vanished.
I think you missed the thread where Linus's machine broke :)
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: ht
On Wed, 2015-04-22 at 15:04 +0800, Herbert Xu wrote:
> Hi:
>
> This series adds inclusions of aead.h to all AEAD users including
> AEAD implementors (where it's internal/aead.h). This is necessary
> because I'll be adding an updated AEAD interface and that will live
> in aead.h instead of crypto.
All users of AEAD should include crypto/aead.h instead of
include/linux/crypto.h.
Signed-off-by: Herbert Xu
---
crypto/testmgr.c |1 +
1 file changed, 1 insertion(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 18b7d49..d463978 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
All users of AEAD should include crypto/aead.h instead of
include/linux/crypto.h.
This patch also removes a bogus inclusion of algapi.h which should
only be used by algorithm/driver implementors and not crypto users.
Instead linux/crypto.h is added which is necessary because mac802154
also uses b
All users of AEAD should include crypto/aead.h instead of
include/linux/crypto.h.
Signed-off-by: Herbert Xu
---
crypto/tcrypt.c |1 +
1 file changed, 1 insertion(+)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index 22cdd61..2bff613 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -
All users of AEAD should include crypto/aead.h instead of
include/linux/crypto.h.
Signed-off-by: Herbert Xu
---
net/mac80211/aes_ccm.c |3 +--
net/mac80211/aes_gcm.c |3 +--
net/mac80211/aes_gmac.c |2 +-
3 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/net/mac80211/
All users of AEAD should include crypto/aead.h instead of
include/linux/crypto.h.
Signed-off-by: Herbert Xu
---
crypto/algif_aead.c |1 +
1 file changed, 1 insertion(+)
diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
index 00a6fe1..53702e9 100644
--- a/crypto/algif_aead.c
+++ b/cryp
All implementers of AEAD should include crypto/internal/aead.h
instead of include/linux/crypto.h.
Signed-off-by: Herbert Xu
---
arch/arm64/crypto/aes-ce-ccm-glue.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/crypto/aes-ce-ccm-glue.c
b/arch/arm64/crypto/aes
Hi:
This series adds inclusions of aead.h to all AEAD users including
AEAD implementors (where it's internal/aead.h). This is necessary
because I'll be adding an updated AEAD interface and that will live
in aead.h instead of crypto.h.
Dave, if it's OK with you I'd like to push the last two patch
42 matches
Mail list logo
