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 t
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 alway
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 cipher implementation.
In that case you should return an error if
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 = crypto_aead_ctx(aead);
> + struct crypto_cipher *tfm = ctx->child;
>
The header file internal.h is only meant for internal crypto API
implementors such as rng.c. So fips has no business in including
it.
This patch removes that inclusions and instead adds inclusions of
the actual features used by fips.
Signed-off-by: Herbert Xu
---
crypto/fips.c |5 -
1
All users of fips_enabled should include linux/fips.h directly
instead of getting it through internal.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 f9bce3d..18b7d49 100644
--- a/crypto/testmgr.c
All users of fips_enabled should include linux/fips.h directly
instead of getting it through internal.h which is reserved for
internal crypto API implementors.
Signed-off-by: Herbert Xu
---
crypto/tcrypt.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/tcrypt.c b/
Now that all fips_enabled users are including linux/fips.h directly
instead of getting it through internal.h, we can remove the fips.h
inclusions from internal.h.
Signed-off-by: Herbert Xu
---
crypto/internal.h |1 -
1 file changed, 1 deletion(-)
diff --git a/crypto/internal.h b/crypto/int
All users of fips_enabled should include linux/fips.h directly
instead of getting it through internal.h.
Signed-off-by: Herbert Xu
---
crypto/algapi.c |1 +
1 file changed, 1 insertion(+)
diff --git a/crypto/algapi.c b/crypto/algapi.c
index f835f43..c63836f 100644
--- a/crypto/algapi.c
+++
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 crypto API is against such user
interfaces so this patch moves all the FIPS sysc
For historical reasons internal.h currently includes fips.h and
a number of files depend on that to get access to fips_enabled.
This is suboptimal because internal.h is truly internal and should
only be used if you're implementing internal crypto API. That means
if you are an algorithm/driver aut
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 crypto API is against such user
interfaces so this patch moves all the FIPS
This patch implements the AES key wrapping as specified in
NIST SP800-38F and RFC3394.
The implementation covers key wrapping without padding. The caller may
provide an IV. If no IV is provided, the default IV defined in SP800-38F
is used for key wrapping and unwrapping.
The key wrapping is an au
Am Mittwoch, 22. April 2015, 11:42:35 schrieb Herbert Xu:
Hi Herbert,
> This patch removes the unnecessary CRYPTO_FIPS ifdef from
> drbg_healthcheck_sanity so that the code always gets checked
> by the compiler.
>
> Signed-off-by: Herbert Xu
Acked-by: Stephan Mueller
--
Ciao
Stephan
--
To u
On Wed, Apr 22, 2015 at 11:43:39AM +0800, kbuild test robot wrote:
> tree:
> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
> head: b617b702da4e922277806f81c411d3051107d462
> commit: acec27ff35af9caf34d76d16ee17ff3b292e7d83 [31/40] crypto: rng -
> Convert low-l
This patch removes the unnecessary CRYPTO_FIPS ifdef from
drbg_healthcheck_sanity so that the code always gets checked
by the compiler.
Signed-off-by: Herbert Xu
diff --git a/crypto/drbg.c b/crypto/drbg.c
index ec6bffd..23d444e 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1707,7 +1707,
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
diff --git a/crypto/algapi.c b/crypto/algapi.c
index 8057c9f..c63836f 100644
--- a/crypto/algapi.c
+++ b/cryp
The function crypto_ahash_init can also be asynchronous just
like update and final. So all callers must be able to handle
an async return.
Signed-off-by: Herbert Xu
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index 1a28001..bf41c34 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -8
Am Dienstag, 21. April 2015, 14:56:31 schrieb Stephan Mueller:
Hi Stephan,
> Am Dienstag, 21. April 2015, 14:35:47 schrieb Stephan Mueller:
>
> Hi Stephan,
>
> > Hi Herbert,
> >
> > I am currently working on the template for SP800-38F key wrapping. The
> > module is operational and calculates
Am Dienstag, 21. April 2015, 14:35:47 schrieb Stephan Mueller:
Hi Stephan,
> Hi Herbert,
>
> I am currently working on the template for SP800-38F key wrapping. The
> module is operational and calculates what I want.
>
> However, I have one problem I am having difficulties to track down and I am
Hi Herbert,
I am currently working on the template for SP800-38F key wrapping. The module
is operational and calculates what I want.
However, I have one problem I am having difficulties to track down and I am
wondering whether you could point me to the right direction.
When a caller calls
Am Dienstag, 21. April 2015, 10:44:36 schrieb Herbert Xu:
Hi Herbert,
> This series converts the crypto_rng interface over to the "new"
> style. I'm putting it in quotes because this style has been
> around since 2008. In fact, RNG was the very last interface
> type added before the introductio
On Tue, Apr 21, 2015 at 10:44:36AM +0800, Herbert Xu wrote:
> This series converts the crypto_rng interface over to the "new"
> style. I'm putting it in quotes because this style has been
> around since 2008. In fact, RNG was the very last interface
> type added before the introduction of the new
Hi Herbert/David,
I believe for accessing crypto from user-space irrespective underlying kernel
crypto - AF_ALG is one of the best method.
Can you tell me how can we verify the ARM64/Crypto with this(simple
test method with example)
and please provide me any other methods to verify the same from
On Tue, Apr 21, 2015 at 10:07:47AM +0200, Milan Broz wrote:
> First, from the cryptsetup log
> # Userspace crypto wrapper cannot use gost-xts-plain64 (-2).
> it seems that there is some problem with loading of your gost cipher
> implementation.
>
I relaunch the command into QEMU and I obtain "
On 04/21/2015 09:27 AM, jonathan.thieul...@gmail.com wrote:
> I'm implementing a new cipher block within the kernel and I'm stuck into a
> problem. My algorithm works pretty well, it can cipher and decipher a block.
> The
> algorithm also works with ECB, CBC, and CTR modes, however when I try to u
Hi,
I'm implementing a new cipher block within the kernel and I'm stuck into a
problem. My algorithm works pretty well, it can cipher and decipher a block. The
algorithm also works with ECB, CBC, and CTR modes, however when I try to use the
modes such as XTS or LRW I have the following errors whic
27 matches
Mail list logo
