* Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices
From: Jason Cooper @ 2016-08-09 16:57 UTC (permalink / raw)
To: Herbert Xu; +Cc: Keith Packard, linux-crypto, linux-kernel
In-Reply-To: <20160809095058.GA6618@gondor.apana.org.au>
Hi Keith, Herbert,
On Tue, Aug 09, 2016 at 05:50:58PM +0800, Herbert Xu wrote:
> On Mon, Jul 25, 2016 at 01:07:35PM -0700, Keith Packard wrote:
> > Instead of having only one hwrng feeding /dev/random at a time, maintain
> > a list of devices and cycle between them when filling the entropy pool.
> >
> > Signed-off-by: Keith Packard <keithp@keithp.com>
>
> So you're cycling RNGs even for user-space reads? That could be
> problematic because not all hardware RNGs carry the maximum amount
> of entropy. It would be rather annoying to be cycling between
> RNGs of different qualities.
>
> Perhaps only cycle for the kernel hwrngd?
Perhaps a /dev/hwrng[0-9] per rng? That would lend itself nicely to a
sysfs interface for per device quality, rate, and enabled attributes.
e.g. /sys/class/hw_random/hwrng0/{device/,quality,rate,enabled}
/dev/hwrng could pull from the one with the highest quality, or user
specified for backwards compatibility.
thx,
Jason.
^ permalink raw reply
* FIPS mode: modprobe: ERROR: could not insert 'drbg'
From: Tapas Sarangi @ 2016-08-09 16:34 UTC (permalink / raw)
To: linux-crypto@vger.kernel.org
Hi Stephan,
Following up from the other thread:
While trying to boot in FIPS mode, kernel panics with the following
message. So far, I don¹t have success to get more information about which
module or symbol is causing this. I haven¹t found any errors or warnings
in kernel compilation. It boots fine in a non-fips mode.
I am also pasting the CRYPTO related configs that I have enabled (See
below).
-Tapas
/boot/vmlinuz-4.7.0-1.tos2_5: OK
modprobe: ERROR: could not insert 'drbg': Unknown symbol in module, or
unknown parameter (see dmesg)
[ 1.330798] dracut: FATAL: FIPS integrity test failed
[ 1.331534] dracut: Refusing to continue
[ 1.333491] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x00000100
[ 1.333491]
[ 1.334768] CPU: 0 PID: 1 Comm: init Not tainted 4.7.0-1.tos2_5 #1
[ 1.335632] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.8.2-20150714_191134- 04/01/2014
[ 1.336114] 0000000000000000 ffff88003e1dfbc8 ffffffff812ae299
0000000000000001
[ 1.336114] 0000000000000001 ffffffff81716b00 ffff88003e210000
ffff88003e1dfc48
[ 1.336114] ffffffff81104fd4 0000000000000010 ffff88003e1dfc58
ffff88003e1dfbf8
[ 1.336114] Call Trace:
[ 1.336114] [<ffffffff812ae299>] dump_stack+0x51/0x78
[ 1.336114] [<ffffffff81104fd4>] panic+0xc1/0x211
[ 1.336114] [<ffffffff81058781>] forget_original_parent+0x411/0x420
[ 1.336114] [<ffffffff810f4a12>] ? perf_pin_task_context+0x12/0x40
[ 1.336114] [<ffffffff810fcd52>] ? perf_event_exit_task+0x3b2/0x470
[ 1.336114] [<ffffffff81058cb6>] exit_notify+0x36/0x1e0
[ 1.336114] [<ffffffff810d4b61>] ? cgroup_exit+0x71/0xc0
[ 1.336114] [<ffffffff81070fdf>] ? task_work_run+0x5f/0x90
[ 1.336114] [<ffffffff8105a4ff>] do_exit+0x31f/0x640
[ 1.336114] [<ffffffff811726d9>] ? ____fput+0x9/0x10
[ 1.336114] [<ffffffff81070fdf>] ? task_work_run+0x5f/0x90
[ 1.336114] [<ffffffff81046d0e>] ? __do_page_fault+0x17e/0x450
[ 1.336114] [<ffffffff8105a869>] do_group_exit+0x49/0xb0
[ 1.336114] [<ffffffff8105a8e2>] SyS_exit_group+0x12/0x20
[ 1.336114] [<ffffffff8154dd9b>] entry_SYSCALL_64_fastpath+0x13/0x8f
[ 1.336114] Kernel Offset: disabled
[ 1.336114] ---[ end Kernel panic - not syncing: Attempted to kill
init! exitcode=0x00000100
[ 1.336114]
# Enabled CRYPTO configs
[root@localhost ~]# egrep 'CRYPTO.*=y|CRYPTO.*=m'
/boot/config-4.7.0-1.tos2_5
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_RT2X00_LIB_CRYPTO=y
CONFIG_CRYPTO=y
CONFIG_CRYPTO_FIPS=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=m
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_RNG_DEFAULT=m
CONFIG_CRYPTO_AKCIPHER2=y
CONFIG_CRYPTO_AKCIPHER=y
CONFIG_CRYPTO_RSA=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
CONFIG_CRYPTO_USER=m
CONFIG_CRYPTO_GF128MUL=m
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_NULL2=y
CONFIG_CRYPTO_PCRYPT=m
CONFIG_CRYPTO_WORKQUEUE=y
CONFIG_CRYPTO_CRYPTD=m
CONFIG_CRYPTO_MCRYPTD=m
CONFIG_CRYPTO_AUTHENC=m
CONFIG_CRYPTO_TEST=m
CONFIG_CRYPTO_ABLK_HELPER=m
CONFIG_CRYPTO_GLUE_HELPER_X86=m
CONFIG_CRYPTO_CCM=m
CONFIG_CRYPTO_GCM=m
CONFIG_CRYPTO_SEQIV=m
CONFIG_CRYPTO_ECHAINIV=m
CONFIG_CRYPTO_CBC=m
CONFIG_CRYPTO_CTR=m
CONFIG_CRYPTO_CTS=m
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_LRW=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_XTS=m
CONFIG_CRYPTO_CMAC=m
CONFIG_CRYPTO_HMAC=m
CONFIG_CRYPTO_XCBC=m
CONFIG_CRYPTO_VMAC=m
CONFIG_CRYPTO_CRC32C=y
CONFIG_CRYPTO_CRC32C_INTEL=m
CONFIG_CRYPTO_CRC32=m
CONFIG_CRYPTO_CRC32_PCLMUL=m
CONFIG_CRYPTO_CRCT10DIF=y
CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m
CONFIG_CRYPTO_GHASH=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_RMD128=m
CONFIG_CRYPTO_RMD160=m
CONFIG_CRYPTO_RMD256=m
CONFIG_CRYPTO_RMD320=m
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA1_SSSE3=m
CONFIG_CRYPTO_SHA256_SSSE3=m
CONFIG_CRYPTO_SHA512_SSSE3=m
CONFIG_CRYPTO_SHA1_MB=m
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_TGR192=m
CONFIG_CRYPTO_WP512=m
CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL=m
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_AES_X86_64=m
CONFIG_CRYPTO_AES_NI_INTEL=m
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_BLOWFISH_COMMON=m
CONFIG_CRYPTO_BLOWFISH_X86_64=m
CONFIG_CRYPTO_CAMELLIA=m
CONFIG_CRYPTO_CAMELLIA_X86_64=m
CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64=m
CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64=m
CONFIG_CRYPTO_CAST_COMMON=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST5_AVX_X86_64=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_CAST6_AVX_X86_64=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_DES3_EDE_X86_64=m
CONFIG_CRYPTO_FCRYPT=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_SALSA20=m
CONFIG_CRYPTO_SALSA20_X86_64=m
CONFIG_CRYPTO_SEED=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_SERPENT_SSE2_X86_64=m
CONFIG_CRYPTO_SERPENT_AVX_X86_64=m
CONFIG_CRYPTO_SERPENT_AVX2_X86_64=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_TWOFISH_COMMON=m
CONFIG_CRYPTO_TWOFISH_X86_64=m
CONFIG_CRYPTO_TWOFISH_X86_64_3WAY=m
CONFIG_CRYPTO_TWOFISH_AVX_X86_64=m
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_LZO=m
CONFIG_CRYPTO_LZ4=m
CONFIG_CRYPTO_LZ4HC=m
CONFIG_CRYPTO_ANSI_CPRNG=m
CONFIG_CRYPTO_DRBG_MENU=m
CONFIG_CRYPTO_DRBG_HMAC=y
CONFIG_CRYPTO_DRBG=m
CONFIG_CRYPTO_JITTERENTROPY=m
CONFIG_CRYPTO_USER_API=m
CONFIG_CRYPTO_USER_API_HASH=m
CONFIG_CRYPTO_USER_API_SKCIPHER=m
CONFIG_CRYPTO_HASH_INFO=y
CONFIG_CRYPTO_HW=y
CONFIG_CRYPTO_DEV_PADLOCK=m
CONFIG_CRYPTO_DEV_PADLOCK_AES=m
CONFIG_CRYPTO_DEV_PADLOCK_SHA=m
CONFIG_CRYPTO_DEV_CCP=y
CONFIG_CRYPTO_DEV_CCP_DD=m
CONFIG_CRYPTO_DEV_CCP_CRYPTO=m
CONFIG_CRYPTO_DEV_QAT=m
CONFIG_CRYPTO_DEV_QAT_DH895xCC=m
________________________________
This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
^ permalink raw reply
* Re: RSA key size not allowed in FIPS
From: Stephan Mueller @ 2016-08-09 16:08 UTC (permalink / raw)
To: Tapas Sarangi; +Cc: dhowells@redhat.com, linux-crypto@vger.kernel.org
In-Reply-To: <D3CF6958.28A9%tsarangi@trustwave.com>
Am Dienstag, 9. August 2016, 16:07:06 CEST schrieb Tapas Sarangi:
Hi Tapas,
> Hi Stephan,
>
>
> Thanks for your responses. I am past this error now.
>
> I am still NOT out of trouble. Now, test integrity fails while trying to
> get into FIPS mode. Here is the snippet of error messages. I will create
> a separate thread for this,
>
> /boot/vmlinuz-4.7.0-1.tos2_5: OK
> modprobe: ERROR: could not insert 'drbg': Unknown symbol in module, or
> unknown parameter (see dmesg)
Do you see which symbol is missing?
> [ 1.193406] dracut: FATAL: FIPS integrity test failed
> [ 1.194086] dracut: Refusing to continue
>
> [ 1.195820] Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x00000100
> [ 1.195820]
>
>
> -Tapas
>
>
>
> On 8/9/16, 10:00 AM, "Tapas Sarangi" <TSarangi@trustwave.com> wrote:
>
>
> >Embarrassing! Yes, I just saw this while you are pressing send on that
> >replyŠ default bits were set to 4096 in x509.genkey. :-(
> >
> >I am trying out with 2048 bits. I will confirm.
> >
> >-Tapas
> >
> >
> >On 8/9/16, 9:55 AM, "Stephan Mueller" <smueller@chronox.de> wrote:
> >
> >
> >>Am Dienstag, 9. August 2016, 14:39:03 CEST schrieb Tapas Sarangi:
> >>
> >>Hi Tapas, David,
> >>
> >>
> >>> Hi Stephan,
> >>>
> >>>
> >>>
> >>> If I understand this correctly, this (CONFIG_MODULE_SIG_HASH=³sha256")
> >>> tells about the key size used.
> >>> I am using ³sha256². Initially, I was using ³sha512² which I thought
> >>>
> >>>could
> >>>
> >>> be causing problem, but I am getting same error when change it to
> >>> ³sha256².
> >>>
> >>>
> >>>
> >>> [root@localhost ~]# grep MODULE_SIG /boot/config-4.7.0-1.tos2_5
> >>>
> >>>
> >>>
> >>> CONFIG_MODULE_SIG=y
> >>> # CONFIG_MODULE_SIG_FORCE is not set
> >>> CONFIG_MODULE_SIG_ALL=y
> >>> # CONFIG_MODULE_SIG_SHA1 is not set
> >>> # CONFIG_MODULE_SIG_SHA224 is not set
> >>> CONFIG_MODULE_SIG_SHA256=y
> >>> # CONFIG_MODULE_SIG_SHA384 is not set
> >>> # CONFIG_MODULE_SIG_SHA512 is not set
> >>> CONFIG_MODULE_SIG_HASH="sha256"
> >>> CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"
> >>
> >>
> >>It is rather the question how signing_key.pem is generated.
> >>
> >>Do you have the file certs/x509.genkey? If yes, what is the default_bits
> >>value?
> >>
> >>David, the x509.genkey file seems to generate a 4k RSA key per default.
> >>This
> >>will cause a panic with fips=1 as only 2k and 3k keys are allowed.
> >>
> >>Ciao
> >>Stephan
> >
> >
>
>
>
> ________________________________
>
> This transmission may contain information that is privileged, confidential,
> and/or exempt from disclosure under applicable law. If you are not the
> intended recipient, you are hereby notified that any disclosure, copying,
> distribution, or use of the information contained herein (including any
> reliance thereon) is strictly prohibited. If you received this transmission
> in error, please immediately contact the sender and destroy the material in
> its entirety, whether in electronic or hard copy format.
Ciao
Stephan
^ permalink raw reply
* Re: RSA key size not allowed in FIPS
From: Tapas Sarangi @ 2016-08-09 16:07 UTC (permalink / raw)
To: Stephan Mueller, dhowells@redhat.com; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <D3CF597F.289B%tsarangi@trustwave.com>
Hi Stephan,
Thanks for your responses. I am past this error now.
I am still NOT out of trouble. Now, test integrity fails while trying to
get into FIPS mode. Here is the snippet of error messages. I will create
a separate thread for this,
/boot/vmlinuz-4.7.0-1.tos2_5: OK
modprobe: ERROR: could not insert 'drbg': Unknown symbol in module, or
unknown parameter (see dmesg)
[ 1.193406] dracut: FATAL: FIPS integrity test failed
[ 1.194086] dracut: Refusing to continue
[ 1.195820] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x00000100
[ 1.195820]
-Tapas
On 8/9/16, 10:00 AM, "Tapas Sarangi" <TSarangi@trustwave.com> wrote:
>Embarrassing! Yes, I just saw this while you are pressing send on that
>replyŠ default bits were set to 4096 in x509.genkey. :-(
>
>I am trying out with 2048 bits. I will confirm.
>
>-Tapas
>
>
>On 8/9/16, 9:55 AM, "Stephan Mueller" <smueller@chronox.de> wrote:
>
>>Am Dienstag, 9. August 2016, 14:39:03 CEST schrieb Tapas Sarangi:
>>
>>Hi Tapas, David,
>>
>>> Hi Stephan,
>>>
>>> If I understand this correctly, this (CONFIG_MODULE_SIG_HASH=³sha256")
>>> tells about the key size used.
>>> I am using ³sha256². Initially, I was using ³sha512² which I thought
>>>could
>>> be causing problem, but I am getting same error when change it to
>>> ³sha256².
>>>
>>> [root@localhost ~]# grep MODULE_SIG /boot/config-4.7.0-1.tos2_5
>>>
>>> CONFIG_MODULE_SIG=y
>>> # CONFIG_MODULE_SIG_FORCE is not set
>>> CONFIG_MODULE_SIG_ALL=y
>>> # CONFIG_MODULE_SIG_SHA1 is not set
>>> # CONFIG_MODULE_SIG_SHA224 is not set
>>> CONFIG_MODULE_SIG_SHA256=y
>>> # CONFIG_MODULE_SIG_SHA384 is not set
>>> # CONFIG_MODULE_SIG_SHA512 is not set
>>> CONFIG_MODULE_SIG_HASH="sha256"
>>> CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"
>>
>>It is rather the question how signing_key.pem is generated.
>>
>>Do you have the file certs/x509.genkey? If yes, what is the default_bits
>>value?
>>
>>David, the x509.genkey file seems to generate a 4k RSA key per default.
>>This
>>will cause a panic with fips=1 as only 2k and 3k keys are allowed.
>>
>>Ciao
>>Stephan
>
________________________________
This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
^ permalink raw reply
* Re: RSA key size not allowed in FIPS
From: Tapas Sarangi @ 2016-08-09 15:00 UTC (permalink / raw)
To: Stephan Mueller, dhowells@redhat.com; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <21317106.O9C0GvNNQc@positron.chronox.de>
Embarrassing! Yes, I just saw this while you are pressing send on that
replyŠ default bits were set to 4096 in x509.genkey. :-(
I am trying out with 2048 bits. I will confirm.
-Tapas
On 8/9/16, 9:55 AM, "Stephan Mueller" <smueller@chronox.de> wrote:
>Am Dienstag, 9. August 2016, 14:39:03 CEST schrieb Tapas Sarangi:
>
>Hi Tapas, David,
>
>> Hi Stephan,
>>
>> If I understand this correctly, this (CONFIG_MODULE_SIG_HASH=³sha256")
>> tells about the key size used.
>> I am using ³sha256². Initially, I was using ³sha512² which I thought
>>could
>> be causing problem, but I am getting same error when change it to
>> ³sha256².
>>
>> [root@localhost ~]# grep MODULE_SIG /boot/config-4.7.0-1.tos2_5
>>
>> CONFIG_MODULE_SIG=y
>> # CONFIG_MODULE_SIG_FORCE is not set
>> CONFIG_MODULE_SIG_ALL=y
>> # CONFIG_MODULE_SIG_SHA1 is not set
>> # CONFIG_MODULE_SIG_SHA224 is not set
>> CONFIG_MODULE_SIG_SHA256=y
>> # CONFIG_MODULE_SIG_SHA384 is not set
>> # CONFIG_MODULE_SIG_SHA512 is not set
>> CONFIG_MODULE_SIG_HASH="sha256"
>> CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"
>
>It is rather the question how signing_key.pem is generated.
>
>Do you have the file certs/x509.genkey? If yes, what is the default_bits
>value?
>
>David, the x509.genkey file seems to generate a 4k RSA key per default.
>This
>will cause a panic with fips=1 as only 2k and 3k keys are allowed.
>
>Ciao
>Stephan
________________________________
This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
^ permalink raw reply
* Re: RSA key size not allowed in FIPS
From: Stephan Mueller @ 2016-08-09 14:55 UTC (permalink / raw)
To: Tapas Sarangi, dhowells; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <D3CF5455.2887%tsarangi@trustwave.com>
Am Dienstag, 9. August 2016, 14:39:03 CEST schrieb Tapas Sarangi:
Hi Tapas, David,
> Hi Stephan,
>
> If I understand this correctly, this (CONFIG_MODULE_SIG_HASH=“sha256")
> tells about the key size used.
> I am using “sha256”. Initially, I was using “sha512” which I thought could
> be causing problem, but I am getting same error when change it to
> “sha256”.
>
> [root@localhost ~]# grep MODULE_SIG /boot/config-4.7.0-1.tos2_5
>
> CONFIG_MODULE_SIG=y
> # CONFIG_MODULE_SIG_FORCE is not set
> CONFIG_MODULE_SIG_ALL=y
> # CONFIG_MODULE_SIG_SHA1 is not set
> # CONFIG_MODULE_SIG_SHA224 is not set
> CONFIG_MODULE_SIG_SHA256=y
> # CONFIG_MODULE_SIG_SHA384 is not set
> # CONFIG_MODULE_SIG_SHA512 is not set
> CONFIG_MODULE_SIG_HASH="sha256"
> CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"
It is rather the question how signing_key.pem is generated.
Do you have the file certs/x509.genkey? If yes, what is the default_bits
value?
David, the x509.genkey file seems to generate a 4k RSA key per default. This
will cause a panic with fips=1 as only 2k and 3k keys are allowed.
Ciao
Stephan
^ permalink raw reply
* Re: RSA key size not allowed in FIPS
From: Tapas Sarangi @ 2016-08-09 14:54 UTC (permalink / raw)
To: Stephan Mueller; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <D3CF5455.2887%tsarangi@trustwave.com>
Looking at the kernel compilation log, it seems to be generating a 4k
(4096 bits) private key, although I am specifying
CONFIG_MODULE_SIG_HASH=“sha256”. How can I generate RSA key that is within
2k-3k bits ?
Here is a snippet from the compilation log:
### Now generating an X.509 key pair to be used for signing modules.
###
### If this takes a long time, you might wish to run rngd in the
### background to keep the supply of entropy topped up. It
### needs to be run as root, and uses a hardware random
### number generator if one is available.
###
Generating a 4096 bit RSA private key
Thanks a lot.
-Tapas
On 8/9/16, 9:39 AM, "Tapas Sarangi" <TSarangi@trustwave.com> wrote:
>Hi Stephan,
>
>If I understand this correctly, this (CONFIG_MODULE_SIG_HASH=“sha256")
>tells about the key size used.
>I am using “sha256”. Initially, I was using “sha512” which I thought could
>be causing problem, but I am getting same error when change it to
>“sha256”.
>
>[root@localhost ~]# grep MODULE_SIG /boot/config-4.7.0-1.tos2_5
>
>CONFIG_MODULE_SIG=y
># CONFIG_MODULE_SIG_FORCE is not set
>CONFIG_MODULE_SIG_ALL=y
># CONFIG_MODULE_SIG_SHA1 is not set
># CONFIG_MODULE_SIG_SHA224 is not set
>CONFIG_MODULE_SIG_SHA256=y
># CONFIG_MODULE_SIG_SHA384 is not set
># CONFIG_MODULE_SIG_SHA512 is not set
>CONFIG_MODULE_SIG_HASH="sha256"
>CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"
>
>Thanks
>
>
>-Tapas
>
>
>On 8/9/16, 9:29 AM, "Stephan Mueller" <smueller@chronox.de> wrote:
>
>>Am Dienstag, 9. August 2016, 14:10:33 CEST schrieb Tapas Sarangi:
>>
>>Hi Tapas,
>>
>>> Hello,
>>>
>>> I am using vanilla kernel-4.7 source. It crashes with the following
>>>when
>>> booted with ³fips=1 boot=/dev/sda1² option at the kernel command line
>>> argument.
>>
>>The kernel only allows 2k and 3k RSA keys in FIPS mode. Please check your
>>RSA
>>key used for signatures.
>>
>> /* In FIPS mode only allow key size 2K & 3K */
>> if (n_sz != 256 && n_sz != 384) {
>> pr_err("RSA: key size not allowed in FIPS
>>mode\n");
>> return -EINVAL;
>> }
>>
>>Ciao
>>Stephan
>
________________________________
This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
^ permalink raw reply
* Re: RSA key size not allowed in FIPS
From: Tapas Sarangi @ 2016-08-09 14:39 UTC (permalink / raw)
To: Stephan Mueller; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <2825660.AnRQGUh0XD@tauon.atsec.com>
Hi Stephan,
If I understand this correctly, this (CONFIG_MODULE_SIG_HASH=“sha256")
tells about the key size used.
I am using “sha256”. Initially, I was using “sha512” which I thought could
be causing problem, but I am getting same error when change it to
“sha256”.
[root@localhost ~]# grep MODULE_SIG /boot/config-4.7.0-1.tos2_5
CONFIG_MODULE_SIG=y
# CONFIG_MODULE_SIG_FORCE is not set
CONFIG_MODULE_SIG_ALL=y
# CONFIG_MODULE_SIG_SHA1 is not set
# CONFIG_MODULE_SIG_SHA224 is not set
CONFIG_MODULE_SIG_SHA256=y
# CONFIG_MODULE_SIG_SHA384 is not set
# CONFIG_MODULE_SIG_SHA512 is not set
CONFIG_MODULE_SIG_HASH="sha256"
CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"
Thanks
-Tapas
On 8/9/16, 9:29 AM, "Stephan Mueller" <smueller@chronox.de> wrote:
>Am Dienstag, 9. August 2016, 14:10:33 CEST schrieb Tapas Sarangi:
>
>Hi Tapas,
>
>> Hello,
>>
>> I am using vanilla kernel-4.7 source. It crashes with the following when
>> booted with ³fips=1 boot=/dev/sda1² option at the kernel command line
>> argument.
>
>The kernel only allows 2k and 3k RSA keys in FIPS mode. Please check your
>RSA
>key used for signatures.
>
> /* In FIPS mode only allow key size 2K & 3K */
> if (n_sz != 256 && n_sz != 384) {
> pr_err("RSA: key size not allowed in FIPS
>mode\n");
> return -EINVAL;
> }
>
>Ciao
>Stephan
________________________________
This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
^ permalink raw reply
* Re: RSA key size not allowed in FIPS
From: Gary R Hook @ 2016-08-09 14:36 UTC (permalink / raw)
To: linux-crypto@vger.kernel.org
In-Reply-To: <D3CF4E8C.2883%tsarangi@trustwave.com>
On 08/09/2016 09:10 AM, Tapas Sarangi wrote:
> Ps : I could not send any attachment, is it possible to send attachment to
> this mailing list ?
Pretty sure that's frowned upon.
^ permalink raw reply
* Re: RSA key size not allowed in FIPS
From: Stephan Mueller @ 2016-08-09 14:29 UTC (permalink / raw)
To: Tapas Sarangi; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <D3CF4E8C.2883%tsarangi@trustwave.com>
Am Dienstag, 9. August 2016, 14:10:33 CEST schrieb Tapas Sarangi:
Hi Tapas,
> Hello,
>
> I am using vanilla kernel-4.7 source. It crashes with the following when
> booted with ³fips=1 boot=/dev/sda1² option at the kernel command line
> argument.
The kernel only allows 2k and 3k RSA keys in FIPS mode. Please check your RSA
key used for signatures.
/* In FIPS mode only allow key size 2K & 3K */
if (n_sz != 256 && n_sz != 384) {
pr_err("RSA: key size not allowed in FIPS mode\n");
return -EINVAL;
}
Ciao
Stephan
^ permalink raw reply
* RSA key size not allowed in FIPS
From: Tapas Sarangi @ 2016-08-09 14:10 UTC (permalink / raw)
To: linux-crypto@vger.kernel.org
Hello,
I am using vanilla kernel-4.7 source. It crashes with the following when
booted with ³fips=1 boot=/dev/sda1² option at the kernel command line
argument.
[ 0.642411] RSA: key size not allowed in FIPS mode
[ 0.643099] Problem loading in-kernel X.509 certificate (-22)
[ 0.800524] BUG: unable to handle kernel NULL pointer dereference at
0000000000000068
[ 0.803075] IP: [<ffffffff811e1ad7>] kernfs_find_ns+0x17/0xf0
[ 0.804111] PGD 0
[ 0.804111] Oops: 0000 [#1] SMP
[ 0.804111] Modules linked in:
[ 0.804111] CPU: 0 PID: 6 Comm: kworker/u2:0 Tainted: G W
4.7.0-1.tos2_5 #1
[ 0.804111] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.8.2-20150714_191134- 04/01/2014
[ 0.804111] Workqueue: events_unbound async_run_entry_fn
[ 0.804111] task: ffff88003e214100 ti: ffff88003e264000 task.ti:
ffff88003e264000
[ 0.804111] RIP: 0010:[<ffffffff811e1ad7>] [<ffffffff811e1ad7>]
kernfs_find_ns+0x17/0xf0
[ 0.804111] RSP: 0018:ffff88003e267868 EFLAGS: 00010282
[ 0.804111] RAX: ffff88003e214100 RBX: 0000000000000000 RCX:
ffff88003e264008
[ 0.804111] RDX: 0000000000000000 RSI: ffffffff8166bb80 RDI:
0000000000000000
[ 0.804111] RBP: ffff88003e267898 R08: 0000000000000000 R09:
ffffffff8166bb80
[ 0.804111] R10: 00000000000c6000 R11: 0000000000000001 R12:
ffffffff8166bb80
[ 0.804111] R13: 0000000000000000 R14: ffffffff8173048a R15:
ffff88003b17b1a0
[ 0.804111] FS: 0000000000000000(0000) GS:ffff88003fc00000(0000)
knlGS:0000000000000000
[ 0.804111] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 0.804111] CR2: 0000000000000068 CR3: 0000000001806000 CR4:
00000000000406f0
[ 0.804111] Stack:
[ 0.804111] ffff88003e267898 0000000000000000 ffff880000000001
0000000000000000
[ 0.804111] ffffffff8166bb80 0000000000000000 ffff88003e2678c8
ffffffff811e1e77
[ 0.804111] 0000000000000096 ffffffff81873d40 ffff88003b152828
0000000000000005
[ 0.804111] Call Trace:
[ 0.804111] [<ffffffff811e1e77>] kernfs_find_and_get_ns+0x37/0x60
[ 0.804111] [<ffffffff811e5c58>] sysfs_unmerge_group+0x18/0x60
[ 0.804111] [<ffffffff8139c187>] dpm_sysfs_remove+0x27/0x60
Thanks for any suggestion.
-Tapas
Ps : I could not send any attachment, is it possible to send attachment to
this mailing list ?
________________________________
This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
^ permalink raw reply
* Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy
From: Jason Cooper @ 2016-08-09 14:04 UTC (permalink / raw)
To: Theodore Ts'o, Pan, Miaoqing, Stephan Mueller,
Sepehrdad, Pouyan, herbert@gondor.apana.org.au,
linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
ath9k-devel, linux-wireless@vger.kernel.org,
ath9k-devel@lists.ath9k.org, Kalle Valo
In-Reply-To: <20160809115622.GG9515@thunk.org>
Hi Ted,
On Tue, Aug 09, 2016 at 07:56:22AM -0400, Theodore Ts'o wrote:
> On Tue, Aug 09, 2016 at 06:30:03AM +0000, Pan, Miaoqing wrote:
> > Agree with Jason's point, also understand Stephan's concern. The
> > date rate can be roughly estimated by 'cat /dev/random |rngtest -c
> > 1000', the average speed is 1111.294Kibits/s. I will sent the patch
> > to disable ath9k RNG by default.
>
> If the ATH9K is generating some random amount of data, but you don't
> know how random, and you're gathering it opportunistically --- for
> example, suppose a wireless driver gets the radio's signal strength
> through the normal course of its operation, and while there might not
> be that much randomness for someone who can observe the exact details
> of how the phone is positioned in the room --- but for which the
> analyst sitting in Fort Meade won't know whether or not the phone is
> on the desk, or in a knapsack under the table, the right interface to
> use is:
>
> void add_device_randomness(const void *buf, unsigned int size);
>
> This won't increase the entropy count, but if you have the bit of
> potential randomness "for free", you might as well contribute it to
> the entropy pool. If it turns out that the chip was manufactured in
> China, and the MSS has backdoored it out the wazoo, it won't do any
> harm --- where as using the hwrng framework would be disastrous.
Ok, I get that. However, we have Documentation/hw_random.txt saying:
This data is NOT CHECKED by any fitness tests, and could potentially be
bogus (if the hardware is faulty or has been tampered with). Data is
only output if the hardware "has-data" flag is set, but nevertheless a
security-conscious person would run fitness tests on the data before
assuming it is truly random.
Which I would read as "Don't assume 1 bit read from /dev/hwrng equals 1
bit of entropy." Which runs counter to Stephan's reading of the rngd
code.
And then we have drivers like timeriomem-rng.c that appear to be
spitting out the raw 32bit register value of $SOC's timer.
Thankfully, most hw_random drivers don't set the quality. So unless the
user sets the default_quality param, it's zero.
iiuc, Ted, you're saying using the hw_random framework would be
disasterous because despite most drivers having a default quality of 0,
rngd assumes 1 bit of entropy for every bit read?
thx,
Jason.
^ permalink raw reply
* Re: testmgr.h
From: Stephan Mueller @ 2016-08-09 13:31 UTC (permalink / raw)
To: Gary R Hook; +Cc: linux-crypto
In-Reply-To: <e1ec0bc6-59cf-22d7-f8fd-59a337393b6d@amd.com>
Am Dienstag, 9. August 2016, 08:21:43 CEST schrieb Gary R Hook:
Hi Gary,
> Q: Is there a policy (de facto or otherwise) on adding tests to testmgr.h?
> Two cases:
>
> 1) Tests from the NIST document(s) on various ciphers and hashes wherein
> we add to an existing set of tests? For example, 3DES ECB mode, or AES
> GCM? I suppose this question is really about, "how much is enough?"
>
> 2) Adding testing for a mode that has not heretofore been included? For
> example, 3DES CFB mode? Pretty sure the answer here is "yes".
>
> Over-arching concern: do we want to include official NIST test cases, or
> eschew them?
>
> There was no obvious reference to this (by way of grepping for testmgr)
> in any of the existing Documentation. That I could find. If I missed
> something, please excuse me.
It is always helpful to use test vectors that are created by some third
parties. These are NIST test vectors or test vectors in RFCs. In some cases,
vectors were created using OpenSSL.
Regarding the question how much: I can only answer to the FIPS 140-2
requirements: all tests that need to be there for FIPS 140-2 are there for
those with fips_allowed=1.
Ciao
Stephan
^ permalink raw reply
* testmgr.h
From: Gary R Hook @ 2016-08-09 13:21 UTC (permalink / raw)
To: linux-crypto
Q: Is there a policy (de facto or otherwise) on adding tests to testmgr.h?
Two cases:
1) Tests from the NIST document(s) on various ciphers and hashes wherein
we add to an existing set of tests? For example, 3DES ECB mode, or AES
GCM? I suppose this question is really about, "how much is enough?"
2) Adding testing for a mode that has not heretofore been included? For
example, 3DES CFB mode? Pretty sure the answer here is "yes".
Over-arching concern: do we want to include official NIST test cases, or
eschew them?
There was no obvious reference to this (by way of grepping for testmgr)
in any of the existing Documentation. That I could find. If I missed
something, please excuse me.
Thanks,
Gary
^ permalink raw reply
* [PATCH v5 3/4] crypto: kdf - SP800-108 Key Derivation Function
From: Stephan Mueller @ 2016-08-09 12:28 UTC (permalink / raw)
To: herbert; +Cc: mathew.j.martineau, dhowells, linux-crypto, keyrings
In-Reply-To: <2808589.gm6f519sFh@positron.chronox.de>
The SP800-108 compliant Key Derivation Function is implemented as a
random number generator considering that it behaves like a deterministic
RNG.
All three KDF types specified in SP800-108 are implemented.
The code comments provide details about how to invoke the different KDF
types.
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
crypto/kdf.c | 508 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 508 insertions(+)
create mode 100644 crypto/kdf.c
diff --git a/crypto/kdf.c b/crypto/kdf.c
new file mode 100644
index 0000000..6f9f082
--- /dev/null
+++ b/crypto/kdf.c
@@ -0,0 +1,508 @@
+/*
+ * Copyright (C) 2016, Stephan Mueller <smueller@chronox.de>
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ * notice, and the entire permission notice in its entirety,
+ * including the disclaimer of warranties.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * 3. The name of the author may not be used to endorse or promote
+ * products derived from this software without specific prior
+ * written permission.
+ *
+ * ALTERNATIVELY, this product may be distributed under the terms of
+ * the GNU General Public License, in which case the provisions of the GPL2
+ * are required INSTEAD OF the above restrictions. (This clause is
+ * necessary due to a potential bad interaction between the GPL and
+ * the restrictions contained in a BSD-style copyright.)
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, ALL OF
+ * WHICH ARE HEREBY DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
+ * OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
+ * BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
+ * USE OF THIS SOFTWARE, EVEN IF NOT ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ */
+
+/*
+ * For performing a KDF operation, the following input is required
+ * from the caller:
+ *
+ * * Keying material to be used to derive the new keys from
+ * (denoted as Ko in SP800-108)
+ * * Label -- a free form binary string
+ * * Context -- a free form binary string
+ *
+ * The KDF is implemented as a random number generator.
+ *
+ * The Ko keying material is to be provided with the initialization of the KDF
+ * "random number generator", i.e. with the crypto_rng_reset function.
+ *
+ * The Label and Context concatenated string is provided when obtaining random
+ * numbers, i.e. with the crypto_rng_generate function. The caller must format
+ * the free-form Label || Context input as deemed necessary for the given
+ * purpose. Note, SP800-108 mandates that the Label and Context are separated
+ * by a 0x00 byte, i.e. the caller shall provide the input as
+ * Label || 0x00 || Context when trying to be compliant to SP800-108. For
+ * the feedback KDF, an IV is required as documented below.
+ *
+ * Example without proper error handling:
+ * char *keying_material = "\x00\x11\x22\x33\x44\x55\x66\x77";
+ * char *label_context = "\xde\xad\xbe\xef\x00\xde\xad\xbe\xef";
+ * kdf = crypto_alloc_rng(name, 0, 0);
+ * crypto_rng_reset(kdf, keying_material, 8);
+ * crypto_rng_generate(kdf, label_context, 9, outbuf, outbuflen);
+ *
+ * NOTE: In-place cipher operations are not supported.
+ */
+
+#include <linux/module.h>
+#include <crypto/rng.h>
+#include <crypto/internal/rng.h>
+#include <crypto/hash.h>
+#include <crypto/internal/hash.h>
+
+struct crypto_kdf_ctx {
+ struct shash_desc shash;
+ char ctx[];
+};
+
+/* convert 32 bit integer into its string representation */
+static inline void crypto_kw_cpu_to_be32(u32 val, u8 *buf)
+{
+ __be32 *a = (__be32 *)buf;
+
+ *a = cpu_to_be32(val);
+}
+
+/*
+ * Implementation of the KDF in double pipeline iteration mode according with
+ * counter to SP800-108 section 5.3.
+ *
+ * The caller must provide Label || 0x00 || Context in src. This src pointer
+ * may also be NULL if the caller wishes not to provide anything.
+ */
+static int crypto_kdf_dpi_random(struct crypto_rng *rng,
+ const u8 *src, unsigned int slen,
+ u8 *dst, unsigned int dlen)
+{
+ struct crypto_kdf_ctx *ctx = crypto_tfm_ctx(crypto_rng_tfm(rng));
+ struct shash_desc *desc = &ctx->shash;
+ unsigned int h = crypto_shash_digestsize(desc->tfm);
+ unsigned int alignmask = crypto_shash_alignmask(desc->tfm);
+ int err = 0;
+ u8 *dst_orig = dst;
+ u8 Aiblock[h + alignmask];
+ u8 *Ai = PTR_ALIGN((u8 *)Aiblock, alignmask + 1);
+ u32 i = 1;
+ u8 iteration[sizeof(u32)];
+
+ memset(Ai, 0, h);
+
+ while (dlen) {
+ /* Calculate A(i) */
+ if (dst == dst_orig && src && slen)
+ /* 5.3 step 4 and 5.a */
+ err = crypto_shash_digest(desc, src, slen, Ai);
+ else
+ /* 5.3 step 5.a */
+ err = crypto_shash_digest(desc, Ai, h, Ai);
+ if (err)
+ goto err;
+
+ /* Calculate K(i) -- step 5.b */
+ err = crypto_shash_init(desc);
+ if (err)
+ goto err;
+
+ err = crypto_shash_update(desc, Ai, h);
+ if (err)
+ goto err;
+
+ crypto_kw_cpu_to_be32(i, iteration);
+ err = crypto_shash_update(desc, iteration, sizeof(u32));
+ if (err)
+ goto err;
+ if (src && slen) {
+ err = crypto_shash_update(desc, src, slen);
+ if (err)
+ goto err;
+ }
+
+ if (dlen < h) {
+ u8 tmpbuffer[h];
+
+ err = crypto_shash_final(desc, tmpbuffer);
+ if (err)
+ goto err;
+ memcpy(dst, tmpbuffer, dlen);
+ memzero_explicit(tmpbuffer, h);
+ goto ret;
+ } else {
+ err = crypto_shash_final(desc, dst);
+ if (err)
+ goto err;
+ dlen -= h;
+ dst += h;
+ i++;
+ }
+ }
+
+err:
+ memzero_explicit(dst_orig, dlen);
+ret:
+ memzero_explicit(Ai, h);
+ return err;
+}
+
+/*
+ * Implementation of the KDF in feedback mode with a non-NULL IV and with
+ * counter according to SP800-108 section 5.2. The IV is supplied with src
+ * and must be equal to the digestsize of the used cipher.
+ *
+ * In addition, the caller must provide Label || 0x00 || Context in src. This
+ * src pointer must not be NULL as the IV is required. The ultimate format of
+ * the src pointer is IV || Label || 0x00 || Context where the length of the
+ * IV is equal to the output size of the PRF.
+ */
+static int crypto_kdf_fb_random(struct crypto_rng *rng,
+ const u8 *src, unsigned int slen,
+ u8 *dst, unsigned int dlen)
+{
+ struct crypto_kdf_ctx *ctx = crypto_tfm_ctx(crypto_rng_tfm(rng));
+ struct shash_desc *desc = &ctx->shash;
+ unsigned int h = crypto_shash_digestsize(desc->tfm);
+ int err = 0;
+ u8 *dst_orig = dst;
+ const u8 *label;
+ unsigned int labellen = 0;
+ u32 i = 1;
+ u8 iteration[sizeof(u32)];
+
+ /* require the presence of an IV */
+ if (!src || slen < h)
+ return -EINVAL;
+
+ /* calculate the offset of the label / context data */
+ label = src + h;
+ labellen = slen - h;
+
+ while (dlen) {
+ err = crypto_shash_init(desc);
+ if (err)
+ goto err;
+
+ /*
+ * Feedback mode applies to all rounds except first which uses
+ * the IV.
+ */
+ if (dst_orig == dst)
+ err = crypto_shash_update(desc, src, h);
+ else
+ err = crypto_shash_update(desc, dst - h, h);
+ if (err)
+ goto err;
+
+ crypto_kw_cpu_to_be32(i, iteration);
+ err = crypto_shash_update(desc, iteration, sizeof(u32));
+ if (err)
+ goto err;
+ if (labellen) {
+ err = crypto_shash_update(desc, label, labellen);
+ if (err)
+ goto err;
+ }
+
+ if (dlen < h) {
+ u8 tmpbuffer[h];
+
+ err = crypto_shash_final(desc, tmpbuffer);
+ if (err)
+ goto err;
+ memcpy(dst, tmpbuffer, dlen);
+ memzero_explicit(tmpbuffer, h);
+ return 0;
+ } else {
+ err = crypto_shash_final(desc, dst);
+ if (err)
+ goto err;
+ dlen -= h;
+ dst += h;
+ i++;
+ }
+ }
+
+ return 0;
+
+err:
+ memzero_explicit(dst_orig, dlen);
+ return err;
+}
+
+/*
+ * Implementation of the KDF in counter mode according to SP800-108 section 5.1
+ * as well as SP800-56A section 5.8.1 (Single-step KDF).
+ *
+ * SP800-108:
+ * The caller must provide Label || 0x00 || Context in src. This src pointer
+ * may also be NULL if the caller wishes not to provide anything.
+ *
+ * SP800-56A:
+ * The key provided for the HMAC during the crypto_rng_reset shall NOT be the
+ * shared secret from the DH operation, but an independently generated key.
+ * The src pointer is defined as Z || other info where Z is the shared secret
+ * from DH and other info is an arbitrary string (see SP800-56A section
+ * 5.8.1.2).
+ */
+static int crypto_kdf_ctr_random(struct crypto_rng *rng,
+ const u8 *src, unsigned int slen,
+ u8 *dst, unsigned int dlen)
+{
+ struct crypto_kdf_ctx *ctx = crypto_tfm_ctx(crypto_rng_tfm(rng));
+ struct shash_desc *desc = &ctx->shash;
+ unsigned int h = crypto_shash_digestsize(desc->tfm);
+ int err = 0;
+ u8 *dst_orig = dst;
+ u32 i = 1;
+ u8 iteration[sizeof(u32)];
+
+ while (dlen) {
+ err = crypto_shash_init(desc);
+ if (err)
+ goto err;
+
+ crypto_kw_cpu_to_be32(i, iteration);
+ err = crypto_shash_update(desc, iteration, sizeof(u32));
+ if (err)
+ goto err;
+
+ if (src && slen) {
+ err = crypto_shash_update(desc, src, slen);
+ if (err)
+ goto err;
+ }
+
+ if (dlen < h) {
+ u8 tmpbuffer[h];
+
+ err = crypto_shash_final(desc, tmpbuffer);
+ if (err)
+ goto err;
+ memcpy(dst, tmpbuffer, dlen);
+ memzero_explicit(tmpbuffer, h);
+ return 0;
+ } else {
+ err = crypto_shash_final(desc, dst);
+ if (err)
+ goto err;
+
+ dlen -= h;
+ dst += h;
+ i++;
+ }
+ }
+
+ return 0;
+
+err:
+ memzero_explicit(dst_orig, dlen);
+ return err;
+}
+
+/*
+ * The seeding of the KDF allows to set a key which must be at least
+ * digestsize long.
+ */
+static int crypto_kdf_seed(struct crypto_rng *rng,
+ const u8 *seed, unsigned int slen)
+{
+ struct crypto_kdf_ctx *ctx = crypto_tfm_ctx(crypto_rng_tfm(rng));
+ unsigned int ds = crypto_shash_digestsize(ctx->shash.tfm);
+
+ /* Check according to SP800-108 section 7.2 */
+ if (ds > slen)
+ return -EINVAL;
+
+ /*
+ * We require that we operate on a MAC -- if we do not operate on a
+ * MAC, this function returns an error.
+ */
+ return crypto_shash_setkey(ctx->shash.tfm, seed, slen);
+}
+
+static int crypto_kdf_init_tfm(struct crypto_tfm *tfm)
+{
+ struct crypto_instance *inst = crypto_tfm_alg_instance(tfm);
+ struct crypto_shash_spawn *spawn = crypto_instance_ctx(inst);
+ struct crypto_kdf_ctx *ctx = crypto_tfm_ctx(tfm);
+ struct crypto_shash *hash;
+
+ hash = crypto_spawn_shash(spawn);
+ if (IS_ERR(hash))
+ return PTR_ERR(hash);
+
+ ctx->shash.tfm = hash;
+
+ return 0;
+}
+
+static void crypto_kdf_exit_tfm(struct crypto_tfm *tfm)
+{
+ struct crypto_kdf_ctx *ctx = crypto_tfm_ctx(tfm);
+
+ crypto_free_shash(ctx->shash.tfm);
+}
+
+static void crypto_kdf_free(struct rng_instance *inst)
+{
+ crypto_drop_spawn(rng_instance_ctx(inst));
+ kfree(inst);
+}
+
+static int crypto_kdf_alloc_common(struct crypto_template *tmpl,
+ struct rtattr **tb,
+ const u8 *name,
+ int (*generate)(struct crypto_rng *tfm,
+ const u8 *src,
+ unsigned int slen,
+ u8 *dst, unsigned int dlen))
+{
+ struct rng_instance *inst;
+ struct crypto_alg *alg;
+ struct shash_alg *salg;
+ int err;
+ unsigned int ds, ss;
+
+ err = crypto_check_attr_type(tb, CRYPTO_ALG_TYPE_RNG);
+ if (err)
+ return err;
+
+ salg = shash_attr_alg(tb[1], 0, 0);
+ if (IS_ERR(salg))
+ return PTR_ERR(salg);
+
+ ds = salg->digestsize;
+ ss = salg->statesize;
+ alg = &salg->base;
+
+ inst = rng_alloc_instance(name, alg);
+ err = PTR_ERR(inst);
+ if (IS_ERR(inst))
+ goto out_put_alg;
+
+ err = crypto_init_shash_spawn(rng_instance_ctx(inst), salg,
+ rng_crypto_instance(inst));
+ if (err)
+ goto out_free_inst;
+
+ inst->alg.base.cra_priority = alg->cra_priority;
+ inst->alg.base.cra_blocksize = alg->cra_blocksize;
+ inst->alg.base.cra_alignmask = alg->cra_alignmask;
+
+ inst->alg.generate = generate;
+ inst->alg.seed = crypto_kdf_seed;
+ inst->alg.seedsize = ds;
+
+ inst->alg.base.cra_init = crypto_kdf_init_tfm;
+ inst->alg.base.cra_exit = crypto_kdf_exit_tfm;
+ inst->alg.base.cra_ctxsize = ALIGN(sizeof(struct crypto_kdf_ctx) +
+ ss * 2, crypto_tfm_ctx_alignment());
+
+ inst->free = crypto_kdf_free;
+
+ err = rng_register_instance(tmpl, inst);
+
+ if (err) {
+out_free_inst:
+ crypto_kdf_free(inst);
+ }
+
+out_put_alg:
+ crypto_mod_put(alg);
+ return err;
+}
+
+static int crypto_kdf_ctr_create(struct crypto_template *tmpl,
+ struct rtattr **tb)
+{
+ return crypto_kdf_alloc_common(tmpl, tb, "kdf_ctr",
+ crypto_kdf_ctr_random);
+}
+
+static struct crypto_template crypto_kdf_ctr_tmpl = {
+ .name = "kdf_ctr",
+ .create = crypto_kdf_ctr_create,
+ .module = THIS_MODULE,
+};
+
+static int crypto_kdf_fb_create(struct crypto_template *tmpl,
+ struct rtattr **tb) {
+ return crypto_kdf_alloc_common(tmpl, tb, "kdf_fb",
+ crypto_kdf_fb_random);
+}
+
+static struct crypto_template crypto_kdf_fb_tmpl = {
+ .name = "kdf_fb",
+ .create = crypto_kdf_fb_create,
+ .module = THIS_MODULE,
+};
+
+static int crypto_kdf_dpi_create(struct crypto_template *tmpl,
+ struct rtattr **tb) {
+ return crypto_kdf_alloc_common(tmpl, tb, "kdf_dpi",
+ crypto_kdf_dpi_random);
+}
+
+static struct crypto_template crypto_kdf_dpi_tmpl = {
+ .name = "kdf_dpi",
+ .create = crypto_kdf_dpi_create,
+ .module = THIS_MODULE,
+};
+
+static int __init crypto_kdf_init(void)
+{
+ int err = crypto_register_template(&crypto_kdf_ctr_tmpl);
+
+ if (err)
+ return err;
+
+ err = crypto_register_template(&crypto_kdf_fb_tmpl);
+ if (err) {
+ crypto_unregister_template(&crypto_kdf_ctr_tmpl);
+ return err;
+ }
+
+ err = crypto_register_template(&crypto_kdf_dpi_tmpl);
+ if (err) {
+ crypto_unregister_template(&crypto_kdf_ctr_tmpl);
+ crypto_unregister_template(&crypto_kdf_fb_tmpl);
+ }
+ return err;
+}
+
+static void __exit crypto_kdf_exit(void)
+{
+ crypto_unregister_template(&crypto_kdf_ctr_tmpl);
+ crypto_unregister_template(&crypto_kdf_fb_tmpl);
+ crypto_unregister_template(&crypto_kdf_dpi_tmpl);
+}
+
+module_init(crypto_kdf_init);
+module_exit(crypto_kdf_exit);
+
+MODULE_LICENSE("Dual BSD/GPL");
+MODULE_AUTHOR("Stephan Mueller <smueller@chronox.de>");
+MODULE_DESCRIPTION("Key Derivation Function according to SP800-108 and SP800-56A");
+MODULE_ALIAS_CRYPTO("kdf_ctr");
+MODULE_ALIAS_CRYPTO("kdf_fb");
+MODULE_ALIAS_CRYPTO("kdf_dpi");
--
2.7.4
^ permalink raw reply related
* [PATCH v5 2/4] crypto: kdf - add known answer tests
From: Stephan Mueller @ 2016-08-09 12:28 UTC (permalink / raw)
To: herbert; +Cc: mathew.j.martineau, dhowells, linux-crypto, keyrings
In-Reply-To: <2808589.gm6f519sFh@positron.chronox.de>
Add known answer tests to the testmgr for the KDF (SP800-108) cipher.
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
crypto/testmgr.c | 226 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
crypto/testmgr.h | 110 +++++++++++++++++++++++++++
2 files changed, 336 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index c2a8bd3..8ac1a2d 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -116,6 +116,11 @@ struct drbg_test_suite {
unsigned int count;
};
+struct kdf_test_suite {
+ struct kdf_testvec *vecs;
+ unsigned int count;
+};
+
struct akcipher_test_suite {
struct akcipher_testvec *vecs;
unsigned int count;
@@ -139,6 +144,7 @@ struct alg_test_desc {
struct hash_test_suite hash;
struct cprng_test_suite cprng;
struct drbg_test_suite drbg;
+ struct kdf_test_suite kdf;
struct akcipher_test_suite akcipher;
struct kpp_test_suite kpp;
} suite;
@@ -1758,6 +1764,64 @@ outbuf:
return ret;
}
+static int kdf_cavs_test(struct kdf_testvec *test,
+ const char *driver, u32 type, u32 mask)
+{
+ int ret = -EAGAIN;
+ struct crypto_rng *drng;
+ unsigned char *buf = kzalloc(test->expectedlen, GFP_KERNEL);
+
+ if (!buf)
+ return -ENOMEM;
+
+ drng = crypto_alloc_rng(driver, type | CRYPTO_ALG_INTERNAL, mask);
+ if (IS_ERR(drng)) {
+ printk(KERN_ERR "alg: kdf: could not allocate cipher handle "
+ "for %s\n", driver);
+ kzfree(buf);
+ return -ENOMEM;
+ }
+
+ ret = crypto_rng_reset(drng, test->K1, test->K1len);
+ if (ret) {
+ printk(KERN_ERR "alg: kdf: could not set key derivation key\n");
+ goto err;
+ }
+
+ ret = crypto_rng_generate(drng, test->context, test->contextlen,
+ buf, test->expectedlen);
+ if (ret) {
+ printk(KERN_ERR "alg: kdf: could not obtain key data\n");
+ goto err;
+ }
+
+ ret = memcmp(test->expected, buf, test->expectedlen);
+
+err:
+ crypto_free_rng(drng);
+ kzfree(buf);
+ return ret;
+}
+
+static int alg_test_kdf(const struct alg_test_desc *desc, const char *driver,
+ u32 type, u32 mask)
+{
+ int err = 0;
+ unsigned int i = 0;
+ struct kdf_testvec *template = desc->suite.kdf.vecs;
+ unsigned int tcount = desc->suite.kdf.count;
+
+ for (i = 0; i < tcount; i++) {
+ err = kdf_cavs_test(&template[i], driver, type, mask);
+ if (err) {
+ printk(KERN_ERR "alg: kdf: Test %d failed for %s\n",
+ i, driver);
+ err = -EINVAL;
+ break;
+ }
+ }
+ return err;
+}
static int alg_test_drbg(const struct alg_test_desc *desc, const char *driver,
u32 type, u32 mask)
@@ -3467,6 +3531,168 @@ static const struct alg_test_desc alg_test_descs[] = {
.fips_allowed = 1,
.test = alg_test_null,
}, {
+ .alg = "kdf_ctr(cmac(aes))",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "kdf_ctr(cmac(des3_ede))",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "kdf_ctr(hmac(sha1))",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "kdf_ctr(hmac(sha224))",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "kdf_ctr(hmac(sha256))",
+ .test = alg_test_kdf,
+ .fips_allowed = 1,
+ .suite = {
+ .kdf = {
+ .vecs = kdf_ctr_hmac_sha256_tv_template,
+ .count = ARRAY_SIZE(kdf_ctr_hmac_sha256_tv_template)
+ }
+ }
+ }, {
+ .alg = "kdf_ctr(hmac(sha384))",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "kdf_ctr(hmac(sha512))",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "kdf_ctr(sha1)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "kdf_ctr(sha224)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "kdf_ctr(sha256)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "kdf_ctr(sha384)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "kdf_ctr(sha512)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "kdf_dpi(cmac(aes))",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "kdf_dpi(cmac(des3_ede))",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "kdf_dpi(hmac(sha1))",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "kdf_dpi(hmac(sha224))",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "kdf_dpi(hmac(sha256))",
+ .test = alg_test_kdf,
+ .fips_allowed = 1,
+ .suite = {
+ .kdf = {
+ .vecs = kdf_dpi_hmac_sha256_tv_template,
+ .count = ARRAY_SIZE(kdf_dpi_hmac_sha256_tv_template)
+ }
+ }
+ }, {
+ .alg = "kdf_dpi(hmac(sha384))",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "kdf_dpi(hmac(sha512))",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "kdf_dpi(sha1)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "kdf_dpi(sha224)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "kdf_dpi(sha256)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "kdf_dpi(sha384)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "kdf_dpi(sha512)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "kdf_fb(cmac(aes))",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "kdf_fb(cmac(des3_ede))",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "kdf_fb(hmac(sha1))",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "kdf_fb(hmac(sha224))",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "kdf_fb(hmac(sha256))",
+ .test = alg_test_kdf,
+ .fips_allowed = 1,
+ .suite = {
+ .kdf = {
+ .vecs = kdf_fb_hmac_sha256_tv_template,
+ .count = ARRAY_SIZE(kdf_fb_hmac_sha256_tv_template)
+ }
+ }
+ }, {
+ .alg = "kdf_fb(hmac(sha384))",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "kdf_fb(hmac(sha512))",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "kdf_fb(sha1)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "kdf_fb(sha224)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "kdf_fb(sha256)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "kdf_fb(sha384)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "kdf_fb(sha512)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
.alg = "kw(aes)",
.test = alg_test_skcipher,
.fips_allowed = 1,
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index acb6bbf..1fe93ed 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -123,6 +123,15 @@ struct drbg_testvec {
size_t expectedlen;
};
+struct kdf_testvec {
+ unsigned char *K1;
+ size_t K1len;
+ unsigned char *context;
+ size_t contextlen;
+ unsigned char *expected;
+ size_t expectedlen;
+};
+
struct akcipher_testvec {
unsigned char *key;
unsigned char *m;
@@ -25827,6 +25836,107 @@ static struct drbg_testvec drbg_nopr_ctr_aes128_tv_template[] = {
},
};
+/*
+ * Test vector obtained from
+ * http://csrc.nist.gov/groups/STM/cavp/documents/KBKDF800-108/CounterMode.zip
+ */
+static struct kdf_testvec kdf_ctr_hmac_sha256_tv_template[] = {
+ {
+ .K1 = (unsigned char *)
+ "\xdd\x1d\x91\xb7\xd9\x0b\x2b\xd3"
+ "\x13\x85\x33\xce\x92\xb2\x72\xfb"
+ "\xf8\xa3\x69\x31\x6a\xef\xe2\x42"
+ "\xe6\x59\xcc\x0a\xe2\x38\xaf\xe0",
+ .K1len = 32,
+ .context = (unsigned char *)
+ "\x01\x32\x2b\x96\xb3\x0a\xcd\x19"
+ "\x79\x79\x44\x4e\x46\x8e\x1c\x5c"
+ "\x68\x59\xbf\x1b\x1c\xf9\x51\xb7"
+ "\xe7\x25\x30\x3e\x23\x7e\x46\xb8"
+ "\x64\xa1\x45\xfa\xb2\x5e\x51\x7b"
+ "\x08\xf8\x68\x3d\x03\x15\xbb\x29"
+ "\x11\xd8\x0a\x0e\x8a\xba\x17\xf3"
+ "\xb4\x13\xfa\xac",
+ .contextlen = 60,
+ .expected = (unsigned char *)
+ "\x10\x62\x13\x42\xbf\xb0\xfd\x40"
+ "\x04\x6c\x0e\x29\xf2\xcf\xdb\xf0",
+ .expectedlen = 16
+ }
+};
+
+/*
+ * Test vector obtained from
+ * http://csrc.nist.gov/groups/STM/cavp/documents/KBKDF800-108/FeedbackModeNOzeroiv.zip
+ */
+static struct kdf_testvec kdf_fb_hmac_sha256_tv_template[] = {
+ {
+ .K1 = (unsigned char *)
+ "\x93\xf6\x98\xe8\x42\xee\xd7\x53"
+ "\x94\xd6\x29\xd9\x57\xe2\xe8\x9c"
+ "\x6e\x74\x1f\x81\x0b\x62\x3c\x8b"
+ "\x90\x1e\x38\x37\x6d\x06\x8e\x7b",
+ .K1len = 32,
+ .context = (unsigned char *)
+ "\x9f\x57\x5d\x90\x59\xd3\xe0\xc0"
+ "\x80\x3f\x08\x11\x2f\x8a\x80\x6d"
+ "\xe3\xc3\x47\x19\x12\xcd\xf4\x2b"
+ "\x09\x53\x88\xb1\x4b\x33\x50\x8e"
+ "\x53\xb8\x9c\x18\x69\x0e\x20\x57"
+ "\xa1\xd1\x67\x82\x2e\x63\x6d\xe5"
+ "\x0b\xe0\x01\x85\x32\xc4\x31\xf7"
+ "\xf5\xe3\x7f\x77\x13\x92\x20\xd5"
+ "\xe0\x42\x59\x9e\xbe\x26\x6a\xf5"
+ "\x76\x7e\xe1\x8c\xd2\xc5\xc1\x9a"
+ "\x1f\x0f\x80",
+ .contextlen = 83,
+ .expected = (unsigned char *)
+ "\xbd\x14\x76\xf4\x3a\x4e\x31\x57"
+ "\x47\xcf\x59\x18\xe0\xea\x5b\xc0"
+ "\xd9\x87\x69\x45\x74\x77\xc3\xab"
+ "\x18\xb7\x42\xde\xf0\xe0\x79\xa9"
+ "\x33\xb7\x56\x36\x5a\xfb\x55\x41"
+ "\xf2\x53\xfe\xe4\x3c\x6f\xd7\x88"
+ "\xa4\x40\x41\x03\x85\x09\xe9\xee"
+ "\xb6\x8f\x7d\x65\xff\xbb\x5f\x95",
+ .expectedlen = 64
+ }
+};
+
+/*
+ * Test vector obtained from
+ * http://csrc.nist.gov/groups/STM/cavp/documents/KBKDF800-108/PipelineModewithCounter.zip
+ */
+static struct kdf_testvec kdf_dpi_hmac_sha256_tv_template[] = {
+ {
+ .K1 = (unsigned char *)
+ "\x02\xd3\x6f\xa0\x21\xc2\x0d\xdb"
+ "\xde\xe4\x69\xf0\x57\x94\x68\xba"
+ "\xe5\xcb\x13\xb5\x48\xb6\xc6\x1c"
+ "\xdf\x9d\x3e\xc4\x19\x11\x1d\xe2",
+ .K1len = 32,
+ .context = (unsigned char *)
+ "\x85\xab\xe3\x8b\xf2\x65\xfb\xdc"
+ "\x64\x45\xae\x5c\x71\x15\x9f\x15"
+ "\x48\xc7\x3b\x7d\x52\x6a\x62\x31"
+ "\x04\x90\x4a\x0f\x87\x92\x07\x0b"
+ "\x3d\xf9\x90\x2b\x96\x69\x49\x04"
+ "\x25\xa3\x85\xea\xdb\x0f\x9c\x76"
+ "\xe4\x6f\x0f",
+ .contextlen = 51,
+ .expected = (unsigned char *)
+ "\xd6\x9f\x74\xf5\x18\xc9\xf6\x4f"
+ "\x90\xa0\xbe\xeb\xab\x69\xf6\x89"
+ "\xb7\x3b\x5c\x13\xeb\x0f\x86\x0a"
+ "\x95\xca\xd7\xd9\x81\x4f\x8c\x50"
+ "\x6e\xb7\xb1\x79\xa5\xc5\xb4\x46"
+ "\x6a\x9e\xc1\x54\xc3\xbf\x1c\x13"
+ "\xef\xd6\xec\x0d\x82\xb0\x2c\x29"
+ "\xaf\x2c\x69\x02\x99\xed\xc4\x53",
+ .expectedlen = 64
+ }
+};
+
/* Cast5 test vectors from RFC 2144 */
#define CAST5_ENC_TEST_VECTORS 4
#define CAST5_DEC_TEST_VECTORS 4
--
2.7.4
^ permalink raw reply related
* [PATCH v5 4/4] crypto: kdf - enable compilation
From: Stephan Mueller @ 2016-08-09 12:28 UTC (permalink / raw)
To: herbert; +Cc: mathew.j.martineau, dhowells, linux-crypto, keyrings
In-Reply-To: <2808589.gm6f519sFh@positron.chronox.de>
Include KDF into Kconfig and Makefile for compilation.
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
crypto/Kconfig | 7 +++++++
crypto/Makefile | 1 +
2 files changed, 8 insertions(+)
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 84d7148..16f3221 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -372,6 +372,13 @@ config CRYPTO_KEYWRAP
Support for key wrapping (NIST SP800-38F / RFC3394) without
padding.
+config CRYPTO_KDF
+ tristate "Key Derivation Function (SP800-108)"
+ select CRYPTO_RNG
+ help
+ Support for KDF compliant to SP800-108. All three types of
+ KDF specified in SP800-108 are implemented.
+
comment "Hash modes"
config CRYPTO_CMAC
diff --git a/crypto/Makefile b/crypto/Makefile
index 99cc64a..9022280 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -80,6 +80,7 @@ obj-$(CONFIG_CRYPTO_LRW) += lrw.o
obj-$(CONFIG_CRYPTO_XTS) += xts.o
obj-$(CONFIG_CRYPTO_CTR) += ctr.o
obj-$(CONFIG_CRYPTO_KEYWRAP) += keywrap.o
+obj-$(CONFIG_CRYPTO_KDF) += kdf.o
obj-$(CONFIG_CRYPTO_GCM) += gcm.o
obj-$(CONFIG_CRYPTO_CCM) += ccm.o
obj-$(CONFIG_CRYPTO_CHACHA20POLY1305) += chacha20poly1305.o
--
2.7.4
^ permalink raw reply related
* [PATCH v5 0/4] crypto: Key Derivation Function (SP800-108)
From: Stephan Mueller @ 2016-08-09 12:27 UTC (permalink / raw)
To: herbert; +Cc: mathew.j.martineau, dhowells, linux-crypto, keyrings
Hi,
this patch set implements all three key derivation functions defined in
SP800-108.
The implementation is provided as a template for random number generators,
since a KDF can be considered a form of deterministic RNG where the key
material is used as a seed.
With the KDF implemented as a template, all types of keyed and
non-keyed hashes can be utilized, including HMAC and CMAC. The testmgr
tests are derived from publicly available test vectors from NIST.
The KDF are all tested with a complete round of CAVS testing on 32 and 64 bit.
The patch set introduces an extension to the kernel crypto API in the first
patch by adding a template handling for random number generators based on the
same logic as for keyed hashes.
Changes v5:
* move rng_instance and __crypto_rng_alg into rng.c
Changes v4:
* removal of the check that src and dst buffers are not the same from the KDF
implementations as requested by Herbert
* implement and use new free API in the RNG instance handling as requested
by Herbert
* move the instance handling code from include/crypto/rng.h to
include/crypto/internal/rng.h
Changes v3:
* port testmgr patch to current cryptodev-2.6 tree
* add non-keyed KDF references to testmgr.c
Changes v2:
* port to 4.7-rc1
Stephan Mueller (4):
crypto: add template handling for RNGs
crypto: kdf - add known answer tests
crypto: kdf - SP800-108 Key Derivation Function
crypto: kdf - enable compilation
crypto/Kconfig | 7 +
crypto/Makefile | 1 +
crypto/kdf.c | 508 ++++++++++++++++++++++++++++++++++++++++++
crypto/rng.c | 44 ++++
crypto/testmgr.c | 226 +++++++++++++++++++
crypto/testmgr.h | 110 +++++++++
include/crypto/internal/rng.h | 26 +++
7 files changed, 922 insertions(+)
create mode 100644 crypto/kdf.c
--
2.7.4
^ permalink raw reply
* [PATCH v5 1/4] crypto: add template handling for RNGs
From: Stephan Mueller @ 2016-08-09 12:27 UTC (permalink / raw)
To: herbert; +Cc: mathew.j.martineau, dhowells, linux-crypto, keyrings
In-Reply-To: <2808589.gm6f519sFh@positron.chronox.de>
This patch adds the ability to register templates for RNGs. RNGs are
"meta" mechanisms using raw cipher primitives. Thus, RNGs can now be
implemented as templates to allow the complete flexibility the kernel
crypto API provides.
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
crypto/rng.c | 44 +++++++++++++++++++++++++++++++++++++++++++
include/crypto/internal/rng.h | 26 +++++++++++++++++++++++++
2 files changed, 70 insertions(+)
diff --git a/crypto/rng.c b/crypto/rng.c
index b81cffb..a4ee894 100644
--- a/crypto/rng.c
+++ b/crypto/rng.c
@@ -63,6 +63,25 @@ static int crypto_rng_init_tfm(struct crypto_tfm *tfm)
return 0;
}
+static inline struct rng_alg *__crypto_rng_alg(struct crypto_alg *alg)
+{
+ return container_of(alg, struct rng_alg, base);
+}
+
+static inline struct rng_instance *rng_instance(
+ struct crypto_instance *inst)
+{
+ return container_of(__crypto_rng_alg(&inst->alg),
+ struct rng_instance, alg);
+}
+
+static void crypto_rng_free_instance(struct crypto_instance *inst)
+{
+ struct rng_instance *rng = rng_instance(inst);
+
+ rng->free(rng);
+}
+
static unsigned int seedsize(struct crypto_alg *alg)
{
struct rng_alg *ralg = container_of(alg, struct rng_alg, base);
@@ -105,6 +124,7 @@ static void crypto_rng_show(struct seq_file *m, struct crypto_alg *alg)
static const struct crypto_type crypto_rng_type = {
.extsize = crypto_alg_extsize,
.init_tfm = crypto_rng_init_tfm,
+ .free = crypto_rng_free_instance,
#ifdef CONFIG_PROC_FS
.show = crypto_rng_show,
#endif
@@ -232,5 +252,29 @@ void crypto_unregister_rngs(struct rng_alg *algs, int count)
}
EXPORT_SYMBOL_GPL(crypto_unregister_rngs);
+static int rng_prepare_alg(struct rng_alg *alg)
+{
+ struct crypto_alg *base = &alg->base;
+
+ base->cra_type = &crypto_rng_type;
+ base->cra_flags &= ~CRYPTO_ALG_TYPE_MASK;
+ base->cra_flags |= CRYPTO_ALG_TYPE_RNG;
+
+ return 0;
+}
+
+int rng_register_instance(struct crypto_template *tmpl,
+ struct rng_instance *inst)
+{
+ int err;
+
+ err = rng_prepare_alg(&inst->alg);
+ if (err)
+ return err;
+
+ return crypto_register_instance(tmpl, rng_crypto_instance(inst));
+}
+EXPORT_SYMBOL_GPL(rng_register_instance);
+
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Random Number Generator");
diff --git a/include/crypto/internal/rng.h b/include/crypto/internal/rng.h
index a52ef34..aeaf58f 100644
--- a/include/crypto/internal/rng.h
+++ b/include/crypto/internal/rng.h
@@ -42,4 +42,30 @@ static inline void crypto_rng_set_entropy(struct crypto_rng *tfm,
crypto_rng_alg(tfm)->set_ent(tfm, data, len);
}
+struct rng_instance {
+ void (*free)(struct rng_instance *inst);
+ struct rng_alg alg;
+};
+
+static inline struct rng_instance *rng_alloc_instance(
+ const char *name, struct crypto_alg *alg)
+{
+ return crypto_alloc_instance2(name, alg,
+ sizeof(struct rng_instance) - sizeof(*alg));
+}
+
+static inline struct crypto_instance *rng_crypto_instance(
+ struct rng_instance *inst)
+{
+ return container_of(&inst->alg.base, struct crypto_instance, alg);
+}
+
+static inline void *rng_instance_ctx(struct rng_instance *inst)
+{
+ return crypto_instance_ctx(rng_crypto_instance(inst));
+}
+
+int rng_register_instance(struct crypto_template *tmpl,
+ struct rng_instance *inst);
+
#endif
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy
From: Theodore Ts'o @ 2016-08-09 11:56 UTC (permalink / raw)
To: Pan, Miaoqing
Cc: Jason Cooper, Stephan Mueller, Sepehrdad, Pouyan,
herbert@gondor.apana.org.au, linux-kernel@vger.kernel.org,
linux-crypto@vger.kernel.org, ath9k-devel,
linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org,
Kalle Valo
In-Reply-To: <99963d34acea47bbacb3ca73b18fed9f@aptaiexm02f.ap.qualcomm.com>
On Tue, Aug 09, 2016 at 06:30:03AM +0000, Pan, Miaoqing wrote:
> Agree with Jason's point, also understand Stephan's concern. The
> date rate can be roughly estimated by 'cat /dev/random |rngtest -c
> 1000', the average speed is 1111.294Kibits/s. I will sent the patch
> to disable ath9k RNG by default.
If the ATH9K is generating some random amount of data, but you don't
know how random, and you're gathering it opportunistically --- for
example, suppose a wireless driver gets the radio's signal strength
through the normal course of its operation, and while there might not
be that much randomness for someone who can observe the exact details
of how the phone is positioned in the room --- but for which the
analyst sitting in Fort Meade won't know whether or not the phone is
on the desk, or in a knapsack under the table, the right interface to
use is:
void add_device_randomness(const void *buf, unsigned int size);
This won't increase the entropy count, but if you have the bit of
potential randomness "for free", you might as well contribute it to
the entropy pool. If it turns out that the chip was manufactured in
China, and the MSS has backdoored it out the wazoo, it won't do any
harm --- where as using the hwrng framework would be disastrous.
Cheerfs,
- Ted
^ permalink raw reply
* Re: crypto: crc32c-vpmsum - Convert to CPU feature based module autoloading
From: Michael Ellerman @ 2016-08-09 11:26 UTC (permalink / raw)
To: Anton Blanchard, benh, paulus, herbert, davem
Cc: linuxppc-dev, linux-crypto, alastair
In-Reply-To: <1470292695-9829-1-git-send-email-anton@ozlabs.org>
On Thu, 2016-04-08 at 06:38:15 UTC, Anton Blanchard wrote:
> From: Anton Blanchard <anton@samba.org>
>
> This patch utilises the GENERIC_CPU_AUTOPROBE infrastructure
> to automatically load the crc32c-vpmsum module if the CPU supports
> it.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/d2cf5be07ff7c7cde8bef8551a
cheers
^ permalink raw reply
* Re: [PATCH 0/7] Various fixes for the cesa driver
From: Herbert Xu @ 2016-08-09 11:05 UTC (permalink / raw)
To: Romain Perier
Cc: thomas.petazzoni, boris.brezillon, linux, arno, linux-crypto,
gregory.clement, davem, linux-arm-kernel
In-Reply-To: <1470733400-23621-1-git-send-email-romain.perier@free-electrons.com>
Romain Perier <romain.perier@free-electrons.com> wrote:
> This patches series contains various fixes for ahash requests, dma
> operations and an important fixe in the core of the driver (cesa.c). It
> also includes some code cleanups.
All applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: caam - avoid kernel warnings on probe failure
From: Herbert Xu @ 2016-08-09 11:03 UTC (permalink / raw)
To: Russell King; +Cc: Fabio Estevam, horia.geanta, linux-crypto
In-Reply-To: <E1bX1UI-0006vt-K7@rmk-PC.armlinux.org.uk>
On Tue, Aug 09, 2016 at 08:30:10AM +0100, Russell King wrote:
> While debugging setkey issues, the following warnings were found while
> trying to reinsert the caam module. Fix this by avoiding the duplicated
> cleanup in the probe path after caam_remove(), which has already cleaned
> up the resources.
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 00/11] Further iMX CAAM updates
From: Herbert Xu @ 2016-08-09 11:02 UTC (permalink / raw)
To: Russell King - ARM Linux; +Cc: Fabio Estevam, David S. Miller, linux-crypto
In-Reply-To: <20160808170400.GC1041@n2100.armlinux.org.uk>
On Mon, Aug 08, 2016 at 06:04:01PM +0100, Russell King - ARM Linux wrote:
> This is a re-post (with hopefully bugs fixed from December's review).
> Untested, because AF_ALG appears to be broken in 4.8-rc1. Maybe
> someone can provide some hints how to test using tcrypt please?
>
> Here are further imx-caam updates that I've had since before the
> previous merge window. Please review and (I guess) if Freescale
> folk can provide acks etc that would be nice. Thanks.
>
> drivers/crypto/caam/caamhash.c | 540 ++++++++++++++++++++++-------------------
> drivers/crypto/caam/intern.h | 1 -
> drivers/crypto/caam/jr.c | 25 +-
> 3 files changed, 305 insertions(+), 261 deletions(-)
All applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2 0/7] crypto: img-hash - fixes and interface changes
From: Herbert Xu @ 2016-08-09 11:02 UTC (permalink / raw)
To: Will Thomas; +Cc: linux-crypto
In-Reply-To: <1470402020-10774-1-git-send-email-will.thomas@imgtec.com>
On Fri, Aug 05, 2016 at 02:00:13PM +0100, Will Thomas wrote:
> Hi Herbert,
>
> This patchset includes small stability fixes, power management
> and import/export interface functions for the img-hash driver.
>
> Changes as discussed for [1/7], [2/7] and [5/7].
>
>
> Govindraj Raja (1):
> crypto: img-hash - Add suspend resume hooks for img hash
>
> James Hartley (2):
> crypto: img-hash - Add support for export and import
> crypto: img-hash - log a successful probe
>
> Will Thomas (4):
> crypto: img-hash - Fix null pointer exception
> crypto: img-hash - Fix hash request context
> crypto: img-hash - Reconfigure DMA Burst length
> crypto: img-hash - Fix set_reqsize call
All applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox