* Re: Test AEAD/authenc algorithms from userspace
From: Stephan Mueller @ 2016-05-31 11:05 UTC (permalink / raw)
To: Harsh Jain; +Cc: linux-crypto
In-Reply-To: <CAFXBA==PsTepbhPeBMsb1YyKx12B8ie5KC7VF=8pwCSBFJgfgg@mail.gmail.com>
Am Dienstag, 31. Mai 2016, 16:28:14 schrieb Harsh Jain:
Hi Harsh,
> Hi Stephen,
>
> Yes ,It's for Hash. The available API in library for hash update
> "_kcapi_md_update" uses "MSG_MORE" flag always set. It will not
> trigger driver's digest/finup implementation. We need something like
> that
>
> _kcapi_common_accept()
> send(handle->opfd, buffer, len, 0); ==> flag = 0.
>
> It will execute digest callback of selected tfm from User
> Space.(init->digest) Similarly
>
> _kcapi_common_accept()
> send(handle->opfd, buffer, len, MSG_MORE);
> send(handle->opfd, buffer, len, 0);
>
> It will execute finup callback of selected tfm. (init->update->finup).
>
> In that way we can test all callbacks from userspace. In future if you
> feel this use case important. You can add API's to implement this.
Ok, I see that the finup code path is not exercised in the kernel by my
library.
Why do you think that this code path should be tested by my test code?
The test code shall verify that libkcapi works fine.
Ciao
Stephan
^ permalink raw reply
* Re: Test AEAD/authenc algorithms from userspace
From: Harsh Jain @ 2016-05-31 10:58 UTC (permalink / raw)
To: Stephan Mueller; +Cc: linux-crypto
In-Reply-To: <3164476.NJZyJLbx96@tauon.atsec.com>
Hi Stephen,
Yes ,It's for Hash. The available API in library for hash update
"_kcapi_md_update" uses "MSG_MORE" flag always set. It will not
trigger driver's digest/finup implementation. We need something like
that
_kcapi_common_accept()
send(handle->opfd, buffer, len, 0); ==> flag = 0.
It will execute digest callback of selected tfm from User
Space.(init->digest) Similarly
_kcapi_common_accept()
send(handle->opfd, buffer, len, MSG_MORE);
send(handle->opfd, buffer, len, 0);
It will execute finup callback of selected tfm. (init->update->finup).
In that way we can test all callbacks from userspace. In future if you
feel this use case important. You can add API's to implement this.
Regards
Harsh Jain
regards
Harsh Jain
regards
Harsh Jain
On Tue, May 31, 2016 at 2:51 PM, Stephan Mueller <smueller@chronox.de> wrote:
> Am Dienstag, 31. Mai 2016, 14:45:27 schrieb Harsh Jain:
>
> Hi Harsh,
>
>> Hi,
>>
>> Thanks Stephen, I will check the same.1 suggestion for kcapi tool. Add
>> some switch cases in tool to test digest and finup path of crypto
>> driver. Current implementation triggers only init/update/final.
>
> You mean for hashes? I guess the following is what you refer to? This logic is
> even found for the other cipher types (symmetric algos, AEAD ciphers). See the
> documentation on stream vs one-shot use cases.
>
> /**
> * kcapi_md_init() - initialize cipher handle
> * @handle: cipher handle filled during the call - output
> * @ciphername: kernel crypto API cipher name as specified in
> * /proc/crypto - input
> * @flags: flags specifying the type of cipher handle
> *
> * This function provides the initialization of a (keyed) message digest
> handle
> * and establishes the connection to the kernel.
> *
> * Return: 0 upon success; ENOENT - algorithm not available;
> * -EOPNOTSUPP - AF_ALG family not available;
> * -EINVAL - accept syscall failed
> * -ENOMEM - cipher handle cannot be allocated
> */
> int kcapi_md_init(struct kcapi_handle **handle, const char *ciphername,
> uint32_t flags);
>
> /**
> * kcapi_md_update() - message digest update function (stream)
> * @handle: cipher handle - input
> * @buffer: holding the data to add to the message digest - input
> * @len: buffer length - input
> *
> * Return: 0 upon success;
> * < 0 in case of error
> */
> int32_t kcapi_md_update(struct kcapi_handle *handle,
> const uint8_t *buffer, uint32_t len);
>
> /**
> * kcapi_md_final() - message digest finalization function (stream)
> * @handle: cipher handle - input
> * @buffer: filled with the message digest - output
> * @len: buffer length - input
> *
> * Return: size of message digest upon success;
> * -EIO - data cannot be obtained;
> * -ENOMEM - buffer is too small for the complete message digest,
> * the buffer is filled with the truncated message digest
> */
> int32_t kcapi_md_final(struct kcapi_handle *handle,
> uint8_t *buffer, uint32_t len);
>
>
> The test/kcapi tool is a crude test tool that I use for my regression testing.
> It is not intended for anything else.
>>
>>
>> Regards
>> Harsh Jain
>>
>> On Tue, May 31, 2016 at 2:29 PM, Stephan Mueller <smueller@chronox.de>
> wrote:
>> > Am Dienstag, 31. Mai 2016, 14:10:20 schrieb Harsh Jain:
>> >
>> > Hi Harsh,
>> >
>> >> Hi,
>> >>
>> >> You means to say like this
>> >>
>> >> ./kcapi -x 2 -e -c "authenc(hmac(sha1),cbc(aes))" -p
>> >> 48981da18e4bb9ef7e2e3162d16b19108b19050f66582cb7f7e4b6c873819b71 -k
>> >> 8d7dd9b0170ce0b5f2f8e1aa768e01e91da8bfc67fd486d081b28254c99eb423 -i
>> >> 7fbc02ebf5b93322329df9bfccb635af -a afcd7202d621e06ca53b70c2bdff7fb2
>> >> -l 16f4a3eacfbdadd3b1a17117b1d67ffc1f1e21efbbc6d83724a8c296e3bb8cda0c44
>> >>
>> >> It gives following error with kernel 4.5.2
>> >> Symmetric cipher setkey failed
>> >> Failed to invoke testing
>> >
>> > Please see testmgr.h for usage (especially the key encoding):
>> >
>> > invocation:
>> > ./kcapi -x 2 -e -c "authenc(hmac(sha1),cbc(aes))" -p
>> > 53696e676c6520626c6f636b206d7367 -k
>> > 0800010000000010000000000000000000000000000000000000000006a9214036b8a15b51
>> > 2e03d534120006 -i 3dafba429d9eb430b422da802c9fac41 -a
>> > 3dafba429d9eb430b422da802c9fac41 -l 20
>> >
>> > return:
>> > e353779c1079aeb82708942dbe77181a1b13cbaf895ee12c13c52ea3cceddcb50371a206
>> >
>> > This is the first test of hmac_sha1_aes_cbc_enc_tv_temp (RFC3601 case 1).
>> > Note, the input string of "Single block msg" was converted to hex
>> > 53696e676c6520626c6f636b206d7367 as my tool always treats all input data
>> > as
>> > hex data.
>> >
>> >> Regards
>> >> Harsh Jain
>> >>
>> >> On Tue, May 31, 2016 at 12:35 PM, Stephan Mueller <smueller@chronox.de>
>> >
>> > wrote:
>> >> > Am Dienstag, 31. Mai 2016, 12:31:16 schrieb Harsh Jain:
>> >> >
>> >> > Hi Harsh,
>> >> >
>> >> >> Hi All,
>> >> >>
>> >> >> How can we open socket of type "authenc(hmac(sha256),cbc(aes))" from
>> >> >> userspace program.I check libkcapi library. It has test programs for
>> >> >> GCM/CCM. There are 3 types of approaches to Authenticated Encryption,
>> >> >> Which of them is supported in crypto framework.
>> >> >>
>> >> >> 1) Encrypt-then-MAC (EtM)
>> >> >>
>> >> >> The plaintext is first encrypted, then a MAC is produced based on
>> >> >>
>> >> >> the resulting ciphertext. The ciphertext and its MAC are sent
>> >> >> together.
>> >> >> 2) Encrypt-and-MAC (E&M)
>> >> >>
>> >> >> A MAC is produced based on the plaintext, and the plaintext is
>> >> >>
>> >> >> encrypted without the MAC. The plaintext's MAC and the ciphertext are
>> >> >> sent together.
>> >> >>
>> >> >> 3) MAC-then-Encrypt (MtE)
>> >> >>
>> >> >> A MAC is produced based on the plaintext, then the plaintext and
>> >> >>
>> >> >> MAC are together encrypted to produce a ciphertext based on both. The
>> >> >> ciphertext (containing an encrypted MAC) is sent.
>> >> >
>> >> > The cipher types you mention refer to the implementation of authenc().
>> >> > IIRC, authenc implements EtM as this is mandated by IPSEC.
>> >> >
>> >> > When you use libkcapi, you should simply be able to use your cipher
>> >> > name
>> >> > with the AEAD API. I.e. use the examples you see for CCM or GCM and use
>> >> > those with the chosen authenc() cipher. Do you experience any issues?
>> >> >
>> >> > Ciao
>> >> > Stephan
>> >
>> > Ciao
>> > Stephan
>
>
> Ciao
> Stephan
^ permalink raw reply
* Re: [PATCH] crypto: s5p-sss - Use consistent indentation for variables and members
From: Herbert Xu @ 2016-05-31 10:19 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: davem, Vladimir Zapolskiy, linux-crypto, linux-kernel,
linux-samsung-soc, Bartlomiej Zolnierkiewicz
In-Reply-To: <1464349780-27674-1-git-send-email-k.kozlowski@samsung.com>
On Fri, May 27, 2016 at 01:49:40PM +0200, Krzysztof Kozlowski wrote:
> Bring some consistency by:
> 1. Replacing fixed-space indentation of structure members with just
> tabs.
> 2. Remove indentation in declaration of local variable between type and
> name. Driver was mixing usage of such indentation and lack of it.
> When removing indentation, reorder variables in
> reversed-christmas-tree order with first variables being initialized
> ones.
>
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Applied.
--
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/4] hw rng support for NSP SoC
From: Herbert Xu @ 2016-05-31 10:19 UTC (permalink / raw)
To: Yendapally Reddy Dhananjaya Reddy
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Stephen Warren, Lee Jones, Eric Anholt, Russell King, Ray Jui,
Scott Branden, Jon Mason, Matt Mackall, Daniel Thompson,
Kieran Bingham, Pankaj Dev, Richard Weinberger, noltari,
Joshua Henderson, devicetree, linux-rpi-kernel, linux-arm-kernel,
linux-kernel, bcm-kernel-feedback-list, linux-crypto
In-Reply-To: <1464343841-29504-1-git-send-email-yendapally.reddy@broadcom.com>
On Fri, May 27, 2016 at 06:10:37AM -0400, Yendapally Reddy Dhananjaya Reddy wrote:
> This patchset contains the hw random number generator support for the
> Broadcom's NSP SoC. The block is similar to the block available in
> bcm2835 with different default interrupt mask value. Due to lack of
> documentation, I cannot confirm the interrupt mask register details
> in bcm2835. In an effort to not break the existing functionality of
> bcm2835, I used a different compatible string to mask the interrupt
> for NSP SoC. Please let me know. Also supported providing requested
> number of random numbers instead of static size of four bytes.
>
> The first patch contains the documentation changes and the second patch
> contains the support for rng available in NSP SoC. The third patch
> contains the device tree changes for NSP SoC. The fourth patch contains
> the support for reading requested number of random numbers.
>
> This patch set has been tested on NSP bcm958625HR board.
> This patch set is based on v4.6.0-rc1 and is available from github
> repo: https://github.com/Broadcom/cygnus-linux.git
> branch: nsp-rng-v2
>
> Changes since v1
All applied.
--
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 0/5] refactor mpi_read_from_buffer()
From: Herbert Xu @ 2016-05-31 10:19 UTC (permalink / raw)
To: Nicolai Stange
Cc: David Howells, Tadeusz Struk, Michal Marek, linux-crypto,
linux-kernel
In-Reply-To: <1464297595-24032-1-git-send-email-nicstange@gmail.com>
On Thu, May 26, 2016 at 11:19:50PM +0200, Nicolai Stange wrote:
> mpi_read_from_buffer() and mpi_read_raw_data() do almost the same and share a
> fair amount of common code.
>
> This patchset attempts to rewrite mpi_read_from_buffer() in order to implement
> it in terms of mpi_read_raw_data().
>
> The patches 1 and 3, i.e.
> "lib/mpi: mpi_read_from_buffer(): return error code"
> and
> "lib/mpi: mpi_read_from_buffer(): return -EINVAL upon too short buffer"
> do the groundwork in that they move any error detection unique to
> mpi_read_from_buffer() out of the data handling loop.
>
> The patches 2 and 4, that is
> "lib/digsig: digsig_verify_rsa(): return -EINVAL if modulo length is zero"
> and
> "lib/mpi: mpi_read_from_buffer(): sanitize short buffer printk"
> are not strictly necessary for the refactoring: they cleanup some minor oddities
> related to error handling I came across.
>
> Finally, the last patch in this series,
> "lib/mpi: refactor mpi_read_from_buffer() in terms of mpi_read_raw_data()"
> actually does what this series is all about.
>
>
> Applicable to linux-next-20160325.
All applied.
--
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 1/2] lib/mpi: mpi_read_raw_data(): purge redundant clearing of nbits
From: Herbert Xu @ 2016-05-31 10:18 UTC (permalink / raw)
To: Nicolai Stange; +Cc: Tadeusz Struk, Michal Marek, linux-crypto, linux-kernel
In-Reply-To: <1464260732-4446-1-git-send-email-nicstange@gmail.com>
On Thu, May 26, 2016 at 01:05:31PM +0200, Nicolai Stange wrote:
> In mpi_read_raw_data(), unsigned nbits is calculated as follows:
>
> nbits = nbytes * 8;
>
> and redundantly cleared later on if nbytes == 0:
>
> if (nbytes > 0)
> ...
> else
> nbits = 0;
>
> Purge this redundant clearing for the sake of clarity.
>
> Signed-off-by: Nicolai Stange <nicstange@gmail.com>
Both applied.
--
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] lib/mpi: purge mpi_set_buffer()
From: Herbert Xu @ 2016-05-31 10:18 UTC (permalink / raw)
To: Nicolai Stange
Cc: Dmitry Kasatkin, Tadeusz Struk, LABBE Corentin, Michal Marek,
linux-crypto, linux-kernel
In-Reply-To: <1464260270-3525-1-git-send-email-nicstange@gmail.com>
On Thu, May 26, 2016 at 12:57:50PM +0200, Nicolai Stange wrote:
> mpi_set_buffer() has no in-tree users and similar functionality is provided
> by mpi_read_raw_data().
>
> Remove mpi_set_buffer().
>
> Signed-off-by: Nicolai Stange <nicstange@gmail.com>
Applied.
--
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] hwrng: stm32: fix maybe uninitialized variable warning
From: Herbert Xu @ 2016-05-31 10:18 UTC (permalink / raw)
To: Maxime Coquelin
Cc: Matt Mackall, Sudip Mukherjee, Arnd Bergmann, Daniel Thompson,
linux-kernel, linux-crypto, linux-arm-kernel
In-Reply-To: <1464255297-21090-1-git-send-email-mcoquelin.stm32@gmail.com>
On Thu, May 26, 2016 at 11:34:57AM +0200, Maxime Coquelin wrote:
> This patch fixes the following warning:
> drivers/char/hw_random/stm32-rng.c: In function 'stm32_rng_read':
> drivers/char/hw_random/stm32-rng.c:82:19: warning: 'sr' may be used
> uninitialized in this function
>
> Reported-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
> Suggested-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Daniel Thompson <daniel.thompson@linaro.org>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Applied.
--
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 19/54] MAINTAINERS: Add file patterns for rng device tree bindings
From: Herbert Xu @ 2016-05-31 10:16 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: devicetree, linux-kernel, Matt Mackall, linux-crypto
In-Reply-To: <1463907991-7916-20-git-send-email-geert@linux-m68k.org>
On Sun, May 22, 2016 at 11:05:56AM +0200, Geert Uytterhoeven wrote:
> Submitters of device tree binding documentation may forget to CC
> the subsystem maintainer if this is missing.
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Applied.
--
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 0211/1529] Fix typo
From: Herbert Xu @ 2016-05-31 10:16 UTC (permalink / raw)
To: Andrea Gelmini
Cc: trivial, davem, benh, paulus, mpe, linux-crypto, linuxppc-dev
In-Reply-To: <20160521120338.10915-1-andrea.gelmini@gelma.net>
On Sat, May 21, 2016 at 02:03:38PM +0200, Andrea Gelmini wrote:
> Signed-off-by: Andrea Gelmini <andrea.gelmini@gelma.net>
Applied.
--
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 14/54] MAINTAINERS: Add file patterns for crypto device tree bindings
From: Herbert Xu @ 2016-05-31 10:16 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: devicetree, linux-kernel, David S. Miller, linux-crypto
In-Reply-To: <1463907991-7916-15-git-send-email-geert@linux-m68k.org>
On Sun, May 22, 2016 at 11:05:51AM +0200, Geert Uytterhoeven wrote:
> Submitters of device tree binding documentation may forget to CC
> the subsystem maintainer if this is missing.
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Applied.
--
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 0010/1529] Fix typo
From: Herbert Xu @ 2016-05-31 10:15 UTC (permalink / raw)
To: Andrea Gelmini; +Cc: trivial, davem, corbet, linux-crypto, linux-doc
In-Reply-To: <20160521113643.31792-1-andrea.gelmini@gelma.net>
On Sat, May 21, 2016 at 01:36:43PM +0200, Andrea Gelmini wrote:
> Signed-off-by: Andrea Gelmini <andrea.gelmini@gelma.net>
Applied.
--
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 v3 0/8] crypto: caam - add support for LS1043A SoC
From: Herbert Xu @ 2016-05-31 10:15 UTC (permalink / raw)
To: Horia Geantă
Cc: Shawn Guo, Rob Herring, Olof Johansson, Arnd Bergmann,
Catalin Marinas, Michael Ellerman, linux-crypto, David S. Miller,
linux-kernel
In-Reply-To: <1463670405-1059-1-git-send-email-horia.geanta@nxp.com>
On Thu, May 19, 2016 at 06:06:45PM +0300, Horia Geantă wrote:
> v3:
> -DT maintainers - please ack patch 8/8 "arm64: dts: ls1043a: add crypto node"
> (to go into kernel 4.8 via crypto tree)
> -Fixed typo in pdb.h: s/be32/__be32
> -Appended Acks (from v2) into commit messages
> -Tested that current patch set works on top of RSA support being added by
> Tudor Ambarus:
> [PATCH v6 0/3] crypto: caam - add support for RSA algorithm
> https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg19085.html
Patches 1 through 7 applied.
--
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: qat - fix typos sizeof for ctx
From: Herbert Xu @ 2016-05-31 10:15 UTC (permalink / raw)
To: Tadeusz Struk; +Cc: linux-crypto
In-Reply-To: <1463507631-5789-1-git-send-email-tadeusz.struk@intel.com>
On Tue, May 17, 2016 at 10:53:51AM -0700, Tadeusz Struk wrote:
> The sizeof(*ctx->dec_cd) and sizeof(*ctx->enc_cd) are equal,
> but we should use the correct one for freeing memory anyway.
>
> Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
Applied.
--
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: user - no parsing of CRYPTO_MSG_GETALG
From: Herbert Xu @ 2016-05-31 10:14 UTC (permalink / raw)
To: Stephan Mueller; +Cc: Steffen Klassert, linux-crypto
In-Reply-To: <2794859.sgsFI1z3Ep@positron.chronox.de>
On Mon, May 16, 2016 at 02:53:36AM +0200, Stephan Mueller wrote:
> The CRYPTO_MSG_GETALG netlink message type provides a buffer to the
> kernel to retrieve information from the kernel. The data buffer will not
> provide any input and will not be read. Hence the nlmsg_parse is not
> applicable to this netlink message type.
>
> This patch fixes the following kernel log message when using this
> netlink interface:
>
> netlink: 208 bytes leftover after parsing attributes in process `XXX'.
>
> Patch successfully tested with libkcapi from [1] which uses
> CRYPTO_MSG_GETALG to obtain cipher-specific information from the kernel.
>
> [1] http://www.chronox.de/libkcapi.html
>
> Signed-off-by: Stephan Mueller <smueller@chronox.de>
Applied.
--
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: Intel SHA - add MODULE_ALIAS
From: Herbert Xu @ 2016-05-31 10:13 UTC (permalink / raw)
To: Stephan Mueller; +Cc: linux-crypto
In-Reply-To: <2277976.2OBcIJC5tF@positron.chronox.de>
On Fri, May 13, 2016 at 02:02:00PM +0200, Stephan Mueller wrote:
> Add the MODULE_ALIAS for the cra_driver_name of the different ciphers to
> allow an automated loading if a driver name is used.
>
> Signed-off-by: Stephan Mueller <smueller@chronox.de>
Applied.
--
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 2/6] crypto: talitos - making mapping helpers more generic
From: Herbert Xu @ 2016-05-31 9:46 UTC (permalink / raw)
To: Christophe Leroy
Cc: Kim Phillips, David S Miller, linux-kernel, linuxppc-dev,
linux-crypto
In-Reply-To: <26474a2b44e69a0dbff43dbeed030ab5adef81db.1464330501.git.christophe.leroy@c-s.fr>
On Fri, May 27, 2016 at 11:32:36AM +0200, Christophe Leroy wrote:
>
> + sg_count = sg_to_link_tbl_offset(src, sg_count, offset, len,
> + &edesc->link_tbl[tbl_off])
> + if (sg_count == 1) {
> + /* Only one segment now, so no link tbl needed*/
> + copy_talitos_ptr(ptr, &edesc->link_tbl[tbl_off], is_sec1);
> + return sg_count;
> + }
This patch doesn't build.
--
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] KEYS: Add placeholder for KDF usage with DH
From: David Howells @ 2016-05-31 9:37 UTC (permalink / raw)
To: jmorris
Cc: dhowells, Mat Martineau, Stephan Mueller, keyrings, linux-crypto,
linux-security-module
In-Reply-To: <9470.1464302447@warthog.procyon.org.uk>
Hi James,
> Could you pass this along to Linus as soon as possible, please? This
> alters a new keyctl function added in the current merge window to allow for
> a future extension planned for the next merge window.
Is this likely to go to Linus before -rc2? If not, we'll need to do things
differently.
David
^ permalink raw reply
* Re: Test AEAD/authenc algorithms from userspace
From: Stephan Mueller @ 2016-05-31 9:21 UTC (permalink / raw)
To: Harsh Jain; +Cc: linux-crypto
In-Reply-To: <CAFXBA=mfw3tcftwo9nEihJHVKQzdRVg3HXJOkn8CT5VtYNxbxQ@mail.gmail.com>
Am Dienstag, 31. Mai 2016, 14:45:27 schrieb Harsh Jain:
Hi Harsh,
> Hi,
>
> Thanks Stephen, I will check the same.1 suggestion for kcapi tool. Add
> some switch cases in tool to test digest and finup path of crypto
> driver. Current implementation triggers only init/update/final.
You mean for hashes? I guess the following is what you refer to? This logic is
even found for the other cipher types (symmetric algos, AEAD ciphers). See the
documentation on stream vs one-shot use cases.
/**
* kcapi_md_init() - initialize cipher handle
* @handle: cipher handle filled during the call - output
* @ciphername: kernel crypto API cipher name as specified in
* /proc/crypto - input
* @flags: flags specifying the type of cipher handle
*
* This function provides the initialization of a (keyed) message digest
handle
* and establishes the connection to the kernel.
*
* Return: 0 upon success; ENOENT - algorithm not available;
* -EOPNOTSUPP - AF_ALG family not available;
* -EINVAL - accept syscall failed
* -ENOMEM - cipher handle cannot be allocated
*/
int kcapi_md_init(struct kcapi_handle **handle, const char *ciphername,
uint32_t flags);
/**
* kcapi_md_update() - message digest update function (stream)
* @handle: cipher handle - input
* @buffer: holding the data to add to the message digest - input
* @len: buffer length - input
*
* Return: 0 upon success;
* < 0 in case of error
*/
int32_t kcapi_md_update(struct kcapi_handle *handle,
const uint8_t *buffer, uint32_t len);
/**
* kcapi_md_final() - message digest finalization function (stream)
* @handle: cipher handle - input
* @buffer: filled with the message digest - output
* @len: buffer length - input
*
* Return: size of message digest upon success;
* -EIO - data cannot be obtained;
* -ENOMEM - buffer is too small for the complete message digest,
* the buffer is filled with the truncated message digest
*/
int32_t kcapi_md_final(struct kcapi_handle *handle,
uint8_t *buffer, uint32_t len);
The test/kcapi tool is a crude test tool that I use for my regression testing.
It is not intended for anything else.
>
>
> Regards
> Harsh Jain
>
> On Tue, May 31, 2016 at 2:29 PM, Stephan Mueller <smueller@chronox.de>
wrote:
> > Am Dienstag, 31. Mai 2016, 14:10:20 schrieb Harsh Jain:
> >
> > Hi Harsh,
> >
> >> Hi,
> >>
> >> You means to say like this
> >>
> >> ./kcapi -x 2 -e -c "authenc(hmac(sha1),cbc(aes))" -p
> >> 48981da18e4bb9ef7e2e3162d16b19108b19050f66582cb7f7e4b6c873819b71 -k
> >> 8d7dd9b0170ce0b5f2f8e1aa768e01e91da8bfc67fd486d081b28254c99eb423 -i
> >> 7fbc02ebf5b93322329df9bfccb635af -a afcd7202d621e06ca53b70c2bdff7fb2
> >> -l 16f4a3eacfbdadd3b1a17117b1d67ffc1f1e21efbbc6d83724a8c296e3bb8cda0c44
> >>
> >> It gives following error with kernel 4.5.2
> >> Symmetric cipher setkey failed
> >> Failed to invoke testing
> >
> > Please see testmgr.h for usage (especially the key encoding):
> >
> > invocation:
> > ./kcapi -x 2 -e -c "authenc(hmac(sha1),cbc(aes))" -p
> > 53696e676c6520626c6f636b206d7367 -k
> > 0800010000000010000000000000000000000000000000000000000006a9214036b8a15b51
> > 2e03d534120006 -i 3dafba429d9eb430b422da802c9fac41 -a
> > 3dafba429d9eb430b422da802c9fac41 -l 20
> >
> > return:
> > e353779c1079aeb82708942dbe77181a1b13cbaf895ee12c13c52ea3cceddcb50371a206
> >
> > This is the first test of hmac_sha1_aes_cbc_enc_tv_temp (RFC3601 case 1).
> > Note, the input string of "Single block msg" was converted to hex
> > 53696e676c6520626c6f636b206d7367 as my tool always treats all input data
> > as
> > hex data.
> >
> >> Regards
> >> Harsh Jain
> >>
> >> On Tue, May 31, 2016 at 12:35 PM, Stephan Mueller <smueller@chronox.de>
> >
> > wrote:
> >> > Am Dienstag, 31. Mai 2016, 12:31:16 schrieb Harsh Jain:
> >> >
> >> > Hi Harsh,
> >> >
> >> >> Hi All,
> >> >>
> >> >> How can we open socket of type "authenc(hmac(sha256),cbc(aes))" from
> >> >> userspace program.I check libkcapi library. It has test programs for
> >> >> GCM/CCM. There are 3 types of approaches to Authenticated Encryption,
> >> >> Which of them is supported in crypto framework.
> >> >>
> >> >> 1) Encrypt-then-MAC (EtM)
> >> >>
> >> >> The plaintext is first encrypted, then a MAC is produced based on
> >> >>
> >> >> the resulting ciphertext. The ciphertext and its MAC are sent
> >> >> together.
> >> >> 2) Encrypt-and-MAC (E&M)
> >> >>
> >> >> A MAC is produced based on the plaintext, and the plaintext is
> >> >>
> >> >> encrypted without the MAC. The plaintext's MAC and the ciphertext are
> >> >> sent together.
> >> >>
> >> >> 3) MAC-then-Encrypt (MtE)
> >> >>
> >> >> A MAC is produced based on the plaintext, then the plaintext and
> >> >>
> >> >> MAC are together encrypted to produce a ciphertext based on both. The
> >> >> ciphertext (containing an encrypted MAC) is sent.
> >> >
> >> > The cipher types you mention refer to the implementation of authenc().
> >> > IIRC, authenc implements EtM as this is mandated by IPSEC.
> >> >
> >> > When you use libkcapi, you should simply be able to use your cipher
> >> > name
> >> > with the AEAD API. I.e. use the examples you see for CCM or GCM and use
> >> > those with the chosen authenc() cipher. Do you experience any issues?
> >> >
> >> > Ciao
> >> > Stephan
> >
> > Ciao
> > Stephan
Ciao
Stephan
^ permalink raw reply
* Re: Test AEAD/authenc algorithms from userspace
From: Harsh Jain @ 2016-05-31 9:15 UTC (permalink / raw)
To: Stephan Mueller; +Cc: linux-crypto
In-Reply-To: <2892187.M1JfTODgdh@tauon.atsec.com>
Hi,
Thanks Stephen, I will check the same.1 suggestion for kcapi tool. Add
some switch cases in tool to test digest and finup path of crypto
driver. Current implementation triggers only init/update/final.
Regards
Harsh Jain
On Tue, May 31, 2016 at 2:29 PM, Stephan Mueller <smueller@chronox.de> wrote:
> Am Dienstag, 31. Mai 2016, 14:10:20 schrieb Harsh Jain:
>
> Hi Harsh,
>
>> Hi,
>>
>> You means to say like this
>>
>> ./kcapi -x 2 -e -c "authenc(hmac(sha1),cbc(aes))" -p
>> 48981da18e4bb9ef7e2e3162d16b19108b19050f66582cb7f7e4b6c873819b71 -k
>> 8d7dd9b0170ce0b5f2f8e1aa768e01e91da8bfc67fd486d081b28254c99eb423 -i
>> 7fbc02ebf5b93322329df9bfccb635af -a afcd7202d621e06ca53b70c2bdff7fb2
>> -l 16f4a3eacfbdadd3b1a17117b1d67ffc1f1e21efbbc6d83724a8c296e3bb8cda0c44
>>
>> It gives following error with kernel 4.5.2
>> Symmetric cipher setkey failed
>> Failed to invoke testing
>>
>
> Please see testmgr.h for usage (especially the key encoding):
>
> invocation:
> ./kcapi -x 2 -e -c "authenc(hmac(sha1),cbc(aes))" -p
> 53696e676c6520626c6f636b206d7367 -k
> 0800010000000010000000000000000000000000000000000000000006a9214036b8a15b512e03d534120006
> -i 3dafba429d9eb430b422da802c9fac41 -a 3dafba429d9eb430b422da802c9fac41 -l 20
>
> return:
> e353779c1079aeb82708942dbe77181a1b13cbaf895ee12c13c52ea3cceddcb50371a206
>
> This is the first test of hmac_sha1_aes_cbc_enc_tv_temp (RFC3601 case 1).
> Note, the input string of "Single block msg" was converted to hex
> 53696e676c6520626c6f636b206d7367 as my tool always treats all input data as
> hex data.
>
>>
>>
>> Regards
>> Harsh Jain
>>
>> On Tue, May 31, 2016 at 12:35 PM, Stephan Mueller <smueller@chronox.de>
> wrote:
>> > Am Dienstag, 31. Mai 2016, 12:31:16 schrieb Harsh Jain:
>> >
>> > Hi Harsh,
>> >
>> >> Hi All,
>> >>
>> >> How can we open socket of type "authenc(hmac(sha256),cbc(aes))" from
>> >> userspace program.I check libkcapi library. It has test programs for
>> >> GCM/CCM. There are 3 types of approaches to Authenticated Encryption,
>> >> Which of them is supported in crypto framework.
>> >>
>> >> 1) Encrypt-then-MAC (EtM)
>> >>
>> >> The plaintext is first encrypted, then a MAC is produced based on
>> >>
>> >> the resulting ciphertext. The ciphertext and its MAC are sent
>> >> together.
>> >> 2) Encrypt-and-MAC (E&M)
>> >>
>> >> A MAC is produced based on the plaintext, and the plaintext is
>> >>
>> >> encrypted without the MAC. The plaintext's MAC and the ciphertext are
>> >> sent together.
>> >>
>> >> 3) MAC-then-Encrypt (MtE)
>> >>
>> >> A MAC is produced based on the plaintext, then the plaintext and
>> >>
>> >> MAC are together encrypted to produce a ciphertext based on both. The
>> >> ciphertext (containing an encrypted MAC) is sent.
>> >
>> > The cipher types you mention refer to the implementation of authenc().
>> > IIRC, authenc implements EtM as this is mandated by IPSEC.
>> >
>> > When you use libkcapi, you should simply be able to use your cipher name
>> > with the AEAD API. I.e. use the examples you see for CCM or GCM and use
>> > those with the chosen authenc() cipher. Do you experience any issues?
>> >
>> > Ciao
>> > Stephan
>
>
> Ciao
> Stephan
^ permalink raw reply
* Re: Test AEAD/authenc algorithms from userspace
From: Stephan Mueller @ 2016-05-31 8:59 UTC (permalink / raw)
To: Harsh Jain; +Cc: linux-crypto
In-Reply-To: <CAFXBA=mHcTorQaTfgkk-gfXf0LSae1hetPe=pJ_05sHJydaJcw@mail.gmail.com>
Am Dienstag, 31. Mai 2016, 14:10:20 schrieb Harsh Jain:
Hi Harsh,
> Hi,
>
> You means to say like this
>
> ./kcapi -x 2 -e -c "authenc(hmac(sha1),cbc(aes))" -p
> 48981da18e4bb9ef7e2e3162d16b19108b19050f66582cb7f7e4b6c873819b71 -k
> 8d7dd9b0170ce0b5f2f8e1aa768e01e91da8bfc67fd486d081b28254c99eb423 -i
> 7fbc02ebf5b93322329df9bfccb635af -a afcd7202d621e06ca53b70c2bdff7fb2
> -l 16f4a3eacfbdadd3b1a17117b1d67ffc1f1e21efbbc6d83724a8c296e3bb8cda0c44
>
> It gives following error with kernel 4.5.2
> Symmetric cipher setkey failed
> Failed to invoke testing
>
Please see testmgr.h for usage (especially the key encoding):
invocation:
./kcapi -x 2 -e -c "authenc(hmac(sha1),cbc(aes))" -p
53696e676c6520626c6f636b206d7367 -k
0800010000000010000000000000000000000000000000000000000006a9214036b8a15b512e03d534120006
-i 3dafba429d9eb430b422da802c9fac41 -a 3dafba429d9eb430b422da802c9fac41 -l 20
return:
e353779c1079aeb82708942dbe77181a1b13cbaf895ee12c13c52ea3cceddcb50371a206
This is the first test of hmac_sha1_aes_cbc_enc_tv_temp (RFC3601 case 1).
Note, the input string of "Single block msg" was converted to hex
53696e676c6520626c6f636b206d7367 as my tool always treats all input data as
hex data.
>
>
> Regards
> Harsh Jain
>
> On Tue, May 31, 2016 at 12:35 PM, Stephan Mueller <smueller@chronox.de>
wrote:
> > Am Dienstag, 31. Mai 2016, 12:31:16 schrieb Harsh Jain:
> >
> > Hi Harsh,
> >
> >> Hi All,
> >>
> >> How can we open socket of type "authenc(hmac(sha256),cbc(aes))" from
> >> userspace program.I check libkcapi library. It has test programs for
> >> GCM/CCM. There are 3 types of approaches to Authenticated Encryption,
> >> Which of them is supported in crypto framework.
> >>
> >> 1) Encrypt-then-MAC (EtM)
> >>
> >> The plaintext is first encrypted, then a MAC is produced based on
> >>
> >> the resulting ciphertext. The ciphertext and its MAC are sent
> >> together.
> >> 2) Encrypt-and-MAC (E&M)
> >>
> >> A MAC is produced based on the plaintext, and the plaintext is
> >>
> >> encrypted without the MAC. The plaintext's MAC and the ciphertext are
> >> sent together.
> >>
> >> 3) MAC-then-Encrypt (MtE)
> >>
> >> A MAC is produced based on the plaintext, then the plaintext and
> >>
> >> MAC are together encrypted to produce a ciphertext based on both. The
> >> ciphertext (containing an encrypted MAC) is sent.
> >
> > The cipher types you mention refer to the implementation of authenc().
> > IIRC, authenc implements EtM as this is mandated by IPSEC.
> >
> > When you use libkcapi, you should simply be able to use your cipher name
> > with the AEAD API. I.e. use the examples you see for CCM or GCM and use
> > those with the chosen authenc() cipher. Do you experience any issues?
> >
> > Ciao
> > Stephan
Ciao
Stephan
^ permalink raw reply
* RE: [PATCH v5 2/3] crypto: kpp - Add DH software implementation
From: Benedetto, Salvatore @ 2016-05-31 8:56 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto@vger.kernel.org, Benedetto, Salvatore
In-Reply-To: <20160531065256.GB13948@gondor.apana.org.au>
> -----Original Message-----
> From: Herbert Xu [mailto:herbert@gondor.apana.org.au]
> Sent: Tuesday, May 31, 2016 7:53 AM
> To: Benedetto, Salvatore <salvatore.benedetto@intel.com>
> Cc: linux-crypto@vger.kernel.org
> Subject: Re: [PATCH v5 2/3] crypto: kpp - Add DH software implementation
>
> On Mon, May 09, 2016 at 10:40:40PM +0100, Salvatore Benedetto wrote:
> >
> > +static int dh_set_params(struct crypto_kpp *tfm, void *buffer,
> > + unsigned int len)
> > +{
> > + struct dh_ctx *ctx = dh_get_ctx(tfm);
> > + struct dh_params *params = (struct dh_params *)buffer;
> > +
> > + if (unlikely(!buffer || !len))
> > + return -EINVAL;
>
> What's the point of len? It's never checked anywhere apart from this non-
> zero check which is pointless. Just get rid of it.
When I first created the API I thought it would be useful to validate the given
buffer in case the user passed in the wrong structure. The actual check would
have been
If (unlikely(!len && len != sizeof(struct dh_params))
return -EINVAL;
but I agree I don't see much value in that now. I'll remove it.
Regards,
Salvatore
^ permalink raw reply
* RE: [PATCH v5 3/3] crypto: kpp - Add ECDH software support
From: Benedetto, Salvatore @ 2016-05-31 8:41 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto@vger.kernel.org, Benedetto, Salvatore
In-Reply-To: <20160531065525.GC13948@gondor.apana.org.au>
> -----Original Message-----
> From: Herbert Xu [mailto:herbert@gondor.apana.org.au]
> Sent: Tuesday, May 31, 2016 7:55 AM
> To: Benedetto, Salvatore <salvatore.benedetto@intel.com>
> Cc: linux-crypto@vger.kernel.org
> Subject: Re: [PATCH v5 3/3] crypto: kpp - Add ECDH software support
>
> On Mon, May 09, 2016 at 10:40:41PM +0100, Salvatore Benedetto wrote:
> >
> > + do {
> > + if (tries++ >= MAX_TRIES)
> > + goto err_retries;
> > +
> > + ecc_point_mult(pk, &curve->g, priv, NULL, curve->p, ndigits);
> > +
> > + } while (ecc_point_is_zero(pk));
>
> You might want to read this again. The original code did this because it
> changed the private key in the loop, in your code priv is constant...
Yep, I'll fix that. Thanks for reviewing.
Salvatore
^ permalink raw reply
* Re: Test AEAD/authenc algorithms from userspace
From: Harsh Jain @ 2016-05-31 8:40 UTC (permalink / raw)
To: Stephan Mueller; +Cc: linux-crypto
In-Reply-To: <2943969.IiWKeGvEyD@tauon.atsec.com>
Hi,
You means to say like this
./kcapi -x 2 -e -c "authenc(hmac(sha1),cbc(aes))" -p
48981da18e4bb9ef7e2e3162d16b19108b19050f66582cb7f7e4b6c873819b71 -k
8d7dd9b0170ce0b5f2f8e1aa768e01e91da8bfc67fd486d081b28254c99eb423 -i
7fbc02ebf5b93322329df9bfccb635af -a afcd7202d621e06ca53b70c2bdff7fb2
-l 16f4a3eacfbdadd3b1a17117b1d67ffc1f1e21efbbc6d83724a8c296e3bb8cda0c44
It gives following error with kernel 4.5.2
Symmetric cipher setkey failed
Failed to invoke testing
Regards
Harsh Jain
On Tue, May 31, 2016 at 12:35 PM, Stephan Mueller <smueller@chronox.de> wrote:
> Am Dienstag, 31. Mai 2016, 12:31:16 schrieb Harsh Jain:
>
> Hi Harsh,
>
>> Hi All,
>>
>> How can we open socket of type "authenc(hmac(sha256),cbc(aes))" from
>> userspace program.I check libkcapi library. It has test programs for
>> GCM/CCM. There are 3 types of approaches to Authenticated Encryption,
>> Which of them is supported in crypto framework.
>>
>> 1) Encrypt-then-MAC (EtM)
>> The plaintext is first encrypted, then a MAC is produced based on
>> the resulting ciphertext. The ciphertext and its MAC are sent
>> together.
>> 2) Encrypt-and-MAC (E&M)
>> A MAC is produced based on the plaintext, and the plaintext is
>> encrypted without the MAC. The plaintext's MAC and the ciphertext are
>> sent together.
>>
>> 3) MAC-then-Encrypt (MtE)
>> A MAC is produced based on the plaintext, then the plaintext and
>> MAC are together encrypted to produce a ciphertext based on both. The
>> ciphertext (containing an encrypted MAC) is sent.
>
> The cipher types you mention refer to the implementation of authenc(). IIRC,
> authenc implements EtM as this is mandated by IPSEC.
>
> When you use libkcapi, you should simply be able to use your cipher name with
> the AEAD API. I.e. use the examples you see for CCM or GCM and use those with
> the chosen authenc() cipher. Do you experience any issues?
>
> Ciao
> Stephan
^ permalink raw reply
* Re: [PATCH 1/7] crypto : stylistic cleanup in sha1-mb
From: Herbert Xu @ 2016-05-31 8:13 UTC (permalink / raw)
To: Megha Dey
Cc: tim.c.chen, davem, linux-crypto, linux-kernel, fenghua.yu,
Megha Dey
In-Reply-To: <1463704984-2136-1-git-send-email-megha.dey@intel.com>
On Thu, May 19, 2016 at 05:43:04PM -0700, Megha Dey wrote:
> From: Megha Dey <megha.dey@linux.intel.com>
>
> Currently there are several checkpatch warnings in the sha1_mb.c file:
> 'WARNING: line over 80 characters' in the sha1_mb.c file. Also, the
> syntax of some multi-line comments are not correct. This patch fixes
> these issues.
>
> Signed-off-by: Megha Dey <megha.dey@linux.intel.com>
This patch says 1/7 but there is no cover letter and I've only
seen patches 1 and 2. What's going on?
Cheers,
--
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