Re: [Caml-list] Re: Cryptokit and HMAC-SHA256

Re: [Caml-list] Re: Cryptokit and HMAC-SHA256

[Dario Teixeira]

[-- Attachment #1: Type: text/plain, Size: 721 bytes --]

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


      

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: cryptokit.mli.patch --]
[-- Type: text/x-diff; name="cryptokit.mli.patch", Size: 1205 bytes --]

--- cryptokit.mli.old	2010-07-21 22:10:37.000000000 +0100
+++ cryptokit.mli	2010-07-21 22:13:09.000000000 +0100
@@ -483,6 +483,16 @@
         applied to SHA-1.  The returned hash values are 160 bits (20 bytes)
         long.  The [key] argument is the MAC key; it can have any length,
         but a minimal length of 20 bytes is recommended. *)
+  val hmac_sha256: string -> hash
+    (** [hmac_sha256 key] returns a MAC based on the HMAC construction (RFC2104)
+        applied to SHA-256.  The returned hash values are 256 bits (32 bytes)
+        long.  The [key] argument is the MAC key; it can have any length,
+        but a minimal length of 32 bytes is recommended. *)
+  val hmac_ripemd160: string -> hash
+    (** [hmac_ripemd160 key] returns a MAC based on the HMAC construction (RFC2104)
+        applied to RIPEMD-160.  The returned hash values are 160 bits (20 bytes)
+        long.  The [key] argument is the MAC key; it can have any length,
+        but a minimal length of 20 bytes is recommended. *)
   val hmac_md5: string -> hash
     (** [hmac_md5 key] returns a MAC based on the HMAC construction (RFC2104)
         applied to MD5.  The returned hash values are 128 bits (16 bytes)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: cryptokit.ml.patch --]
[-- Type: text/x-diff; name="cryptokit.ml.patch", Size: 691 bytes --]

--- cryptokit.ml.old	2010-07-21 19:33:24.000000000 +0100
+++ cryptokit.ml	2010-07-21 22:03:48.000000000 +0100
@@ -947,9 +947,13 @@
 module MAC = struct
 
 module HMAC_SHA1 = HMAC(struct class h = Hash.sha1  let blocksize = 64 end)
+module HMAC_SHA256 = HMAC(struct class h = Hash.sha256  let blocksize = 64 end)
+module HMAC_RIPEMD160 = HMAC(struct class h = Hash.ripemd160  let blocksize = 64 end)
 module HMAC_MD5  = HMAC(struct class h = Hash.md5  let blocksize = 64 end)
 
 let hmac_sha1 key = new HMAC_SHA1.hmac key
+let hmac_sha256 key = new HMAC_SHA256.hmac key
+let hmac_ripemd160 key = new HMAC_RIPEMD160.hmac key
 let hmac_md5 key = new HMAC_MD5.hmac key
 
 let aes ?iv ?pad key =

Re: [Caml-list] Re: Cryptokit and HMAC-SHA256

[Goswin von Brederlow]

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?

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.

MfG
        Goswin

Re: Cryptokit and HMAC-SHA256

[Sylvain Le Gall]

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

Re: [Caml-list] Re: Cryptokit and HMAC-SHA256

[Dario Teixeira]

Hi,

> Well in fact, HMAC-SHA256 and  HMAC-RIPEMD160 has been implemented in
> the source code, but never released. So no patching involved.

Indeed...  In fact, I had looked into the project's WebSVN before,
but since the last trunk commit was dated from 3 years ago, I assumed
th current release was up-to-date and didn't investigate further.

Anyway, a new release is definitely welcome!

Cheers,
Dario



     

Re: [Caml-list] Re: Cryptokit and HMAC-SHA256

[Goswin von Brederlow]

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