Hi,
I've found the python CrcMoose library. The CRC algorithm I seemed to need CRC16X was different from CCITT and CRC16IBM or modbus.
I've converted the CrcMoose library to pike and attached it to this email. The original module (python) can be found here: http://www.nightmare.com/~ryb/
I'd like to opt to get this module into Crypto if possible. I'm not sure how this works with his license in the original file.
/Marc
Says it's MIT license, and it looks pretty liberal to me. Don't think it should be a problem, but I don't know for sure. Then also the language conversion might very well make it textually different enough to not be covered by the original author's copyright at all.
If it's to be added to Pike, I'd like to see that it fits the naming conventions better (see http://pike.ida.liu.se/development/cvs/ policies.xml#naming-conventions).
Martin Nilsson (Opera Mini - AFK!) @ Pike (-) developers forum wrote:
A CRC doesn't really have much to do with Crypto though...
It's a checksum, just like MD5, but I concur that CRC (contrary to MD5) should probably live in a generic math-algorithm section instead.
It's a checksum, just like MD5,
Yes, it's a checksum, just like MD5, but it is not a cryptographic algorithm like MD5. MD5 is in Crypto because it is a cryptographic algorithm, not because it is a checksum. And CRC should not be in Crypto not because it is not a checksum, but because it is not a cryptographic algorithm. The reason that CRC is not a cryptographic algorithm is that _unlike_ MD5, it can only find accedental changes of the data, not malicious ones.
By the way, I think that for the same reason Substitution shouldn't be in Crypto either. It can only protect against accidental loss of confidentiality, not malicious.
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
By the way, I think that for the same reason Substitution shouldn't be in Crypto either. It can only protect against accidental loss of confidentiality, not malicious.
In the same vein, CRC functions can be considered weak ciphers. So, I retract my earlier support for not placing it under Crypto, and suggest we add them under Crypto since they are useful on similar streams and essentially need the same interface(s).
I think they could be under Crypto too, regardless of cryptographic weakness. The reason is simply that it's the de-facto place for stuff like that; that's where at least I - without a doubt - would look first.
But if they are to be added to the Crypto module, they should be fixed to follow the same API as the other hash functions though. I think that'd be preferable regardless where in Pike they're added, as well. Besides, the naming convention for functions in Pike is_like_this, and notthisway.
And to get back to the question of where to put it:
"Standards"? Works, but the counter argument is that there really isn't a standard.
Introduce a toplevel "Hash" och "Checksum" module? Works too, but if "Hash" is introduced the cryptigraphic ones should probably be exposed there too.
Could someone do a survey over how other languages have handled it?
How to calculate a CRC is a standard, which parameters to use is not, but that module provides all the common variants, so I think Standards would fit well.
but practically everything fits under standards, i'd rather avoid that category.
btw: a search for crc in python reveals: binascii.crc32 binascii.crc_hqx zipfile.ZipInfo.CRC zlib.crc32
not very helpful...
greetings, martin.
Yes, but as opposed to everything I think Standards (or Crypto) is where people expect it to be. :)
I don't think anyone _expects_ to find anything in "Standards". It's the place you go look in when you have looked everywhere else excepts "Tools".
pike-devel@lists.lysator.liu.se
-
Marc Dirix -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum -
Martin Bähr -
Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Mirar ＠ Pike developers forum
-
Peter Bortas ＠ Pike developers forum
-
Stephen R. van den Berg