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 the
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 wrapping is
From: Herbert Xu herb...@gondor.apana.org.au
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
On Wed, Apr 22, 2015 at 06:36:59AM +0200, Stephan Mueller wrote:
+ if (req-iv)
+ ret = crypto_memneq(block.A, req-iv, SEMIBSIZE);
+ else
+ ret = crypto_memneq(block.A, default_iv, SEMIBSIZE);
No we don't allow variable-sized IVs. Either you should always
have
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. Therefore, setting of AAD is permissible, but that data
is not used by the
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
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
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
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
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
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 provide
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 use
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: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 functions,
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 outputs 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.
For
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
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
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 completely
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:
+
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
From: Herbert Xu herb...@gondor.apana.org.au
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
All users of AEAD should include crypto/aead.h instead of
include/linux/crypto.h.
Signed-off-by: Herbert Xu herb...@gondor.apana.org.au
---
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(-)
All users of AEAD should include crypto/aead.h instead of
include/linux/crypto.h.
Signed-off-by: Herbert Xu herb...@gondor.apana.org.au
---
crypto/testmgr.c |1 +
1 file changed, 1 insertion(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 18b7d49..d463978 100644
---
All users of AEAD should include crypto/aead.h instead of
include/linux/crypto.h.
Signed-off-by: Herbert Xu herb...@gondor.apana.org.au
---
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
---
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
All users of AEAD should include crypto/aead.h instead of
include/linux/crypto.h.
Signed-off-by: Herbert Xu herb...@gondor.apana.org.au
---
crypto/tcrypt.c |1 +
1 file changed, 1 insertion(+)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index 22cdd61..2bff613 100644
---
All implementers of AEAD should include crypto/internal/aead.h
instead of include/linux/crypto.h.
Signed-off-by: Herbert Xu herb...@gondor.apana.org.au
---
arch/arm64/crypto/aes-ce-ccm-glue.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
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
Herbert Xu herb...@gondor.apana.org.au 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 ru...@rustcorp.com.au
Signed-off-by: Herbert Xu herb...@gondor.apana.org.au
Did you
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.h.
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 herb...@gondor.apana.org.au
Home Page:
On Wed, Apr 22, 2015 at 04:29:16PM +0930, Rusty Russell wrote:
Herbert Xu herb...@gondor.apana.org.au 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
36 matches
Mail list logo
