Sylvain Le Gall <sylvain@le-gall.net> writes:

> Hello,
>
> On 22-07-2010, Goswin von Brederlow <goswin-v-b@web.de> wrote:
>> Dario Teixeira <darioteixeira@yahoo.com> writes:
>>
>>> Hi,
>>>
>>>> If you decide to code the solution and provide the patch, I will be
>>>> happy to apply it to cryptokit (if the main author of cryptokit accepts
>>>> it, of course).
>>>
>>> I'm attaching the patches adding support for HMAC-SHA256 and HMAC-RIPEMD160
>>> (I don't need the latter, but for the sake of completeness it seemed silly
>>> not to support it as well).  Note that these are *very* straightforward
>>> patches -- kudos to Xavier for making Cryptokit so easy to extend.
>>>
>>> The caveat is that I'm not a cryptographer.  I did, however, verify that
>>> these new HMACs pass all the test cases listed in RFC4231 (for HMAC-SHA256)
>>> and RFC2286 (for HMAC-RIPEMD160).
>>>
>>> Thanks for your attention!
>>> Cheers,
>>> Dario Teixeira
>>
>> While you are patching cryptokit anyway would it be possible to also add
>> functions to work on Bigarrays?
>>
>
> Well in fact, HMAC-SHA256 and  HMAC-RIPEMD160 has been implemented in
> the source code, but never released. So no patching involved.
>
>> One huge advantage of bigarray is that the data region is allocated
>> outside the GC heap and will never move. That means one can use
>> enter_blocking_section() / leave_blocking_section() while calculating
>> the checksum for a block of data. For multithreaded applications that
>> can speed up the program by the number of cores present.
>>
>
> Submit a feature request with as much data as possible on the BTS:
> https://forge.ocamlcore.org/tracker/?group_id=133
>
> Regards,
> Sylvain Le Gall

Submitted.

MfG
        Goswin