From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Eric Biggers <ebiggers@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Netdev <netdev@vger.kernel.org>,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
David Miller <davem@davemloft.net>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Samuel Neves <sneves@dei.uc.pt>,
Andrew Lutomirski <luto@kernel.org>,
Jean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com>,
Andy Polyakov <appro@openssl.org>,
Russell King - ARM Linux <linux@armlinux.org.uk>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH net-next v5 09/20] zinc: Poly1305 ARM and ARM64 implementations
Date: Wed, 19 Sep 2018 02:17:10 +0200 [thread overview]
Message-ID: <CAHmME9r_qbbYo=sxOvUauXDetJ3uA2A=WdpvjzQwMgqYF3=h1A@mail.gmail.com> (raw)
In-Reply-To: <20180918225552.GA74746@gmail.com>
Hi Eric,
On Wed, Sep 19, 2018 at 12:55 AM Eric Biggers <ebiggers@kernel.org> wrote:
> This will compute the wrong digest if called with simd_context=HAVE_FULL_SIMD
> and then later with simd_context=HAVE_NO_SIMD, since poly1305_blocks_neon()
> converts the accumulator from base 32 to base 26, whereas poly1305_blocks_arm()
> assumes it is still in base 32. Is that intentional? I'm sure this is a rare
> case, but my understanding is that the existing crypto API doesn't preclude
> calling successive steps in different contexts. And I'm concerned that it could
> be relevant in some cases, e.g. especially if people are importing a hash state
> that was exported earlier. Handling it by silently computing the wrong digest
> is not a great idea...
Indeed you're right; Samuel and I were just discussing that recently.
I'd rather handle this correctly even if the contexts change, so I'll
see if I can fix this up properly for that unlikely case in the next
revision.
Jason
WARNING: multiple messages have this Message-ID (diff)
From: Jason@zx2c4.com (Jason A. Donenfeld)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH net-next v5 09/20] zinc: Poly1305 ARM and ARM64 implementations
Date: Wed, 19 Sep 2018 02:17:10 +0200 [thread overview]
Message-ID: <CAHmME9r_qbbYo=sxOvUauXDetJ3uA2A=WdpvjzQwMgqYF3=h1A@mail.gmail.com> (raw)
In-Reply-To: <20180918225552.GA74746@gmail.com>
Hi Eric,
On Wed, Sep 19, 2018 at 12:55 AM Eric Biggers <ebiggers@kernel.org> wrote:
> This will compute the wrong digest if called with simd_context=HAVE_FULL_SIMD
> and then later with simd_context=HAVE_NO_SIMD, since poly1305_blocks_neon()
> converts the accumulator from base 32 to base 26, whereas poly1305_blocks_arm()
> assumes it is still in base 32. Is that intentional? I'm sure this is a rare
> case, but my understanding is that the existing crypto API doesn't preclude
> calling successive steps in different contexts. And I'm concerned that it could
> be relevant in some cases, e.g. especially if people are importing a hash state
> that was exported earlier. Handling it by silently computing the wrong digest
> is not a great idea...
Indeed you're right; Samuel and I were just discussing that recently.
I'd rather handle this correctly even if the contexts change, so I'll
see if I can fix this up properly for that unlikely case in the next
revision.
Jason
next prev parent reply other threads:[~2018-09-19 0:17 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-18 16:16 [PATCH net-next v5 00/20] WireGuard: Secure Network Tunnel Jason A. Donenfeld
2018-09-18 16:16 ` [PATCH net-next v5 01/20] asm: simd context helper API Jason A. Donenfeld
2018-09-18 16:16 ` [PATCH net-next v5 02/20] zinc: introduce minimal cryptography library Jason A. Donenfeld
2018-09-20 15:41 ` Ard Biesheuvel
2018-09-20 15:41 ` Ard Biesheuvel
2018-09-20 16:01 ` Andy Lutomirski
2018-09-20 16:01 ` Andy Lutomirski
2018-09-20 16:02 ` Arnd Bergmann
2018-09-20 16:02 ` Arnd Bergmann
2018-09-21 0:11 ` Jason A. Donenfeld
2018-09-21 3:12 ` Andrew Lunn
2018-09-21 3:16 ` Jason A. Donenfeld
2018-09-21 3:23 ` Andy Lutomirski
2018-09-21 4:15 ` Jason A. Donenfeld
2018-09-21 4:30 ` Ard Biesheuvel
2018-09-21 4:32 ` Jason A. Donenfeld
2018-09-21 4:52 ` Andy Lutomirski
2018-09-22 16:11 ` Arnd Bergmann
2018-09-22 16:11 ` Arnd Bergmann
2018-09-25 7:18 ` Arnd Bergmann
2018-09-25 7:18 ` Arnd Bergmann
2018-09-25 14:29 ` Jason A. Donenfeld
2018-09-21 0:17 ` Jason A. Donenfeld
2018-09-25 10:25 ` Ard Biesheuvel
2018-09-25 10:25 ` Ard Biesheuvel
2018-09-25 14:44 ` Jason A. Donenfeld
2018-09-18 16:16 ` [PATCH net-next v5 03/20] zinc: ChaCha20 generic C implementation and selftest Jason A. Donenfeld
2018-09-19 1:08 ` Eric Biggers
2018-09-19 2:02 ` Jason A. Donenfeld
2018-09-18 16:16 ` [PATCH net-next v5 04/20] zinc: ChaCha20 x86_64 implementation Jason A. Donenfeld
2018-09-18 22:29 ` Thomas Gleixner
2018-09-19 2:14 ` Jason A. Donenfeld
2018-09-19 6:13 ` Thomas Gleixner
2018-09-19 11:33 ` Jason A. Donenfeld
2018-09-18 16:16 ` [PATCH net-next v5 05/20] zinc: ChaCha20 ARM and ARM64 implementations Jason A. Donenfeld
2018-09-18 16:16 ` Jason A. Donenfeld
2018-09-18 16:16 ` [PATCH net-next v5 06/20] zinc: ChaCha20 MIPS32r2 implementation Jason A. Donenfeld
2018-09-18 20:25 ` Paul Burton
2018-09-20 13:19 ` Jason A. Donenfeld
2018-09-18 16:16 ` [PATCH net-next v5 07/20] zinc: Poly1305 generic C implementations and selftest Jason A. Donenfeld
2018-09-19 0:50 ` Eric Biggers
2018-09-19 1:35 ` Jason A. Donenfeld
2018-09-19 4:13 ` Andy Lutomirski
2018-09-19 11:50 ` Jason A. Donenfeld
2018-09-19 12:26 ` Jason A. Donenfeld
2018-09-19 1:39 ` Jason A. Donenfeld
2018-09-19 1:41 ` Jason A. Donenfeld
2018-09-18 16:16 ` [PATCH net-next v5 08/20] zinc: Poly1305 x86_64 implementation Jason A. Donenfeld
2018-09-18 16:16 ` [PATCH net-next v5 09/20] zinc: Poly1305 ARM and ARM64 implementations Jason A. Donenfeld
2018-09-18 16:16 ` Jason A. Donenfeld
2018-09-18 22:55 ` Eric Biggers
2018-09-18 22:55 ` Eric Biggers
2018-09-19 0:17 ` Jason A. Donenfeld [this message]
2018-09-19 0:17 ` Jason A. Donenfeld
2018-09-18 16:16 ` [PATCH net-next v5 10/20] zinc: Poly1305 MIPS32r2 and MIPS64 implementations Jason A. Donenfeld
2018-09-18 16:16 ` [PATCH net-next v5 11/20] zinc: ChaCha20Poly1305 construction and selftest Jason A. Donenfeld
2018-09-18 16:16 ` [PATCH net-next v5 12/20] zinc: BLAKE2s generic C implementation " Jason A. Donenfeld
2018-09-19 0:41 ` Eric Biggers
2018-09-19 0:45 ` Jason A. Donenfeld
2018-09-18 16:16 ` [PATCH net-next v5 13/20] zinc: BLAKE2s x86_64 implementation Jason A. Donenfeld
2018-09-18 16:16 ` [PATCH net-next v5 14/20] zinc: Curve25519 generic C implementations and selftest Jason A. Donenfeld
2018-09-18 16:16 ` [PATCH net-next v5 15/20] zinc: Curve25519 x86_64 implementation Jason A. Donenfeld
2018-09-18 16:16 ` [PATCH net-next v5 16/20] zinc: Curve25519 ARM implementation Jason A. Donenfeld
2018-09-18 16:16 ` Jason A. Donenfeld
2018-09-18 16:16 ` [PATCH net-next v5 17/20] crypto: port Poly1305 to Zinc Jason A. Donenfeld
2018-09-18 16:16 ` [PATCH net-next v5 18/20] crypto: port ChaCha20 " Jason A. Donenfeld
2018-09-18 16:16 ` [PATCH net-next v5 19/20] security/keys: rewrite big_key crypto to use Zinc Jason A. Donenfeld
2018-09-18 16:16 ` [PATCH net-next v5 20/20] net: WireGuard secure network tunnel Jason A. Donenfeld
2018-09-18 23:34 ` Andrew Lunn
2018-09-19 2:04 ` Jason A. Donenfeld
2018-09-19 12:38 ` Andrew Lunn
2018-09-18 17:01 ` [PATCH net-next v5 19/20] security/keys: rewrite big_key crypto to use Zinc David Howells
2018-09-18 17:12 ` Jason A. Donenfeld
2018-09-18 18:28 ` [PATCH net-next v5 00/20] WireGuard: Secure Network Tunnel Ard Biesheuvel
2018-09-18 18:28 ` Ard Biesheuvel
2018-09-18 21:01 ` Jason A. Donenfeld
2018-09-18 21:01 ` Jason A. Donenfeld
2018-09-19 17:21 ` Ard Biesheuvel
2018-09-19 17:21 ` Ard Biesheuvel
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='CAHmME9r_qbbYo=sxOvUauXDetJ3uA2A=WdpvjzQwMgqYF3=h1A@mail.gmail.com' \
--to=jason@zx2c4.com \
--cc=appro@openssl.org \
--cc=davem@davemloft.net \
--cc=ebiggers@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jeanphilippe.aumasson@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=luto@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sneves@dei.uc.pt \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.