I coded up a somewhat naive literal translation of the the SHA-256 hash algo along with the corresponding HMAC using Larceny (Funny In Head) ERR5RS. I'm actually using a slightly modified build from the latest trunk.
http://github.com/RayRacine/rl3/blob/master/rl3/crypto/hash/sha256.sls Here is the transcript of an example from Amazon's API doc which requires a SHA-256 HMAC. (import (rnrs) (rl3 crypto hash sha256) (rl3 crypto base64) (primitives time)) (define msg "GET\nwebservices.amazon.com \n/onca/xml\nAWSAccessKeyId=00000000000000000000&ItemId=0679722769&Operation=ItemLookup&ResponseGroup=ItemAttributes%2COffers%2CImages%2CReviews&Service=AWSECommerceService&Timestamp=2009-01-01T12%3A00%3A00Z&Version=2009-01-06") (define key "1234567890") (time (base64-encode (hmac-sha256 key msg))) > Words allocated: 4194032 Words reclaimed: 0 Elapsed time...: 998 ms (User: 981 ms; System: 1 ms) Elapsed GC time: 0 ms (CPU: 2 in 4 collections.) "Nace+U3Az4OhN7tISqgs1vdLBHBEijWcBeCqL5xN9xg=" The answer is correct, however, the 1 sec calculation time is a bit longer than anticipated along with the 4 million allocated words. I understand why bitwise manipulations are going to be slower in dynamically typed language with type tag bits. Thought I'd toss it out in the hopes someone may spot a low hanging fruit change in my implementation, recommend some compiler options etc. At a minimum it might make a decent benchmark for grading (rnrs arithmetic bitwise) implementations. If nothing obvious is noted I'll go with an FFI solution. Ray P.S. Noticed the Larceny SVN and mail list has been a bit quiet. Anything new and notable coming down on the Larceny front? 64Bit? Native threads? -- The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane. - Marcus Aurelius
_______________________________________________ Larceny-users mailing list Larceny-users@lists.ccs.neu.edu https://lists.ccs.neu.edu/bin/listinfo/larceny-users