On Wed, Jun 22, 2016 at 06:37:50AM +, Benedetto, Salvatore wrote:
>
> Can you explain me the benefit in doing so?
The less code we have the better. Most of our algorithm types
have a single test function, I have seen no reason why kpp should
be different.
akcipher has been an anomaly and I'm
> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org [mailto:linux-crypto-
> ow...@vger.kernel.org] On Behalf Of Herbert Xu
> Sent: Wednesday, June 22, 2016 1:51 AM
> To: Benedetto, Salvatore
> Cc: linux-crypto@vger.kernel.org
> Subject: Re: [PATCH v10 2/3] crypto: kpp - Add D
Am Dienstag, 21. Juni 2016, 15:31:07 schrieb Austin S. Hemmelgarn:
Hi Austin,
> > Little data, interesting statement for results on 200+ systems including
> > all major CPU arches all showing information leading in the same
> > directions.
> Let me try rephrasing this to make it a bit clearer:
>
From: Megha Dey
Herbert wants the sha1-mb algorithm to have an async implementation:
https://lkml.org/lkml/2016/4/5/286.
Currently, sha1-mb uses an async interface for the outer algorithm
and a sync interface for the inner algorithm. This patch introduces
a async interface for even the inner algo
On Tue, Jun 21, 2016 at 10:43:40AM -0700, Andy Lutomirski wrote:
>
> Is there a straightforward way that bluetooth and, potentially, other
> drivers can just do synchronous crypto in a small buffer specified by
> its virtual address? The actual cryptography part of the crypto code
> already works
On Tue, Jun 21, 2016 at 5:42 PM, Herbert Xu wrote:
> On Tue, Jun 21, 2016 at 10:43:40AM -0700, Andy Lutomirski wrote:
>>
>> Is there a straightforward way that bluetooth and, potentially, other
>> drivers can just do synchronous crypto in a small buffer specified by
>> its virtual address? The ac
On Tue, Jun 21, 2016 at 09:45:30PM +0100, Salvatore Benedetto wrote:
>
> +
> +static int test_dh(struct crypto_kpp *tfm, struct kpp_testvec_dh *vecs,
> +unsigned int tcount)
> +{
> + int ret, i;
Please make the kpp test function generic. I'm trying to kill
the RSA-specific tes
* Implement MPI based Diffie-Hellman under kpp API
* Test provided uses data generad by OpenSSL
Signed-off-by: Salvatore Benedetto
---
crypto/Kconfig | 8 ++
crypto/Makefile | 4 +
crypto/dh.c | 189 ++
crypto/dh_helper.c |
Add key-agreement protocol primitives (kpp) API which allows to
implement primitives required by protocols such as DH and ECDH.
The API is composed mainly by the following functions
* set_secret() - It allows the user to set his secret, also
referred to as his private key, along with the parame
> -Original Message-
> From: Herbert Xu [mailto:herb...@gondor.apana.org.au]
> Sent: Tuesday, June 21, 2016 12:49 AM
> To: Benedetto, Salvatore
> Cc: linux-crypto@vger.kernel.org
> Subject: Re: [PATCH v9 2/3] crypto: kpp - Add DH software implementation
>
> On Mon, Jun 20, 2016 at 11:43:2
Hi Herb,
the following patchset introduces a new API for abstracting key-agreement
protocols such as DH and ECDH. It provides the primitives required for
implementing
the protocol, thus the name KPP (Key-agreement Protocol Primitives).
Regards,
Salvatore
Changes from v9:
* Fix encoding/decoding
* Implement ECDH under kpp API
* Provide ECC software support for curve P-192 and
P-256.
* Add kpp test for ECDH with data generated by OpenSSL
Signed-off-by: Salvatore Benedetto
---
crypto/Kconfig |5 +
crypto/Makefile |4 +
crypto/ecc.c| 1018
Hi,
I am Amanda,
Would you be interested in acquiring an email list of "Moms Email List" from
USA?
We have data for Mortgage Email List, New Homeowner Email List, Online Shoppers
List, Travelers Email List and many more. Choose the best one that meets your
need. We provide you with current
On Tue, Jun 21, 2016 at 12:37 PM, Arnd Bergmann wrote:
> On Tuesday, June 21, 2016 12:05:06 PM CEST John Stultz wrote:
>> On Tue, Jun 21, 2016 at 11:49 AM, Stephan Mueller
>> wrote:
>> > Am Dienstag, 21. Juni 2016, 11:11:42 schrieb John Stultz:
>> >
>> > Hi John,
>> >
>> >> I don't see in the ab
On Tuesday, June 21, 2016 12:05:06 PM CEST John Stultz wrote:
> On Tue, Jun 21, 2016 at 11:49 AM, Stephan Mueller wrote:
> > Am Dienstag, 21. Juni 2016, 11:11:42 schrieb John Stultz:
> >
> > Hi John,
> >
> >> I don't see in the above an explanation of *why* you're using
> >> ktime_get_raw_ns() ins
On 2016-06-21 14:04, Stephan Mueller wrote:
Am Dienstag, 21. Juni 2016, 13:51:15 schrieb Austin S. Hemmelgarn:
6. You have a significant lack of data regarding embedded systems, which
is one of the two biggest segments of Linux's market share. You list no
results for any pre-ARMv6 systems (Linu
On Tue, Jun 21, 2016 at 11:49 AM, Stephan Mueller wrote:
> Am Dienstag, 21. Juni 2016, 11:11:42 schrieb John Stultz:
>
> Hi John,
>
>> I don't see in the above an explanation of *why* you're using
>> ktime_get_raw_ns() instead of ktime_get_ns().
>
> Could you help me understand what the difference
Am Dienstag, 21. Juni 2016, 11:11:42 schrieb John Stultz:
Hi John,
> I don't see in the above an explanation of *why* you're using
> ktime_get_raw_ns() instead of ktime_get_ns().
Could you help me understand what the difference is or point me to some
documentation? I understood that we only tal
Am Dienstag, 21. Juni 2016, 14:22:48 schrieb Austin S. Hemmelgarn:
Hi Austin,
> On 2016-06-21 12:28, Stephan Mueller wrote:
> > Am Dienstag, 21. Juni 2016, 12:03:56 schrieb Austin S. Hemmelgarn:
> >
> > Hi Austin,
> >
> >> On 2016-06-21 03:32, Stephan Mueller wrote:
> >>> Am Dienstag, 21. Juni
On 2016-06-21 09:19, Tomas Mraz wrote:
On Út, 2016-06-21 at 09:05 -0400, Austin S. Hemmelgarn wrote:
On 2016-06-20 14:32, Stephan Mueller wrote:
[1] http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.pdf
Specific things I notice about this:
1. QEMU systems are reporting higher values than almos
On 2016-06-21 12:28, Stephan Mueller wrote:
Am Dienstag, 21. Juni 2016, 12:03:56 schrieb Austin S. Hemmelgarn:
Hi Austin,
On 2016-06-21 03:32, Stephan Mueller wrote:
Am Dienstag, 21. Juni 2016, 09:12:07 schrieb Nikos Mavrogiannopoulos:
Hi Nikos,
On Mon, Jun 20, 2016 at 5:43 PM, Stephan Mue
On Tue, Jun 21, 2016 at 11:05 AM, Stephan Mueller wrote:
> As part of the Y2038 development, __getnstimeofday is not supposed to be
> used any more. It is now replaced with ktime_get_raw_ns. Albeit
> ktime_get_raw_ns is monotonic compared to __getnstimeofday, this
> difference is irrelevant as the
Am Dienstag, 21. Juni 2016, 13:51:15 schrieb Austin S. Hemmelgarn:
Hi Austin,
>
> >> 2. Quite a few systems have a rather distressingly low lower bound and
> >> still get accepted by your algorithm (a number of the S/390 systems, and
> >> a handful of the AMD processors in particular).
> >
> >
As part of the Y2038 development, __getnstimeofday is not supposed to be
used any more. It is now replaced with ktime_get_raw_ns. Albeit
ktime_get_raw_ns is monotonic compared to __getnstimeofday, this
difference is irrelevant as the Jitter RNG uses the time stamp to
measure the execution time of a
Am Dienstag, 21. Juni 2016, 13:54:13 schrieb Austin S. Hemmelgarn:
Hi Austin,
> On 2016-06-21 13:23, Stephan Mueller wrote:
> > Am Dienstag, 21. Juni 2016, 13:18:33 schrieb Austin S. Hemmelgarn:
> >
> > Hi Austin,
> >
> >>> You have to trust the host for anything, not just for the entropy in
>
On 10/06/16 14:38, Tony Lindgren wrote:
* Tero Kristo [160601 02:09]:
From: Joel Fernandes
DRA7xx SoCs have a DES3DES IP. Add DT data for the same.
Are these dts changes safe to apply separately or do they
cause issues like extra warnings during boot?
DTS changes are fine to merge as is s
On 2016-06-21 13:23, Stephan Mueller wrote:
Am Dienstag, 21. Juni 2016, 13:18:33 schrieb Austin S. Hemmelgarn:
Hi Austin,
You have to trust the host for anything, not just for the entropy in
timings. This is completely invalid argument unless you can present a
method that one guest can manipul
On 2016-06-21 09:20, Stephan Mueller wrote:
Am Dienstag, 21. Juni 2016, 09:05:55 schrieb Austin S. Hemmelgarn:
Hi Austin,
On 2016-06-20 14:32, Stephan Mueller wrote:
Am Montag, 20. Juni 2016, 13:07:32 schrieb Austin S. Hemmelgarn:
Hi Austin,
On 2016-06-18 12:31, Stephan Mueller wrote:
Am
net/bluetooth/smp.c (in smp_e) wants to do AES-ECB on a 16-byte stack
buffer, which seems eminently reasonable to me. It does it like this:
sg_init_one(&sg, data, 16);
skcipher_request_set_tfm(req, tfm);
skcipher_request_set_callback(req, 0, NULL, NULL);
skcipher_request_set_cryp
Am Dienstag, 21. Juni 2016, 18:51:32 schrieb Stephan Mueller:
Hi,
> > So.. again, I'd avoid using the "fast" accessor unless there is a
> > clear need or obvious benefit. Which should be documented.
>
> So, you suggest ktime_get_raw_ns? If yes, let me test that for one use case.
I tested ktime_
Am Dienstag, 21. Juni 2016, 10:12:24 schrieb John Stultz:
Hi John,
>
> So this is definitely more clear then what was described earlier, and
> worries me because on many x86 machines (though fewer I guess these
> days then in the past) the clocksource will often not be the TSC (and
> have lower r
Am Dienstag, 21. Juni 2016, 13:18:33 schrieb Austin S. Hemmelgarn:
Hi Austin,
> > You have to trust the host for anything, not just for the entropy in
> > timings. This is completely invalid argument unless you can present a
> > method that one guest can manipulate timings in other guest in such
On 2016-06-21 09:42, Pavel Machek wrote:
Hi!
6. You have a significant lack of data regarding embedded systems, which is
one of the two biggest segments of Linux's market share. You list no
results for any pre-ARMv6 systems (Linux still runs on and is regularly used
on ARMv4 CPU's, and it's wo
On Tue, Jun 21, 2016 at 9:51 AM, Stephan Mueller wrote:
> Am Dienstag, 21. Juni 2016, 09:47:23 schrieb John Stultz:
>
> Hi John,
>
>> On Tue, Jun 21, 2016 at 9:34 AM, Stephan Mueller
> wrote:
>> > Am Dienstag, 21. Juni 2016, 09:22:31 schrieb John Stultz:
>> >
>> > Hi John,
>> >
>> >> On Tue, Jun
Am Dienstag, 21. Juni 2016, 09:47:23 schrieb John Stultz:
Hi John,
> On Tue, Jun 21, 2016 at 9:34 AM, Stephan Mueller
wrote:
> > Am Dienstag, 21. Juni 2016, 09:22:31 schrieb John Stultz:
> >
> > Hi John,
> >
> >> On Tue, Jun 21, 2016 at 1:32 AM, Arnd Bergmann wrote:
> >> > On Tuesday, June 2
On Tue, Jun 21, 2016 at 9:34 AM, Stephan Mueller wrote:
> Am Dienstag, 21. Juni 2016, 09:22:31 schrieb John Stultz:
>
> Hi John,
>
>> On Tue, Jun 21, 2016 at 1:32 AM, Arnd Bergmann wrote:
>> > On Tuesday, June 21, 2016 8:20:10 AM CEST Stephan Mueller wrote:
>> >> Am Freitag, 17. Juni 2016, 17:59:
On Tue, Jun 21, 2016 at 1:32 AM, Arnd Bergmann wrote:
> On Tuesday, June 21, 2016 8:20:10 AM CEST Stephan Mueller wrote:
>> Am Freitag, 17. Juni 2016, 17:59:41 schrieb Arnd Bergmann:
>>
> Compared to the previous __getnstimeofday(), the difference is
>
> - using "monotonic" timebase instead of "re
Am Dienstag, 21. Juni 2016, 09:22:31 schrieb John Stultz:
Hi John,
> On Tue, Jun 21, 2016 at 1:32 AM, Arnd Bergmann wrote:
> > On Tuesday, June 21, 2016 8:20:10 AM CEST Stephan Mueller wrote:
> >> Am Freitag, 17. Juni 2016, 17:59:41 schrieb Arnd Bergmann:
> > Compared to the previous __getnstime
Am Dienstag, 21. Juni 2016, 12:03:56 schrieb Austin S. Hemmelgarn:
Hi Austin,
> On 2016-06-21 03:32, Stephan Mueller wrote:
> > Am Dienstag, 21. Juni 2016, 09:12:07 schrieb Nikos Mavrogiannopoulos:
> >
> > Hi Nikos,
> >
> >> On Mon, Jun 20, 2016 at 5:43 PM, Stephan Mueller
> >
> > wrote:
> >>
On 2016-06-21 03:32, Stephan Mueller wrote:
Am Dienstag, 21. Juni 2016, 09:12:07 schrieb Nikos Mavrogiannopoulos:
Hi Nikos,
On Mon, Jun 20, 2016 at 5:43 PM, Stephan Mueller
wrote:
Personally, I don't really use /dev/random, nor would I recommend it
for most application programmers. At this
Hi!
> 6. You have a significant lack of data regarding embedded systems, which is
> one of the two biggest segments of Linux's market share. You list no
> results for any pre-ARMv6 systems (Linux still runs on and is regularly used
> on ARMv4 CPU's, and it's worth also pointing out that the value
On Út, 2016-06-21 at 09:05 -0400, Austin S. Hemmelgarn wrote:
> On 2016-06-20 14:32, Stephan Mueller wrote:
> >
> > [1] http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.pdf
> Specific things I notice about this:
> 1. QEMU systems are reporting higher values than almost anything
> else
> with the
Am Dienstag, 21. Juni 2016, 09:05:55 schrieb Austin S. Hemmelgarn:
Hi Austin,
> On 2016-06-20 14:32, Stephan Mueller wrote:
> > Am Montag, 20. Juni 2016, 13:07:32 schrieb Austin S. Hemmelgarn:
> >
> > Hi Austin,
> >
> >> On 2016-06-18 12:31, Stephan Mueller wrote:
> >>> Am Samstag, 18. Juni 201
On Mon, Jun 20, 2016 at 01:25:46PM -0700, Megha Dey wrote:
>
> - desc->tfm = child;
> - desc->flags = CRYPTO_TFM_REQ_MAY_SLEEP; /* check this again */
> + ahash_request_set_tfm(desc, child);
> + ahash_request_set_callback(desc, CRYPTO_TFM_REQ_MAY_SLEEP, NULL, NULL);
The callback f
On 2016-06-20 14:32, Stephan Mueller wrote:
Am Montag, 20. Juni 2016, 13:07:32 schrieb Austin S. Hemmelgarn:
Hi Austin,
On 2016-06-18 12:31, Stephan Mueller wrote:
Am Samstag, 18. Juni 2016, 10:44:08 schrieb Theodore Ts'o:
Hi Theodore,
At the end of the day, with these devices you really b
On Tue, 21 Jun 2016 10:08:39 +0200
Romain Perier wrote:
> The Cryptographic Engines and Security Accelerators (CESA) supports the
> Multi-Packet Chain Mode. With this mode enabled, multiple tdma requests
> can be chained and processed by the hardware without software
> intervention. This mode was
On Tue, 21 Jun 2016 10:08:38 +0200
Romain Perier wrote:
> This commits adds support for fine grained load balancing on
> multi-engine IPs. The engine is pre-selected based on its current load
> and on the weight of the crypto request that is about to be processed.
> The global crypto queue is als
Hi,
On So, 2016-06-18 at 10:44 -0400, Theodore Ts'o wrote:
> On Fri, Jun 17, 2016 at 03:56:13PM +0200, David Jaša wrote:
> > I was thinking along the lines that "almost every important package
> > supports FreeBSD as well where they have to handle the condition so
> > option to switch to Rather Br
The __raw IO functions are not endian safe, so use the readl_relaxed
and writel_relaxed versions of these.
Signed-off-by: Ben Dooks
---
CC: Matt Mackall
CC: Krzysztof Kozlowski
CC: linux-crypto@vger.kernel.org
CC: linux-arm-ker...@lists.infradead.org
CC: linux-samsung-...@vger.kernel.org
---
d
This patch fixes an old bug where requests can be reordered because
some are processed by cryptd while others are processed directly
in softirq context.
The fix is to always postpone to cryptd if there are currently
requests outstanding from the same tfm.
Signed-off-by: Herbert Xu
---
crypto/a
This patch fixes an old bug where gcm requests can be reordered
because some are processed by cryptd while others are processed
directly in softirq context.
The fix is to always postpone to cryptd if there are currently
requests outstanding from the same tfm.
Signed-off-by: Herbert Xu
---
arch
This patch fixes an old bug where requests can be reordered because
some are processed by cryptd while others are processed directly
in softirq context.
The fix is to always postpone to cryptd if there are currently
requests outstanding from the same tfm.
This patch also removes the redundant use
This patch fixes an old bug where requests can be reordered because
some are processed by cryptd while others are processed directly
in softirq context.
The fix is to always postpone to cryptd if there are currently
requests outstanding from the same tfm.
This patch also removes the redundant use
Hi:
I finally got around to working on this. I quickly gave up on the
notion of hijacking the queued requests as we may end up overwhelming
our caller.
So the solution is the obvious one of using cryptd as long as there
are requests queued there belonging to the same tfm. This is
totally untest
This patch adds helpers to check whether a given tfm is currently
queued. This is meant to be used by ablk_helper and similar
entities to ensure that no reordering is introduced because of
requests queued in cryptd with respect to requests being processed
in softirq context.
The per-cpu queue len
Am Dienstag, 21. Juni 2016, 10:32:23 schrieb Arnd Bergmann:
Hi Arnd,
> On Tuesday, June 21, 2016 8:20:10 AM CEST Stephan Mueller wrote:
> > Am Freitag, 17. Juni 2016, 17:59:41 schrieb Arnd Bergmann:
> >
> > Hi Arnd,
> >
> > > The jent_get_nstime() function uses __getnstimeofday() to get
> > > s
On Tuesday, June 21, 2016 8:20:10 AM CEST Stephan Mueller wrote:
> Am Freitag, 17. Juni 2016, 17:59:41 schrieb Arnd Bergmann:
>
> Hi Arnd,
>
> > The jent_get_nstime() function uses __getnstimeofday() to get
> > something similar to a 64-bit nanosecond counter. As we want
> > to get rid of struct
Currently, the only way to access the tdma chain is to use the 'req'
union from a mv_cesa_{ablkcipher,ahash}. This will soon become a problem
if we want to handle the TDMA chaining vs standard/non-DMA processing in
a generic way (with generic functions at the cesa.c level detecting
whether the requ
Now that crypto requests are chained together at the DMA level, we
increase the size of the crypto queue for each engine. The result is
that as the backlog list is reached later, it does not stop the crypto
stack from sending asychronous requests, so more cryptographic tasks
are processed by the en
This commits adds support for fine grained load balancing on
multi-engine IPs. The engine is pre-selected based on its current load
and on the weight of the crypto request that is about to be processed.
The global crypto queue is also moved to each engine. These changes are
required to allow chaini
Currently the crypto requests were sent to engines sequentially.
This commit moves the SRAM I/O operations from the prepare to the step
functions. It provides flexibility for future works and allow to prepare
a request while the engine is running.
Signed-off-by: Romain Perier
Acked-by: Boris Brez
So far, the 'process' operation was used to check if the current request
was correctly handled by the engine, if it was the case it copied
information from the SRAM to the main memory. Now, we split this
operation. We keep the 'process' operation, which still checks if the
request was correctly han
The Cryptographic Engines and Security Accelerators (CESA) supports the
Multi-Packet Chain Mode. With this mode enabled, multiple tdma requests
can be chained and processed by the hardware without software
intervention. This mode was already activated, however the crypto
requests were not chained t
Adding a macro constant to be used for the size of the crypto queue,
instead of using a numeric value directly. It will be easier to
maintain in case we add more than one crypto queue of the same size.
Signed-off-by: Romain Perier
Acked-by: Boris Brezillon
---
drivers/crypto/marvell/cesa.c | 5
Add a BUG_ON() call when the driver tries to launch a crypto request
while the engine is still processing the previous one. This replaces
a silent system hang by a verbose kernel panic with the associated
backtrace to let the user know that something went wrong in the CESA
driver.
Signed-off-by: R
Add a TDMA descriptor at the end of the request for copying the
output IV vector via a DMA transfer. This is a good way for offloading
as much as processing as possible to the DMA and the crypto engine.
This is also required for processing multiple cipher requests
in chained mode, otherwise the con
So far, the way that the type of a TDMA operation was checked was wrong.
We have to use the type mask in order to get the right part of the flag
containing the type of the operation.
Signed-off-by: Romain Perier
Acked-by: Boris Brezillon
---
drivers/crypto/marvell/tdma.c | 5 +++--
1 file chang
The Cryptographic Engines and Security Accelerators (CESA) supports
the TDMA chained mode support. When this mode is enabled and crypto
requests are chained at the DMA level, multiple crypto requests can be
handled by the hardware engine without requiring any software
intervention. This approach li
Am Dienstag, 21. Juni 2016, 09:12:07 schrieb Nikos Mavrogiannopoulos:
Hi Nikos,
> On Mon, Jun 20, 2016 at 5:43 PM, Stephan Mueller
wrote:
> >> Personally, I don't really use /dev/random, nor would I recommend it
> >> for most application programmers. At this point, getrandom(2) really
> >> is
On Mon, Jun 20, 2016 at 5:43 PM, Stephan Mueller wrote:
>> Personally, I don't really use /dev/random, nor would I recommend it
>> for most application programmers. At this point, getrandom(2) really
>> is the preferred interface unless you have some very specialized
>> needs.
> I fully agree. Bu
70 matches
Mail list logo
