invertedtomato / crc Goto Github PK

Hi Ben,

The HexStringExtensions is what Convert.ToHexString is for .NET 5+. Extending the API with e.g. the (Byte[], Int32, Int32) overload would make it even more useful.

In terms of speed, the analysis in https://stackoverflow.com/questions/311165/how-do-you-convert-a-byte-array-to-a-hexadecimal-string-and-vice-versa/624379#624379 indentifies https://stackoverflow.com/questions/311165/how-do-you-convert-a-byte-array-to-a-hexadecimal-string-and-vice-versa/24343727#24343727 as a much faster approach than the current BitConverter based approach.

These are just ideas. Feel free to accept or reject.

Best regards,
Matthias

Hi Ben,

I've come across your pretty clean and extensive CRC library, looking for something just like this for https://sourceforge.net/projects/y-a-terminal/, for adding e.g. Modbus capabilities.

Nugetting releases is fine. But sometimes, for debugging, I like to see the related source code. Unfortunately, your git repo doesn't show any tags that correspond to the releases, neither are github releases available. Consequently, looking at today's code, I cannot see whether or not this is the code running in version 1.3.0 of the library.

Could this be improved for future releases? And could you tag the last 1.3.0 release?

Best regards,
Matthias

Hi Ben

The package directories \InvertedTomato.Crc.1.3.0\lib\*\ only contain the InvertedTomato.Crc.dll, but no accompanying InvertedTomato.Crc.xml. Please generate and deploy.

Best regards,
Matthias

anyone also experiencing this?

Could not load file or assembly 'InvertedTomato.Crc' or one of its dependencies. Strong name signature could not be verified. The assembly may have been tampered with, or it was delay signed but not fully signed with the correct private key. (Exception from HRESULT: 0x80131045)

Hello, I have been trying to benchmark several C# and native implementations of CRC32 and CRC64. However, I found BenchmarkDotNet complaining about non-optmized binaries of InvertedTomato.Crc. Please update the nuget packages to the Release build, so people can use the optimized build.

• This library was the one of few libraries where I could find the CRC64 implementations. Thanks for your work!

C:\Joveler\Joveler.Compression\Benchmark>dotnet run -c Release -- hash
// Validating benchmarks:
Assembly Benchmark which defines benchmarks references non-optimized InvertedTomato.Crc
        If you own this dependency, please, build it in RELEASE.
        If you don't, you can disable this policy by using 'config.With(ConfigOptions.DisableOptimizationsValidator)'.

ToHexString is an opinionated rendering of the hash. The has should be output as an int or byte[] and the consumer should determine how that is rendered.

8-bit bound algorithms covered by Rust crc_all not yet covered by InvertedTomato.Crc:

• CRC-8/AUTOSAR
• CRC-8/BLUETOOTH
• CRC-8/GSM-A
• CRC-8/GSM-B
• CRC-8/LTE
• CRC-8/NRSC-5
• CRC-8/OPENSAFETY
• CRC-8/SAE-J1850
• CRC-8/SMBUS
• CRC-8/TECH-3250

https://reveng.sourceforge.io/crc-catalogue/1-15.htm lists them as well.

• CRC-16/CMS
• CRC-16/GSM
• CRC-16/LJ1200
• CRC-16/NRSC-5
• CRC-16/OPENSAFETY-A
• CRC-16/OPENSAFETY-B
• CRC-16/PROFIBUS

https://reveng.sourceforge.io/crc-catalogue/16.htm lists them as well. Interestingly, this link also reveals "CRC-A" as "CRC-16/ISO-IEC-14443-3-A".

• CRC-24/BLE

• CRC-24/INTERLAKEN

• CRC-24/LTE-A

• CRC-24/LTE-B

• CRC-24/OS-9

• CRC-32/AUTOSAR

https://reveng.sourceforge.io/crc-catalogue/17plus.htm lists them as well. Even more:

• CRC-64/GO-ISO
• CRC-64/MS
• CRC-64/REDIS

Maybe better to extract this into a separate issue.

Originally posted by @maettu-this in #9 (comment)

          Endianness sometimes is a beast, the "TODO" in your code isn't for nothing:

I have created https://dotnetfiddle.net/OYNy6O that uses https://learn.microsoft.com/en-us/dotnet/api/system.io.hashing.crc32. https://crccalc.com/?crc=123456789&method=CRC-32&datatype=ascii&outtype=0 results in CRC of 0xCBF43926. The fiddle results in the same.

Now, crc.GetCurrentHash() "emits the answer in the Little Endian byte order", e.g. the LSB [0] is 0x26. This sequence is the reversed of the result of your CrcAlgorithm.ToByteArray(), which is:

It took me quite a while to conclude on this. The method's summary "...the CRC of the bytes that..." doesn't help much. While it is OK to have CrcAlgorithm.ToByteArray() reverse to big-endian, I think this must be improved, as other users likely fall into the same pit. Ideas:

• Leave ToByteArray() as is, but better comment its behavior.
• Add new methods following the NonCryptographicHashAlgorithm like [GetCurrentHash](https://learn.microsoft.com/en-us/dotnet/api/system.io.hashing.noncryptographichashalgorithm.getcurrenthash?view=dotnet-plat-ext-7.0#system-io-hashing-noncryptographichashalgorithm-getcurrenthash), with equal semantic.
• Deprecate ToByteArray().

Originally posted by @maettu-this in #9 (comment)

Hi Ben,

CrcAlgorithm already is quite close to NonCryptographicHashAlgorithm, the base for e.g. Crc32 (https://learn.microsoft.com/en-us/dotnet/api/system.io.hashing.crc32), but there are subtle differencies:

• Width rather than HashLengthInBytes
• No support for Append(Stream)
• Clear() rather than Reset()
• No GetHashAndReset()
• ...

Aligning the API would enable deriving from NonCryptographicHashAlgorithm for .NET 6+.

Also note the remark "this stable output is the byte sequence { 0x1C, 0xDF, 0x44, 0x21 }, the Little Endian representation of 0x2144DF1C" which relates to your "TODO" (https://github.com/invertedtomato/crc/blob/master/Library/CrcAlgorithm.cs#L11). I think this "TODO" can be completed by equally documenting the output. A user can still reverse/rearrange the resulting CRC as needed.

Best regards,
Matthias

Hi Ben,

In order to include InvertedTomato.Crc into libraries or applications that use strong-names, InvertedTomato.Crc must be signed with a strong name. Please refer to https://learn.microsoft.com/en-us/dotnet/standard/assembly/create-use-strong-named and https://github.com/dotnet/runtime/blob/main/docs/project/strong-name-signing.md.

Because of the viral nature of strong-naming, it is recommended that publicly published .NET libraries are strong-named. Not strong-naming a .NET library excludes anyone who does need to strong-name their application or library from using it.

Best regards,
Matthias