gchq / CyberChef

The Cyber Swiss Army Knife - a web app for encryption, encoding, compression and data analysis
https://gchq.github.io/CyberChef
Apache License 2.0
28.97k stars 3.25k forks source link

Operation request: Fletcher-32 and -64 checksums #51

Closed n1474335 closed 7 years ago

n1474335 commented 7 years ago

Request summary

Development of operations to calculate Fletcher-32 and Fletcher-64 checksums. CyberChef already supports Fletcher-16 (example and code).

Example input and output

Fletcher-32 Input: Test Output: 03d901a0

Fletcher-64 Input: Test Output: Currently unavailable

Resources

https://en.wikipedia.org/wiki/Fletcher%27s_checksum

0xTowel commented 5 years ago

@n1474335 Is there a reason for doing the operations byte-wise, even with 32-bit sums in Fletcher64? Reading the Wikipedia page, it seems as if operations should work on the data as 32-bit chunks, but the original paper from Fletcher doesn't address sizes greater than Fletcher16.

For example, Fletcher64('AAAABBBB') as 0xc4c4c4c483838383 rather than 0x92e0000020c.

Reading RFC 1146, Appendix II, it seems the "proper" method would be to work on the data as 32-bit chunks (since the 16-bit Fletcher described, which generates a 32-bit checksum, would use 16-bit chunks).

APPENDIX II: The 16-bit Fletcher Checksum Algorithm The 16-bit Fletcher Checksum algorithm proceeds in precisely the same manner as the 8-bit checksum algorithm,, except that A, B and the D[i] are 16-bit quantities. It is necessary (as it is with the standard TCP checksum algorithm) to pad a datagram containing an odd number of octets with a zero octet.

Really looking for the rationale between choosing to do it byte-wise. Is there a specific reason or standard for that?