~ This is part of the EuCrypt series. Start with Introducing EuCrypt. ~
The communication protocol for Eulora uses CRC32 as checksum for its packages and so I found myself looking in disbelief at the fact that GNAT imposes the use of Streams for something as simple as calculating the checksum of anything at all, no matter how small no matter what use, no matter what you might need or want or indeed find useful, no matter what. No matter! As usual, the forum quickly pointed me in the right direction - thank you ave1! - namely looking under the hood of course, in this case GNAT's own hood, the Systems.CRC32 package. Still, this package makes a whole dance of eating one single character at a time since it is written precisely to support the stream monstrosity on top rather than to support the user with what they might indeed need. Happily though, CRC32 is a very simple thing and absolutely easy to lift and package into 52 lines of code in the .adb file + 130 in the .ads file so 182 all in total1, comments and two types of input (string or raw array of octets) included. And since a CRC32 implementation is anyway likely to be useful outside of Eulora's communication protocol too, I'm adding it as a .vpatch on the EuCrypt tree where it seems to fit best at the moment. It's a lib on its own as "CRC32" when compiled via its own crc32.gpr or otherwise part of the aggregate EuCrypt project if you'd rather compile all of EuCrypt via its eucrypt.gpr.
My CRC32 lib uses the 0x04C11DB7 generator polynomial and a lookup table with pre-calculated values for faster execution. As Stanislav points out, implementing the actual division and living with the slow-down incurred is not a huge problem but at least for now I did not bother with it. The CRC32 lib provides as output 32 bits of checksum for either a string or an array of octets. At the moment at least I really don't see the need for anything more complicated than this - even the string-input method is more for the convenience of other/later uses than anything else. For my own current work on Eulora's protocol I expect to use CRC32 on arrays of octets directly.
The .vpatch adding CRC32 to EuCrypt and my signature for it are as usual on my Reference Code Shelf with additional links here for your convenience:
Specifically: 52 lines is the count of crc32.adb that does the work. The .ads file brings in another 130 lines that are mostly the lookup table with pre-calculated values. The .gpr file has another 61 lines and the restrict.adc another 80 lines. ↩
Comments feed: RSS 2.0
Nice work!
Thanks!
Hi Diana,
Nice implementation, easy to read!
I implemented a version that does the division (I use the same CRC32 type). This turned out to be a nice exercise; the message bits, as specificied for CRC32, have a reversed bit order (the xor at the start and end gave me some problems in the first implementation).
I do like the tricks that can be played with the shifts and the xors to get to the table implementation!
Nice work ave1! Would you make it a .vpatch on top of the Eucrypt tree? I really think it should be in there as alternative, I don't see any reason why not. After all, user can choose which patches to press and/or whether to keep/use the whole or only parts of it.
No problem, as patch with a signature (OK, small problem as apparently the string concatenation triggered a restriction);
http://ave1.org/code/eucrypt/eucrypt_crc32_div.vpatch.ave1.sig
http://ave1.org/code/eucrypt/eucrypt_crc32_div.vpatch
Thank you! The eucrypt_crc32_divtronic.vpatch works great as alternative press path and I've signed it + mirrored it on my shelf: http://ossasepia.com/reference-code-shelf/#selection-429.0-443.46
[...] directly CRC32 to calculate the checksums as and when needed. The CRC32 is the previously published table-lookup CRC32 implementation from EuCrypt, now integrated into SMG Comms and slightly adapted to use the Octets type in [...]