title: Robust incremental CRC32
body: <p>I am implementing a flash integrity check for an STM32F10x MCU-based board. This check needs to process the program flash, one block at a time, i.e. 64-byte block per CRC32 invocation, because it needs to be periodic and interruptible.</p>
  
  <p>Unfortunately, CRC hardware in STM32F10x doesn't allow configuring the initial checksum for the CRC32, so effectively, for each block CRC32 algorithm starts with 0xFFFFFFFF. </p>
  
  <p>I am looking for a way to "merge" these checksums to provide some signature that would be more robust than a trivial XOR of all the checksums. This XOR solution has a problem with swapping of the order of blocks and, of course, the traditional "even number of errors cancels itself" kind of problem.</p>
  
  <p>What would be a better way of integrity checking of blocks sequence in this case? Would the following pseudo-code be "good enough":</p>
  
  <pre class="lang-c prettyprint-override"><code>checksum = 0xffffffff;
  for (idx=0; idx&lt;size_in_blocks; idx++)
  {
      CRC_ResetDR();
      checksum = (checksum &gt;&gt; 8) ^ CRC_CalcBlockCRC(blocks[idx], block_size)
  }
  
  </code></pre>
  
  <p>We can't calculate the whole flash CRC32 in one go, as it takes a too long time, and the CRC HW block is used by other entities in the OS as well, i.e. can be reset in the middle.</p>
  
  <p><em>NOTE</em>: there is no need to reconstruct the exact CRC32 as if it would be a one single CRC32 input block. If it can be done, this would be even better, but it can be just reliable enough to guarantee a certain lack of flash manipulation.</p>
  
  <p><em>Edited</em>: Clearly, CRC32 is not a cryptographic hash, so the word "cryptography" was taken off the title. </p>