From: Eric Biggers <ebiggers@kernel.org>
To: Lionel DEBIEVE <lionel.debieve@st.com>
Cc: "herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>
Subject: Re: [Bug] STM32 crc driver failed on selftest 1
Date: Thu, 21 Mar 2019 06:41:50 -0700 [thread overview]
Message-ID: <20190321134149.GB764@sol.localdomain> (raw)
In-Reply-To: <39d55020-a4db-f5f8-e9b5-777690b85ed5@st.com>
On Thu, Mar 21, 2019 at 10:46:53AM +0000, Lionel DEBIEVE wrote:
> Hi All,
>
> I'm looking further to debug an issue regarding CRC32 selftests. I'm
> currently blocked on an issue about the second test vector implemented
> on CRC32:
> static const struct hash_testvec crc32_tv_template[] = {
> {
> .plaintext = "abcdefg",
> .psize = 7,
>
> .digest = "\xd8\xb5\x46\xac",
>
> },
>
> I'm currently trying to understand the issue, but using others tools
> (computer or Online CRC calculation), I'm not able to find any way to
> get the expected output? This new vector was introduced for few version
> but I'm wondering who was able to verify it.
>
> Should it be written by byte? Word? Half word?
>
> Thanks for help.
>
> BR,
> Lionel
It's the CRC-32 of the 7-byte buffer "abcdefg" using an initial value of 0.
Bitwise little endian with a little endian digest, and no complementation at the
beginning or end. Note that the initial value ("key") is not given explicitly,
i.e. this tests that the implementation uses the correct default initial value.
The generic, arm, and x86 implementations in the kernel obviously all pass this,
otherwise people would be complaining about them. You can also verify it in
userspace with zlib using:
#include <assert.h>
#include <stdint.h>
#include <zlib.h>
int main()
{
assert((uint32_t)~crc32(~0, "abcdefg", 7) == 0xac46b5d8);
}
(zlib complements the value at the beginning and end, so it must be undone to
match the kernel conversion which doesn't do that.)
- Eric
prev parent reply other threads:[~2019-03-21 13:41 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-26 21:05 [Bug] Rockchip crypto driver sometimes produces wrong ciphertext Eric Biggers
2019-01-27 8:54 ` Ard Biesheuvel
2019-01-27 10:29 ` Heiko Stuebner
2019-01-28 3:14 ` Tao Huang
2019-03-15 3:31 ` Eric Biggers
2019-03-16 22:31 ` Ezequiel Garcia
2019-03-18 15:03 ` Gael PORTAY
2019-03-21 17:04 ` Gael PORTAY
2019-03-25 6:31 ` Zhang Zhijie
2019-04-04 13:41 ` Pascal Van Leeuwen
2019-04-04 17:12 ` Eric Biggers
2019-04-07 12:42 ` Herbert Xu
2019-04-07 19:12 ` Pascal Van Leeuwen
2019-04-08 5:58 ` Herbert Xu
2019-04-08 8:59 ` Pascal Van Leeuwen
2019-04-08 9:06 ` Herbert Xu
2019-04-09 15:53 ` Pascal Van Leeuwen
2019-04-08 18:09 ` Eric Biggers
2019-04-09 16:43 ` Pascal Van Leeuwen
2019-04-08 18:27 ` Eric Biggers
2019-04-08 21:17 ` Ard Biesheuvel
2019-04-09 16:58 ` Pascal Van Leeuwen
2019-03-21 10:46 ` [Bug] STM32 crc driver failed on selftest 1 Lionel DEBIEVE
2019-03-21 13:41 ` Eric Biggers [this message]
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=20190321134149.GB764@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=lionel.debieve@st.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