CRC32C - 将0s / CRC附加到消息

时间:2017-04-07 13:36:47

标签: c crc crc32

我正在努力更好地理解CRC,但是我有点卡住了。

这里有很少的样本向量1我可以正确计算,但是我仍然坚持验证计算出的CRC是否正确。

例如,给定一个32字节的消息:

  

000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f

我的理解是你首先附加32位0来获得有效载荷:

  

000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f00000000

并计算该消息的CRC以获得0x73c2a486

要验证CRC是否正确,您应该将CRC值附加到原始值,在这种情况下:

  

000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f73c2a486

这应该返回0,但我不能得到它。

如果有人能指出我哪里出错了,我将非常感激。

编辑:

我正在使用的示例代码:

static uint32_t crc32c_table_small[256] =
{
  0x00000000, 0xF26B8303, 0xE13B70F7, 0x1350F3F4, 0xC79A971F, 0x35F1141C, 0x26A1E7E8, 0xD4CA64EB,
  0x8AD958CF, 0x78B2DBCC, 0x6BE22838, 0x9989AB3B, 0x4D43CFD0, 0xBF284CD3, 0xAC78BF27, 0x5E133C24,
  0x105EC76F, 0xE235446C, 0xF165B798, 0x030E349B, 0xD7C45070, 0x25AFD373, 0x36FF2087, 0xC494A384,
  0x9A879FA0, 0x68EC1CA3, 0x7BBCEF57, 0x89D76C54, 0x5D1D08BF, 0xAF768BBC, 0xBC267848, 0x4E4DFB4B,
  0x20BD8EDE, 0xD2D60DDD, 0xC186FE29, 0x33ED7D2A, 0xE72719C1, 0x154C9AC2, 0x061C6936, 0xF477EA35,
  0xAA64D611, 0x580F5512, 0x4B5FA6E6, 0xB93425E5, 0x6DFE410E, 0x9F95C20D, 0x8CC531F9, 0x7EAEB2FA,
  0x30E349B1, 0xC288CAB2, 0xD1D83946, 0x23B3BA45, 0xF779DEAE, 0x05125DAD, 0x1642AE59, 0xE4292D5A,
  0xBA3A117E, 0x4851927D, 0x5B016189, 0xA96AE28A, 0x7DA08661, 0x8FCB0562, 0x9C9BF696, 0x6EF07595,
  0x417B1DBC, 0xB3109EBF, 0xA0406D4B, 0x522BEE48, 0x86E18AA3, 0x748A09A0, 0x67DAFA54, 0x95B17957,
  0xCBA24573, 0x39C9C670, 0x2A993584, 0xD8F2B687, 0x0C38D26C, 0xFE53516F, 0xED03A29B, 0x1F682198,
  0x5125DAD3, 0xA34E59D0, 0xB01EAA24, 0x42752927, 0x96BF4DCC, 0x64D4CECF, 0x77843D3B, 0x85EFBE38,
  0xDBFC821C, 0x2997011F, 0x3AC7F2EB, 0xC8AC71E8, 0x1C661503, 0xEE0D9600, 0xFD5D65F4, 0x0F36E6F7,
  0x61C69362, 0x93AD1061, 0x80FDE395, 0x72966096, 0xA65C047D, 0x5437877E, 0x4767748A, 0xB50CF789,
  0xEB1FCBAD, 0x197448AE, 0x0A24BB5A, 0xF84F3859, 0x2C855CB2, 0xDEEEDFB1, 0xCDBE2C45, 0x3FD5AF46,
  0x7198540D, 0x83F3D70E, 0x90A324FA, 0x62C8A7F9, 0xB602C312, 0x44694011, 0x5739B3E5, 0xA55230E6,
  0xFB410CC2, 0x092A8FC1, 0x1A7A7C35, 0xE811FF36, 0x3CDB9BDD, 0xCEB018DE, 0xDDE0EB2A, 0x2F8B6829,
  0x82F63B78, 0x709DB87B, 0x63CD4B8F, 0x91A6C88C, 0x456CAC67, 0xB7072F64, 0xA457DC90, 0x563C5F93,
  0x082F63B7, 0xFA44E0B4, 0xE9141340, 0x1B7F9043, 0xCFB5F4A8, 0x3DDE77AB, 0x2E8E845F, 0xDCE5075C,
  0x92A8FC17, 0x60C37F14, 0x73938CE0, 0x81F80FE3, 0x55326B08, 0xA759E80B, 0xB4091BFF, 0x466298FC,
  0x1871A4D8, 0xEA1A27DB, 0xF94AD42F, 0x0B21572C, 0xDFEB33C7, 0x2D80B0C4, 0x3ED04330, 0xCCBBC033,
  0xA24BB5A6, 0x502036A5, 0x4370C551, 0xB11B4652, 0x65D122B9, 0x97BAA1BA, 0x84EA524E, 0x7681D14D,
  0x2892ED69, 0xDAF96E6A, 0xC9A99D9E, 0x3BC21E9D, 0xEF087A76, 0x1D63F975, 0x0E330A81, 0xFC588982,
  0xB21572C9, 0x407EF1CA, 0x532E023E, 0xA145813D, 0x758FE5D6, 0x87E466D5, 0x94B49521, 0x66DF1622,
  0x38CC2A06, 0xCAA7A905, 0xD9F75AF1, 0x2B9CD9F2, 0xFF56BD19, 0x0D3D3E1A, 0x1E6DCDEE, 0xEC064EED,
  0xC38D26C4, 0x31E6A5C7, 0x22B65633, 0xD0DDD530, 0x0417B1DB, 0xF67C32D8, 0xE52CC12C, 0x1747422F,
  0x49547E0B, 0xBB3FFD08, 0xA86F0EFC, 0x5A048DFF, 0x8ECEE914, 0x7CA56A17, 0x6FF599E3, 0x9D9E1AE0,
  0xD3D3E1AB, 0x21B862A8, 0x32E8915C, 0xC083125F, 0x144976B4, 0xE622F5B7, 0xF5720643, 0x07198540,
  0x590AB964, 0xAB613A67, 0xB831C993, 0x4A5A4A90, 0x9E902E7B, 0x6CFBAD78, 0x7FAB5E8C, 0x8DC0DD8F,
  0xE330A81A, 0x115B2B19, 0x020BD8ED, 0xF0605BEE, 0x24AA3F05, 0xD6C1BC06, 0xC5914FF2, 0x37FACCF1,
  0x69E9F0D5, 0x9B8273D6, 0x88D28022, 0x7AB90321, 0xAE7367CA, 0x5C18E4C9, 0x4F48173D, 0xBD23943E,
  0xF36E6F75, 0x0105EC76, 0x12551F82, 0xE03E9C81, 0x34F4F86A, 0xC69F7B69, 0xD5CF889D, 0x27A40B9E,
  0x79B737BA, 0x8BDCB4B9, 0x988C474D, 0x6AE7C44E, 0xBE2DA0A5, 0x4C4623A6, 0x5F16D052, 0xAD7D5351
};

  static inline uint32_t crc32c_software_simple(uint32_t crc, const uint8_t * data, size_t num_bytes)
  {
    while (num_bytes--)
    {
      crc = (crc >> 8) ^ crc32c_table_small[(crc & 0xFF) ^ *data++];
    }
    return crc;
  }



  uint32_t num_bytes = 32;
  uint32_t num_bytes_padded = num_bytes + sizeof(uint32_t);
  uint8_t * test_data = (uint8_t*) malloc(num_bytes_padded);

  for(uint32_t i = num_bytes; i < num_bytes_padded; i++) test_data[i] = 0;

  for(uint32_t i = 0; i < num_bytes; i++)
  {
    test_data[i] = i;
  }

  binary(num_bytes_padded, test_data);
  hex(num_bytes_padded, test_data);
  uint32_t crc = 0xFFFFFFFF;
  crc = ~crc32c_software_simple(crc, test_data, num_bytes_padded);

  for(uint32_t i = 0; i < sizeof(uint32_t); i++) test_data[num_bytes + i] = ((uint8_t*)&crc)[i];

  crc = 0xFFFFFFFF;
  crc = ~crc32c_software_simple(crc, test_data, num_bytes_padded);

2 个答案:

答案 0 :(得分:1)

您所拥有的是完整的CRC计算,不需要在末尾添加零。它的使用方式是简单地计算消息上的CRC(没有附加任何内容),然后附加计算出的CRC。另一方面,仅在消息(不包括CRC)上计算CRC,并且比较计算出的CRC与传输中消息之后的CRC。而不是寻找零。超级简单,以及对任何哈希值的处理方式。

但是,如果您在消息上计算CRC并且附加的CRC,假设CRC以正确的位和字节顺序编码,则数学确保结果将是是相同的常量,&#34;残差&#34;对于该CRC,所有正确的消息/ CRC组合。在这种情况下的残差不是全零,因为CRC被排除非零常数。如果你愿意的话,可以通过检查残差来做到这一点,但是当你可以比较时,在四个字节上计算CRC似乎是浪费时间,并且为代码添加一些模糊性。

答案 1 :(得分:0)

示例代码执行CRC的后补码。这将导致验证CRC为常量非零值,在这种情况下,如果没有错误(无论消息大小如何),则验证CRC == 0x48674bc7。调用代码需要修复第一次调用crc32c_software_simple,使用num_bytes而不是num_bytes_padded,如下面的评论中所述。

如果没有CRC的后补码,那么验证将产生零CRC。

代码也对CRC进行了预补充,但这不会影响验证。

int main()
{
      uint32_t num_bytes = 32;
      uint32_t num_bytes_padded = num_bytes + sizeof(uint32_t);
      uint8_t * test_data = (uint8_t*) malloc(num_bytes_padded);

      for(uint32_t i = num_bytes; i < num_bytes_padded; i++) test_data[i] = 0;

      for(uint32_t i = 0; i < num_bytes; i++)
      {
        test_data[i] = i;
      }

      uint32_t crc = 0xFFFFFFFF;
      crc = ~crc32c_software_simple(crc, test_data, num_bytes);  // num_bytes fix

      for(uint32_t i = 0; i < sizeof(uint32_t); i++) test_data[num_bytes + i] = ((uint8_t*)&crc)[i];

      crc = 0xFFFFFFFF;
      crc = ~crc32c_software_simple(crc, test_data, num_bytes_padded);
      // if no errors, crc == 0x48674bc7
    return 0;
}