Hi Mindaugas, Many thanks for the feedback.
1) it would be nice to have C also interface and to have names compatible to > existing MD5 hasing; The C interface is there, a Harbour C namespace (and MD5 function) compatible layer can easily be added. > 2) SHA1 is also member of the family and often used (SHA224 is seldom); As far as I could see there is no big overhead in having all four versions bundled together. I guess 256 and 512 are the most often used versions, so if group thinks we can easily remove the rest. I didn't deal with SHA1 because it isn't considered safe anymore (just like MD5). It can easily be added, given we find an implementation with a Harbour compatible licence. Here's one: http://www.aarongifford.com/computers/hmac_sha1.tar.gz (HMAC support is BSD, the rest is PD) Personally, I'd also welcome AES in Harbour. > 3) HMAC calculation is algorithm independent from hasing. Maybe we can have > universal HB_HMAC() instead of HB_*_HMAC(), > I guess code is: > FUNC HB_HMAC(fHash, cMessage, cKey) > IF LEN(cKey) > 64; cKey := HB_HexToStr(EVAL(fHash, cKey)) > ENDIF > cKey := PADR(cKey, 64, CHR(0)) > RETURN EVAL(fHash, HB_STRXOR(cKey, 0x5C) + ; > EVAL(fHash, HB_STRXOR(cKey, 0x36) + cMessage)) Good idea, but I'm personally lost with the details here :) Maybe I should change the names to HB_HMAC_SHA*() from HB_SHA*_HMAC() as a small step, should I? > 4) If there are some licence problem, we can find public domain > implementations. I guess rfc or standarts implementation is also free by > some mean; A public domain one would be great, but couldn't find any. > 5) I'm starting to think about some generic HB_CRYPT*() library. I should > stop think :) Just go ahead :) Brgds, Viktor
_______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
