使用 Boost 计算 ECMA-128 64 位 CRC
Use Boost to compute ECMA-128 64bit CRC
使用以下程序,我正在尝试计算 64bit CRC as per the ECMA-128 standard。
测试数据是“123456789”,我正在尝试匹配 here 提供的相同数据,这表明 CRC-64/ECMA-182 的结果应该是 62ec59e3f1a4f00a。不幸的是,我得到 9d13a61c0e5b0ff5,这是 CRC-64/WE 结果。
我从 here. I created the 64 bit hashes with the normal polynomial representation of 0x42F0E1EBA9EA3693 为 ECMA-128 64 位 crc 提供的示例代码开始。
我收到以下 VS 警告:C4293:“<<”:班次计数为负数或太大,未定义的行为。用于此宏:
BOOST_STATIC_CONSTANT( least, sig_bits = (~( ~(least( 0u )) << Bits )) );
据我所知,0
正在按 64 位的全范围进行位移,这是未定义的行为。我很惊讶我没有看到 32 位 crc 的警告。
如何更正此程序以在没有未定义行为的情况下正确计算 ECMA-128 64 位 crc?
// from https://www.boost.org/doc/libs/1_67_0/libs/crc/crc.html#usage
#include <boost/crc.hpp> // for boost::crc_basic, boost::crc_optimal
#include <boost/cstdint.hpp> // for boost::uint16_t
#include <algorithm> // for std::for_each
#include <cassert> // for assert
#include <cstddef> // for std::size_t
#include <iostream> // for std::cout
#include <ostream> // for std::endl
//#define SHOW_ERROR
#if defined( SHOW_ERROR )
#define CRC ecma_crc // expected
#else
#define CRC other_crc // actually received
#endif
int main()
{
// This is "123456789" in ASCII
unsigned char const data[] = {0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39};
std::size_t const data_len = sizeof(data) / sizeof(data[0]);
// The expected CRC for the given data
boost::uint16_t const expected = 0x29B1;
// Expected CRCs for "123456789" as per https://www.nitrxgen.net/hashgen/
long long const other_crc = 0x9D13A61C0E5B0FF5; // Wolfgang Ehrhardt http://www.wolfgang-ehrhardt.de/crchash_en.html
long long const ecma_crc = 0x62EC59E3F1A4F00A; // CRC-64-ECMA-128 https://en.wikipedia.org/wiki/Cyclic_redundancy_check
// Simulate CRC-CCITT
boost::crc_basic<16> crc_ccitt1(0x1021, 0xFFFF, 0, false, false);
crc_ccitt1.process_bytes(data, data_len);
assert(crc_ccitt1.checksum() == expected);
// Repeat with the optimal version (assuming a 16-bit type exists)
boost::crc_optimal<16, 0x1021, 0xFFFF, 0, false, false> crc_ccitt2;
crc_ccitt2 = std::for_each(data, data + data_len, crc_ccitt2);
assert(crc_ccitt2() == expected);
// Attempt 64 bit CRC
boost::crc_basic<64> crc_64_ecma1(0x42F0E1EBA9EA3693, 0xFFFFFFFFFFFFFFFF, 0, false, false);
crc_64_ecma1.process_bytes(data, data_len);
assert(crc_64_ecma1.checksum() == CRC);
boost::crc_optimal<64, 0x42F0E1EBA9EA3693, 0xFFFFFFFFFFFFFFFF, 0, false, false> crc_64_ecma2;
crc_64_ecma2 = std::for_each(data, data + data_len, crc_64_ecma2);
assert(crc_64_ecma2() == CRC);
std::cout << "All tests passed." << std::endl;
return 0;
}
正确的 CRC 参数
Boost 具有以下 CRC-32/B/BZIP2/AAL5/DECT-B 的类型定义:
typedef crc_optimal<32, 0x04C11DB7, 0xFFFFFFFF, 0xFFFFFFFF, true, true>
crc_32_type;
同样,ECMA-128 64 位 CRC 需要最终的异或值(第 3 个参数):
boost::crc_basic<64> crc_64_ecma1(0x42F0E1EBA9EA3693, 0xFFFFFFFFFFFFFFFF, 0xFFFFFFFFFFFFFFFF, false, false);
^^^^^^^^^^^^^^^^^^
警告消息的原因
以下模板
template < std::size_t Bits >
class crc_basic
使用
template < std::size_t Bits >
struct mask_uint_t
而这个 mask_uint_t
专门用于各种位数:
unsigned char -> BOOST_STATIC_CONSTANT( least, sig_bits = (~( least(0u) )) );
unsigned short -> BOOST_STATIC_CONSTANT( least, sig_bits = (~( least(0u) )) );
unsigned int -> BOOST_STATIC_CONSTANT( least, sig_bits = (~( least(0u) )) );
但非专用版本不同并触发未定义行为警告:
BOOST_STATIC_CONSTANT( least, sig_bits = (~( ~(least( 0u )) << Bits ))
);
在 MSVC 上它仍然产生正确的值,但可能不应该依赖它。
仔细看62ec59e3f1a4f00a和9d13a61c0e5b0ff5,一位一位。你看出这两者之间的关系了吗?
更新:
好!你看到了。 (我讨厌剥夺别人发现的乐趣。)至于为什么,您可以查看 Greg Cook's CRC catalog ECMA-182 CRC 的定义,在那里简称为 CRC-64:
width=64 poly=0x42f0e1eba9ea3693 init=0x0000000000000000 refin=false refout=false xorout=0x0000000000000000 check=0x6c40df5f0b497347 residue=0x0000000000000000 name="CRC-64"
这定义了初始值为零的 CRC,最终异或为零,即没有变化。这对于 CRC 来说并不常见,因为它会导致一串任意长度的零具有相同的 CRC,等于零。
CRC-64/WE 也在那里定义,它给出:
width=64 poly=0x42f0e1eba9ea3693 init=0xffffffffffffffff refin=false refout=false xorout=0xffffffffffffffff check=0x62ec59e3f1a4f00a residue=0xfcacbebd5931a992 name="CRC-64/WE"
这更常见,具有初始化和异或两者都具有全 1,因为零字符串的 CRC 将取决于字符串的长度,零长度消息的 CRC 为零。
然而,这与您提供的 link 中的计算不一致。您提供的 link 计算它的初始值为零,而 Greg 的目录中的定义将 CRC 初始化为全 1。只有一个是正确的。
更新二:
格雷格的目录是正确的。 linked 在线哈希计算器是错误的。我通过查看 Wolfgang Ehrhardt's (the "WE" in CRC-64/WE) source code (a zip file) 验证了 CRC 定义。 linked 计算器是双重错误的,因为它给出了 CRC-64/WE 检查值 62ec...
作为 CRC-64/ECMA-182 结果,它给出了 CRC-64/WE 的结果与 CRC-64 均不匹配。当心您在互联网上找到的内容。
使用以下程序,我正在尝试计算 64bit CRC as per the ECMA-128 standard。
测试数据是“123456789”,我正在尝试匹配 here 提供的相同数据,这表明 CRC-64/ECMA-182 的结果应该是 62ec59e3f1a4f00a。不幸的是,我得到 9d13a61c0e5b0ff5,这是 CRC-64/WE 结果。
我从 here. I created the 64 bit hashes with the normal polynomial representation of 0x42F0E1EBA9EA3693 为 ECMA-128 64 位 crc 提供的示例代码开始。
我收到以下 VS 警告:C4293:“<<”:班次计数为负数或太大,未定义的行为。用于此宏:
BOOST_STATIC_CONSTANT( least, sig_bits = (~( ~(least( 0u )) << Bits )) );
据我所知,0
正在按 64 位的全范围进行位移,这是未定义的行为。我很惊讶我没有看到 32 位 crc 的警告。
如何更正此程序以在没有未定义行为的情况下正确计算 ECMA-128 64 位 crc?
// from https://www.boost.org/doc/libs/1_67_0/libs/crc/crc.html#usage
#include <boost/crc.hpp> // for boost::crc_basic, boost::crc_optimal
#include <boost/cstdint.hpp> // for boost::uint16_t
#include <algorithm> // for std::for_each
#include <cassert> // for assert
#include <cstddef> // for std::size_t
#include <iostream> // for std::cout
#include <ostream> // for std::endl
//#define SHOW_ERROR
#if defined( SHOW_ERROR )
#define CRC ecma_crc // expected
#else
#define CRC other_crc // actually received
#endif
int main()
{
// This is "123456789" in ASCII
unsigned char const data[] = {0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39};
std::size_t const data_len = sizeof(data) / sizeof(data[0]);
// The expected CRC for the given data
boost::uint16_t const expected = 0x29B1;
// Expected CRCs for "123456789" as per https://www.nitrxgen.net/hashgen/
long long const other_crc = 0x9D13A61C0E5B0FF5; // Wolfgang Ehrhardt http://www.wolfgang-ehrhardt.de/crchash_en.html
long long const ecma_crc = 0x62EC59E3F1A4F00A; // CRC-64-ECMA-128 https://en.wikipedia.org/wiki/Cyclic_redundancy_check
// Simulate CRC-CCITT
boost::crc_basic<16> crc_ccitt1(0x1021, 0xFFFF, 0, false, false);
crc_ccitt1.process_bytes(data, data_len);
assert(crc_ccitt1.checksum() == expected);
// Repeat with the optimal version (assuming a 16-bit type exists)
boost::crc_optimal<16, 0x1021, 0xFFFF, 0, false, false> crc_ccitt2;
crc_ccitt2 = std::for_each(data, data + data_len, crc_ccitt2);
assert(crc_ccitt2() == expected);
// Attempt 64 bit CRC
boost::crc_basic<64> crc_64_ecma1(0x42F0E1EBA9EA3693, 0xFFFFFFFFFFFFFFFF, 0, false, false);
crc_64_ecma1.process_bytes(data, data_len);
assert(crc_64_ecma1.checksum() == CRC);
boost::crc_optimal<64, 0x42F0E1EBA9EA3693, 0xFFFFFFFFFFFFFFFF, 0, false, false> crc_64_ecma2;
crc_64_ecma2 = std::for_each(data, data + data_len, crc_64_ecma2);
assert(crc_64_ecma2() == CRC);
std::cout << "All tests passed." << std::endl;
return 0;
}
正确的 CRC 参数
Boost 具有以下 CRC-32/B/BZIP2/AAL5/DECT-B 的类型定义:
typedef crc_optimal<32, 0x04C11DB7, 0xFFFFFFFF, 0xFFFFFFFF, true, true>
crc_32_type;
同样,ECMA-128 64 位 CRC 需要最终的异或值(第 3 个参数):
boost::crc_basic<64> crc_64_ecma1(0x42F0E1EBA9EA3693, 0xFFFFFFFFFFFFFFFF, 0xFFFFFFFFFFFFFFFF, false, false);
^^^^^^^^^^^^^^^^^^
警告消息的原因
以下模板
template < std::size_t Bits >
class crc_basic
使用
template < std::size_t Bits >
struct mask_uint_t
而这个 mask_uint_t
专门用于各种位数:
unsigned char -> BOOST_STATIC_CONSTANT( least, sig_bits = (~( least(0u) )) );
unsigned short -> BOOST_STATIC_CONSTANT( least, sig_bits = (~( least(0u) )) );
unsigned int -> BOOST_STATIC_CONSTANT( least, sig_bits = (~( least(0u) )) );
但非专用版本不同并触发未定义行为警告:
BOOST_STATIC_CONSTANT( least, sig_bits = (~( ~(least( 0u )) << Bits ))
);
在 MSVC 上它仍然产生正确的值,但可能不应该依赖它。
仔细看62ec59e3f1a4f00a和9d13a61c0e5b0ff5,一位一位。你看出这两者之间的关系了吗?
更新:
好!你看到了。 (我讨厌剥夺别人发现的乐趣。)至于为什么,您可以查看 Greg Cook's CRC catalog ECMA-182 CRC 的定义,在那里简称为 CRC-64:
width=64 poly=0x42f0e1eba9ea3693 init=0x0000000000000000 refin=false refout=false xorout=0x0000000000000000 check=0x6c40df5f0b497347 residue=0x0000000000000000 name="CRC-64"
这定义了初始值为零的 CRC,最终异或为零,即没有变化。这对于 CRC 来说并不常见,因为它会导致一串任意长度的零具有相同的 CRC,等于零。
CRC-64/WE 也在那里定义,它给出:
width=64 poly=0x42f0e1eba9ea3693 init=0xffffffffffffffff refin=false refout=false xorout=0xffffffffffffffff check=0x62ec59e3f1a4f00a residue=0xfcacbebd5931a992 name="CRC-64/WE"
这更常见,具有初始化和异或两者都具有全 1,因为零字符串的 CRC 将取决于字符串的长度,零长度消息的 CRC 为零。
然而,这与您提供的 link 中的计算不一致。您提供的 link 计算它的初始值为零,而 Greg 的目录中的定义将 CRC 初始化为全 1。只有一个是正确的。
更新二:
格雷格的目录是正确的。 linked 在线哈希计算器是错误的。我通过查看 Wolfgang Ehrhardt's (the "WE" in CRC-64/WE) source code (a zip file) 验证了 CRC 定义。 linked 计算器是双重错误的,因为它给出了 CRC-64/WE 检查值 62ec...
作为 CRC-64/ECMA-182 结果,它给出了 CRC-64/WE 的结果与 CRC-64 均不匹配。当心您在互联网上找到的内容。