Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

HMAC-sha512 digests

104 views
Skip to first unread message

EL

unread,
Aug 7, 2017, 1:22:06 PM8/7/17
to
Hi,

I have the need to compute the HMAC-sha512 digest of some message (with
some key). Tcllib has sha256, including HMAC-sha256, but apparently no
sha512 or higher.

Is there still a possibility to do that in Tcl, apart from [exec]'ing
openssl?


--
EL

Gerald Lester

unread,
Aug 7, 2017, 7:57:57 PM8/7/17
to
Of course, just code in the algorithm.


--
+----------------------------------------------------------------------+
| Gerald W. Lester, President, KNG Consulting LLC |
| Email: Gerald...@kng-consulting.net |
+----------------------------------------------------------------------+

EL

unread,
Aug 8, 2017, 1:44:06 AM8/8/17
to
Gerald Lester <Gerald...@KnG-Consulting.net> wrote:
>>
>> Is there still a possibility to do that in Tcl, apart from [exec]'ing
>> openssl?
>
> Of course, just code in the algorithm.
>

I am not that much experienced with developing secure hashing algorithms...
unfortunately. Therefore I thought I can rely on something that is already
present ;-).

Seems that wrapping libssl/libcrypto via Ffidl is the way to go for me,
then.


--
EL

stefan

unread,
Aug 8, 2017, 5:32:26 AM8/8/17
to
NaviServer has a Tcl binding to this portion of the OpenSSL API & friends:

see NsTclCryptoHmacObjCmd in https://bitbucket.org/naviserver/naviserver/src/default/nsd/tls.c?fileviewer=file-view-default#tls.c-685

Stefan

EL

unread,
Aug 8, 2017, 3:02:05 PM8/8/17
to
Am 08.08.17 um 11:32 schrieb stefan:
> NaviServer has a Tcl binding to this portion of the OpenSSL API & friends:
>
> see NsTclCryptoHmacObjCmd in https://bitbucket.org/naviserver/naviserver/src/default/nsd/tls.c?fileviewer=file-view-default#tls.c-685
>
> Stefan
>

Interresting, thanks :).

I created a small wrapper with Ffidl now... works like a charm. In case
people are interrested, I updated the wiki page:

http://wiki.tcl.tk/13608

With my small, one-procedure wrapper. It could serve as an entry point
for other crypto related procedures based on openssl and Ffidl.


--
EL

Ralf Fassel

unread,
Aug 9, 2017, 10:38:33 AM8/9/17
to
* EL <elehm...@gmail.com>
| I created a small wrapper with Ffidl now... works like a charm. In case
| people are interrested, I updated the wiki page:
>
| http://wiki.tcl.tk/13608

Not really having understood the workings of ffidl etc: I see you use
"string length" on the TCL data, does that take encodings into account
when passing non-ASCII data to the C level?

R'

EL

unread,
Aug 9, 2017, 2:02:05 PM8/9/17
to
Am 09.08.17 um 16:38 schrieb Ralf Fassel:

> | http://wiki.tcl.tk/13608
>
> Not really having understood the workings of ffidl etc: I see you use

Ffidl uses libffi (https://github.com/libffi/libffi) to call functions
in a shared library via the C ABI. And most if not all of these
functions expect char* arrays with raw bytes, or pointers to structs, or
numeric base types,...
There is some documentation for Ffidl on the wiki here:
http://wiki.tcl.tk/1197, including a link to the old official version
with its documentation. Current development apparently takes place on
github, with a version that works on 8.6, but the old original
documentation is still valid.

> "string length" on the TCL data, does that take encodings into account
> when passing non-ASCII data to the C level?

On binary data I think it makes no difference. With Tcl strings and
encodings it might have an influence whether you use [string bytelen] or
[string len] for that hmac function. But I haven't tested that.
The HMAC function expects char* arrays and their length. Thats why I
made the [binary format] before the call, to make sure it is really a
char array and not a Tcl string (there are subtle errors when passing
Tcl strings to Ffidl hooked functions instead of byte arrays, when byte
arrays are expected).


--
EL

Ralf Fassel

unread,
Aug 10, 2017, 6:37:10 AM8/10/17
to
* EL <elehm...@gmail.com>
| The HMAC function expects char* arrays and their length. Thats why I
| made the [binary format] before the call, to make sure it is really a
| char array and not a Tcl string (there are subtle errors when passing
| Tcl strings to Ffidl hooked functions instead of byte arrays, when byte
| arrays are expected).

Ah, sorry, I had overlooked the [binary format] on both key and data
before passing them to sha512. Should be ok the way you're doing it.

R'

gustafn

unread,
Aug 18, 2017, 12:44:08 PM8/18/17
to
0 new messages