From: Stephan Mueller <smueller@chronox.de>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Daniel Borkmann <dborkman@redhat.com>,
'Quentin Gouchet' <quentin.gouchet@gmail.com>,
lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-crypto@vger.kernel.org, linux-api@vger.kernel.org
Subject: Re: [PATCH v3 5/7] crypto: AF_ALG: add random number generator support
Date: Mon, 24 Nov 2014 16:08:51 +0100 [thread overview]
Message-ID: <1924093.6oedGBDXii@tauon> (raw)
In-Reply-To: <20141124143150.GC31469@gondor.apana.org.au>
Am Montag, 24. November 2014, 22:31:50 schrieb Herbert Xu:
Hi Herbert,
>On Fri, Nov 21, 2014 at 06:32:52AM +0100, Stephan Mueller wrote:
>> This patch adds the random number generator support for AF_ALG.
>>
>> A random number generator's purpose is to generate data without
>> requiring the caller to provide any data. Therefore, the AF_ALG
>> interface handler for RNGs only implements a callback handler for
>> recvmsg.
>>
>> The following parameters provided with a recvmsg are processed by the
>>
>> RNG callback handler:
>> * sock - to resolve the RNG context data structure accessing
>> the
>>
>> RNG instance private to the socket
>>
>> * len - this parameter allows userspace callers to specify
>> how
>>
>> many random bytes the RNG shall produce and return. As the
>> kernel context for the RNG allocates a buffer of 128 bytes
>> to
>> store random numbers before copying them to userspace, the
>> len
>> parameter is checked that it is not larger than 128. If a
>> caller wants more random numbers, a new request for recvmsg
>> shall be made.
>>
>> The size of 128 bytes is chose because of the following
considerations:
>> * to increase the memory footprint of the kernel too much
>> (note,
>>
>> that would be 128 bytes per open socket)
>>
>> * 128 is divisible by any typical cryptographic block size an
>>
>> RNG may have
>>
>> * A request for random numbers typically only shall supply
>> small
>>
>> amount of data like for keys or IVs that should only
>> require
>> one invocation of the recvmsg function.
>>
>> Note, during instantiation of the RNG, the code checks whether the
>> RNG
>> implementation requires seeding. If so, the RNG is seeded with output
>> from get_random_bytes.
>>
>> A fully working example using all aspects of the RNG interface is
>> provided at http://www.chronox.de/libkcapi.html
>>
>> Signed-off-by: Stephan Mueller <smueller@chronox.de>
>
>Sorry but who is going to use this and for what purpose?
>
>Every other algif interface exports real hardware features that
>cannot otherwise be accessed from user-space. All crypto RNGs
>are by definition software-only, so what is the point of this?
My idea is twofold: The software-RNGs currently available (X9.31 and
DRBG) use other ciphers as backends. Therefore, they can be considered
as transforms on top of these backend ciphers. Now, if these backend
ciphers are available in kernel mode only, currently only these in-
kernel RNGs can use the hardware.
With the consideration of AEAD, all ciphers supported by the kernel
crypto API are available to user space. That means, there is no need for
an additional crypto library in user space in addition to provide
hardware access. The RNG part is there to complement the case for not
needing an additional crypto lib in user space.
Ciao
Stephan
next prev parent reply other threads:[~2014-11-24 15:08 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-21 5:29 [PATCH v3 0/7] crypto: AF_ALG: add AEAD and RNG support Stephan Mueller
2014-11-21 5:30 ` [PATCH v3 1/7] crypto: AF_ALG: add user space interface for AEAD Stephan Mueller
[not found] ` <5694690.RURGUoE58b-PJstQz4BMNNP20K/wil9xYQuADTiUCJX@public.gmane.org>
2014-11-24 14:26 ` Herbert Xu
2014-11-21 5:30 ` [PATCH v3 3/7] crypto: AF_ALG: crypto API calls to inline functions Stephan Mueller
2014-11-21 5:31 ` [PATCH v3 2/7] crypto: AF_ALG: extend data structuers for AEAD Stephan Mueller
2014-11-21 5:32 ` [PATCH v3 4/7] crypto: AF_ALG: add AEAD support Stephan Mueller
[not found] ` <2175035.5IWBGpA0Ko-PJstQz4BMNNP20K/wil9xYQuADTiUCJX@public.gmane.org>
2014-11-24 14:29 ` Herbert Xu
2014-11-24 14:58 ` Stephan Mueller
2014-11-25 14:58 ` Herbert Xu
[not found] ` <20141125145850.GD8541-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
2014-11-25 15:08 ` Stephan Mueller
2014-11-24 20:55 ` Stephan Mueller
2014-11-21 5:32 ` [PATCH v3 5/7] crypto: AF_ALG: add random number generator support Stephan Mueller
2014-11-24 14:31 ` Herbert Xu
2014-11-24 15:08 ` Stephan Mueller [this message]
2014-11-21 5:33 ` [PATCH v3 6/7] crypto: AF_ALG: enable RNG interface compilation Stephan Mueller
2014-11-21 5:34 ` [PATCH v3 7/7] crypto: AF_ALG: document the user space interface Stephan Mueller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1924093.6oedGBDXii@tauon \
--to=smueller@chronox.de \
--cc=dborkman@redhat.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-api@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quentin.gouchet@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox