Currently the Crc class in algorithms.py can only feed a single string into algo. This should be changed to separate initialization (xor-in), feeding and finalization (xor-out). This has the following advantages:
- The File input can use the same mechanism, the current file-feeding implementation is sort of a workaround
- We can run through the algorithm one feed-unit at a time. This is nice, e.g., when searching for a given initial state when running a CRC backwards (with reflected poly and reflected input) until a start-state is reached
- We could feed bit-wise for the bitwise variants
To make this work I'd separate the single Crc class into three classes, each one implementing the given variant, e.g. CrcBitByBit, CrcTableDriven, ... because the feeding is probably not compatible across the variants.
This would also allow bitwise feeding for the bitwise algos: My use-case here is finding the number of excess bits at the end of a message described in the section "Clearing Up some Puzzles" of Gregory Ewings "Reverse-.Engineering a CRC Algorithm": Here we're running a CRC with only the polynomial known over a XOR of two different messages that differ by only one bit (Greg calls this a difference-message). This is used to discover how far to go (over how much data the original CRC was computed, if it included additional data after the contents we know about). The Algo is initialized with the poly in the register and run until the known CRC is reached (the CRC of two XORed messages is the XOR of both CRC values)
If the 1-bit difference is not on a byte boundary this fails. So we need a way to bitwise feed the algorithm (with zeros in this use-case).
Do we have a regression test? In that case I'd do a stab at this and propose a code-change.
Currently the Crc class in algorithms.py can only feed a single string into algo. This should be changed to separate initialization (xor-in), feeding and finalization (xor-out). This has the following advantages:
To make this work I'd separate the single Crc class into three classes, each one implementing the given variant, e.g. CrcBitByBit, CrcTableDriven, ... because the feeding is probably not compatible across the variants.
This would also allow bitwise feeding for the bitwise algos: My use-case here is finding the number of excess bits at the end of a message described in the section "Clearing Up some Puzzles" of Gregory Ewings "Reverse-.Engineering a CRC Algorithm": Here we're running a CRC with only the polynomial known over a XOR of two different messages that differ by only one bit (Greg calls this a difference-message). This is used to discover how far to go (over how much data the original CRC was computed, if it included additional data after the contents we know about). The Algo is initialized with the poly in the register and run until the known CRC is reached (the CRC of two XORed messages is the XOR of both CRC values)
If the 1-bit difference is not on a byte boundary this fails. So we need a way to bitwise feed the algorithm (with zeros in this use-case).
Do we have a regression test? In that case I'd do a stab at this and propose a code-change.