Instead of copying the calculated authentication tag to memory and
calling crypto_memneq() to verify it, use vector bytewise compare and
min across vector instructions to decide whether the tag is valid. This
is more efficient, and given that the tag is only transiently held in a
NEON register, it
Am Montag, 9. November 2020, 20:31:02 CET schrieb Paul Menzel:
Hi Paul,
> Dear Linux folks,
>
>
> By mistake I built `XFRM_ESP` into the Linux kernel, resulting in
>
> CONFIG_CRYPTO_SEQIV=y
> CONFIG_CRYPTO_ECHAINIV=y
>
> and also the Jitterentropy RNG to be built in.
>
> CRYPT
Dear Stephan,
Thank you for the quick reply.
Am 10.11.20 um 10:25 schrieb Stephan Mueller:
Am Montag, 9. November 2020, 20:31:02 CET schrieb Paul Menzel:
By mistake I built `XFRM_ESP` into the Linux kernel, resulting in
CONFIG_CRYPTO_SEQIV=y
CONFIG_CRYPTO_ECHAINIV=y
and also t
Am Dienstag, 10. November 2020, 10:37:02 CET schrieb Paul Menzel:
Hi Paul,
> Dear Stephan,
>
>
> Thank you for the quick reply.
>
> Am 10.11.20 um 10:25 schrieb Stephan Mueller:
> > Am Montag, 9. November 2020, 20:31:02 CET schrieb Paul Menzel:
> >> By mistake I built `XFRM_ESP` into the Linux
Am Montag, 19. Oktober 2020, 21:28:50 CET schrieb Stephan Müller:
Hi,
>
> * Performance
>
> - Faster by up to 75% in the critical code path of the interrupt handler
>depending on data collection size configurable at kernel compile time -
>the default is about equal in performance with e
On Mon, Nov 09, 2020 at 11:43:35AM +0800, Li Qiang wrote:
> Hi Dave,
>
> I carefully read the ideas you provided and the sample code you gave me.:)
>
> 在 2020/11/6 0:53, Dave Martin 写道:
> > On Tue, Nov 03, 2020 at 08:15:05PM +0800, l00374334 wrote:
> >> From: liqiang
> >>
> >> Dear all,
> >>
> >
On 11/9/20 6:52 PM, Joe Perches wrote:
> On Tue, 2020-10-27 at 09:42 -0700, t...@redhat.com wrote:
>> This rfc will describe
>> An upcoming treewide cleanup.
>> How clang tooling was used to programatically do the clean up.
>> Solicit opinions on how to generally use clang tooling.
>>
>> The clan
在 2020/11/10 18:46, Dave Martin 写道:
> On Mon, Nov 09, 2020 at 11:43:35AM +0800, Li Qiang wrote:
>> Hi Dave,
>>
>> I carefully read the ideas you provided and the sample code you gave me.:)
>>
>> 在 2020/11/6 0:53, Dave Martin 写道:
>>> On Tue, Nov 03, 2020 at 08:15:05PM +0800, l00374334 wrote:
On Mon, Nov 09, 2020 at 02:01:41PM -0500, Chris Mason wrote:
> On 6 Nov 2020, at 13:38, Christoph Hellwig wrote:
> > You just keep resedning this crap, don't you? Haven't you been told
> > multiple times to provide a proper kernel API by now?
>
> You do consistently ask for a shim layer, but you
On Tue, Nov 10, 2020 at 09:20:46PM +0800, Li Qiang wrote:
>
>
> 在 2020/11/10 18:46, Dave Martin 写道:
> > On Mon, Nov 09, 2020 at 11:43:35AM +0800, Li Qiang wrote:
> >> Hi Dave,
> >>
> >> I carefully read the ideas you provided and the sample code you gave me.:)
> >>
> >> 在 2020/11/6 0:53, Dave Mar
On Mon, 2020-11-09 at 10:15 -0600, Rob Herring wrote:
> On Tue, Nov 03, 2020 at 06:49:23PM +, Daniele Alessandrelli wrote:
> > From: Declan Murphy
> >
> > Add device-tree bindings for the Intel Keem Bay Offload Crypto Subsystem
> > (OCS) Hashing Control Unit (HCU) crypto driver.
> >
> > Sign
On Mon, Nov 09, 2020 at 02:01:41PM -0500, Chris Mason wrote:
> You do consistently ask for a shim layer, but you haven???t explained what
> we gain by diverging from the documented and tested API of the upstream zstd
> project. It???s an important discussion given that we hope to regularly
> updat
This series supersedes [0] '[PATCH] crypto: aegis128/neon - optimize tail
block handling', which is included as patch #3 here, but hasn't been
modified substantially.
Patch #1 should probably go to -stable, even though aegis128 does not appear
to be widely used.
Patches #2 and #3 improve the SIMD
Wiring the SIMD code into the generic driver has the unfortunate side
effect that the tcrypt testing code cannot distinguish them, and will
therefore not use the latter to fuzz test the former, as it does for
other algorithms.
So let's refactor the code a bit so we can register two implementations
Avoid copying the tail block via a stack buffer if the total size
exceeds a single AEGIS block. In this case, we can use overlapping
loads and stores and NEON permutation instructions instead, which
leads to a modest performance improvement on some cores (< 5%),
and is slightly cleaner. Note that w
The AEGIS spec mentions explicitly that the security guarantees hold
only if the resulting plaintext and tag of a failed decryption are
not disclosed. So ensure that we abide by this.
While at it, drop the unused struct aead_request *req parameter from
crypto_aegis128_process_crypt().
Signed-off-
Instead of calculating the tag and returning it to the caller on
decryption, use a SIMD compare and min across vector to perform
the comparison. This is slightly more efficient, and removes the
need on the caller's part to wipe the tag from memory if the
decryption failed.
While at it, switch to u
On 10 Nov 2020, at 13:39, Christoph Hellwig wrote:
On Mon, Nov 09, 2020 at 02:01:41PM -0500, Chris Mason wrote:
You do consistently ask for a shim layer, but you haven???t explained
what
we gain by diverging from the documented and tested API of the
upstream zstd
project. It???s an important
> On Nov 10, 2020, at 7:25 AM, David Sterba wrote:
>
> On Mon, Nov 09, 2020 at 02:01:41PM -0500, Chris Mason wrote:
>> On 6 Nov 2020, at 13:38, Christoph Hellwig wrote:
>>> You just keep resedning this crap, don't you? Haven't you been told
>>> multiple times to provide a proper kernel API by no
> On Nov 10, 2020, at 10:39 AM, Christoph Hellwig wrote:
>
> On Mon, Nov 09, 2020 at 02:01:41PM -0500, Chris Mason wrote:
>> You do consistently ask for a shim layer, but you haven???t explained what
>> we gain by diverging from the documented and tested API of the upstream zstd
>> project. It
(+ Russell)
On Thu, 22 Oct 2020 at 18:20, Joe Perches wrote:
>
> On Thu, 2020-10-22 at 09:33 +0200, Peter Zijlstra wrote:
> > On Wed, Oct 21, 2020 at 11:58:25AM -0700, Joe Perches wrote:
> > > Like the __section macro, the __alias macro uses
> > > macro # stringification to create quotes around
>
21 matches
Mail list logo
