HMAC-SHA512
Locked
12
12
 
|
Hi
2018-03-02 11:24 GMT-03:00 Esteban A. Maringolo <[hidden email]>: > 2018-03-02 8:54 GMT-03:00 Ben Coman <[hidden email]>: > >> On 2 March 2018 at 10:43, Esteban A. Maringolo <[hidden email]> wrote: > >>> So after all this what's the recommended way to use HMAC-SHA512 in Pharo >>> 6? > >> Libsodium installation instructions... >> https://github.com/Traadh/bittrex > > Why did you create BittrexLibsodium library wrapper instead of a > plain Libsodium wrapper like the one at > http://smalltalkhub.com/#!/~tonyg/Crypto-Nacl/ ? > > I inspected the Nacl library and it provides the functions: crypto_auth_hmacsha256 crypto_auth_hmacsha256_bytes crypto_auth_hmacsha256_keybytes crypto_auth_hmacsha256_primitive crypto_auth_hmacsha256_ref crypto_auth_hmacsha256_ref_verify crypto_auth_hmacsha256_verify crypto_auth_hmacsha512256 crypto_auth_hmacsha512256_bytes crypto_auth_hmacsha512256_keybytes crypto_auth_hmacsha512256_primitive crypto_auth_hmacsha512256_ref crypto_auth_hmacsha512256_ref_verify crypto_auth_hmacsha512256_verify I've also followed the Ben's example in Nacl but the output is truncated | data message output key expected | data := 'Hi There' . key := (ByteArray readHexFrom: '0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b', '0b0b0b0b') extendedToSize: 32. expected := ByteArray readHexFrom: '87aa7cdea5ef619d4ff0b4241a1d6cb0', '2379f4e2ce4ec2787ad0b30545e17cde', 'daa833b7d6b8a702038b274eaea3f4e4', 'be9d914eeb61f1702e696c203a126854'. output := ByteArray new: 64. Nacl apiCryptoAuthHMAC512: output message: data messageLength: data size key: key. output Nacl class>>apiCryptoAuthHMAC512: c message: m messageLength: mlen key: key ^ self ffiCall: #(long crypto_auth_hmacsha512256(byte * c, byte * m, ulonglong mlen, byte * key)) module: 'libsodium'. Ben do you know what could be happening here? Hernán |
|
|
On 3 March 2018 at 02:22, Hernán Morales Durand <[hidden email]> wrote: Hi If that is the one available from the Pharo Catalog, when I tried it, it used a different api than the libsodium library supplied by Ubuntu 16.04. It makes this call out... crypto_hash_sha512_ref() but Ubuntu libsodium library did not export that, but instead... crypto_hash_sha512() I failed to track down the implications of the "_ref", and at that time Crypto-Nacl did not supply a 64-bit library, so a single FFI matching the system supplied libsodium library was easier. Also as a minor policy, I prefer to use the system library than one compiled by a third-party. cheers -ben >
Just off the top of my head, should the following method properly be named
apiCryptoAuthHMAC512256:message:messageLength:key: to match the library function its calling? Nacl class>>apiCryptoAuthHMAC512: c message: m messageLength: mlen key: key
By how much is it truncated? Perhaps half? cheers -ben |
|
|
In reply to this post by Esteban A. Maringolo
On Fri, Mar 02, 2018 at 11:24:36AM -0300, Esteban A. Maringolo wrote:
> There is a PBKDF2 package made by Udo Schneider, and seems to be > easily pluggable with a different hashing algorithm, so I'd need a > SHA512 class. OpenSSL-Pharo wraps the SHA512 in libcrypto. See LcEvpSHA512Test. https://github.com/PierceNg/OpenSSL-Pharo Pierce |
|
|
2018-03-04 0:45 GMT-03:00 Pierce Ng <[hidden email]>:
> On Fri, Mar 02, 2018 at 11:24:36AM -0300, Esteban A. Maringolo wrote: >> There is a PBKDF2 package made by Udo Schneider, and seems to be >> easily pluggable with a different hashing algorithm, so I'd need a >> SHA512 class. > > OpenSSL-Pharo wraps the SHA512 in libcrypto. See LcEvpSHA512Test. > > https://github.com/PierceNg/OpenSSL-Pharo Thank you Pierce, I managed to make play the SHA classes of your OpenSSL wrapper with the PBKDF2 from Udo's plus HMAC from the Cryptography package. I sent you a pull-request <https://github.com/PierceNg/OpenSSL-Pharo/pull/1> that includes missing accessors that I needed to achieve the above interplay. The end result is this: https://github.com/eMaringolo/pharo-bip39mnemonic What I'm missing is a better PRNG to generate random numbers from 128 to 256 bits. But my main objective was a proof of concept that ended up being successful. Thanks for your help. Esteban A. Maringolo |
|
|
On Sun, Mar 04, 2018 at 04:00:23PM -0300, Esteban A. Maringolo wrote:
> Thank you Pierce, I managed to make play the SHA classes of your > OpenSSL wrapper with the PBKDF2 from Udo's plus HMAC from the > Cryptography package. > I sent you a pull-request > <https://github.com/PierceNg/OpenSSL-Pharo/pull/1> that includes > missing accessors that I needed to achieve the above interplay. Thanks Esteban. Pull request merged. > The end result is this: https://github.com/eMaringolo/pharo-bip39mnemonic Cool! > What I'm missing is a better PRNG to generate random numbers from 128 > to 256 bits. OpenSSL has RAND_* functions waiting to be wrapped. :-) Or, if your code is running on a modern Unix-like system, read directly from /dev/random or /dev/urandom. Pierce |
|
In reply to this post by Ben Coman
On Fri, Mar 2, 2018 at 9:40 PM, Ben Coman <[hidden email]> wrote:
[...] > > If that is the one available from the Pharo Catalog, when I tried it, it > used a different api than the libsodium library supplied by Ubuntu 16.04. > > It makes this call out... > crypto_hash_sha512_ref() > but Ubuntu libsodium library did not export that, but instead... > crypto_hash_sha512() > > I failed to track down the implications of the "_ref", > and at that time Crypto-Nacl did not supply a 64-bit library, > so a single FFI matching the system supplied libsodium library was easier. > Also as a minor policy, I prefer to use the system library than one compiled > by a third-party. > > cheers -ben Hi, Yes, I recommend using the OS/package-manager supplied libsodium (based on https://github.com/jedisct1/libsodium). The downloads provided on Tony's site were based on early commits that exported the "_ref" functions instead: commit e144f9d40d5695b69306bde729d6d8adcd62b1c4 Author: Frank Denis <[hidden email]> Date: Mon Apr 22 16:30:31 2013 -0700 crypto_hash_sha(256|512) are the exported functions that have to be exported. _ref are implementations, that shouldn't be exported. To be useful, http://smalltalkhub.com/#!/~tonyg/Crypto-Nacl/ should be updated to use a system-supplied libsodium. Best, Mike |
|
|
On 8 March 2018 at 02:38, Michael Forster <[hidden email]> wrote: On Fri, Mar 2, 2018 at 9:40 PM, Ben Coman <[hidden email]> wrote: Thanks for clarifying that.
Or at least to the later api. In general there is some advantage in packaging the C-lib with the Smalltalk package for people experimenting with it the first time, to ensure the function prototypes match. But flipping into production may prefer the system library. Currently it seems awkward to switch later to a system library since the library used is hard coded. How do others work around that? Perhaps it would be good to have the external library initialized into an instance variable of FFILIbrary, so a user-application can change the external C-library used without changing code in someone else's ffi-interface package. cheers -ben P.S. On the dream list would be a GUI for managing referenced external C-libraries, including browsing their exported functions. |
|
|
2018-03-07 23:07 GMT-03:00 Ben Coman <[hidden email]>:
> > > On 8 March 2018 at 02:38, Michael Forster <[hidden email]> wrote: >> >> On Fri, Mar 2, 2018 at 9:40 PM, Ben Coman <[hidden email]> wrote: >> [...] >> > >> > If that is the one available from the Pharo Catalog, when I tried it, it >> > used a different api than the libsodium library supplied by Ubuntu >> > 16.04. >> > >> > It makes this call out... >> > crypto_hash_sha512_ref() >> > but Ubuntu libsodium library did not export that, but instead... >> > crypto_hash_sha512() >> > >> > I failed to track down the implications of the "_ref", >> > and at that time Crypto-Nacl did not supply a 64-bit library, >> > so a single FFI matching the system supplied libsodium library was >> > easier. >> > Also as a minor policy, I prefer to use the system library than one >> > compiled >> > by a third-party. >> > >> > cheers -ben >> [...] >> >> >> Hi, >> >> Yes, I recommend using the OS/package-manager supplied libsodium >> (based on https://github.com/jedisct1/libsodium). The downloads >> provided on Tony's site were based on early commits that exported the >> "_ref" functions instead: >> >> commit e144f9d40d5695b69306bde729d6d8adcd62b1c4 >> Author: Frank Denis <[hidden email]> >> Date: Mon Apr 22 16:30:31 2013 -0700 >> >> crypto_hash_sha(256|512) are the exported functions that have >> to be exported. >> _ref are implementations, that shouldn't be exported. > > > Thanks for clarifying that. > > >> >> >> To be useful, http://smalltalkhub.com/#!/~tonyg/Crypto-Nacl/ should be >> updated to use a system-supplied libsodium. > > > Or at least to the later api. In general there is some advantage in > packaging the C-lib with the Smalltalk package > for people experimenting with it the first time, to ensure the function > prototypes match. But flipping into production > may prefer the system library. Currently it seems awkward to switch later to > a system library since the library used is hard coded. Hi Ben, "system library" means it's pre-installed in some Linux distros? I installed a Debian 4.9.65-3+deb9u1 (2017-12-23) last week and libsodium is not present. I use Windows and also isn't available by default. In any case, how do you ensure libsodium system lib matches your interface code? What do you do now if target has a different version? > How do others work around that? > > Perhaps it would be good to have the external library initialized into an > instance variable of FFILIbrary, > so a user-application can change the external C-library used without > changing code in someone else's ffi-interface package. > > cheers -ben > > P.S. On the dream list would be a GUI for managing referenced external > C-libraries, including browsing their exported functions. That would be really cool Hernán |
|
|
On 8 March 2018 at 12:22, Hernán Morales Durand <[hidden email]> wrote:
I installed a Debian 4.9.65-3+deb9u1 (2017-12-23) last week and For Linux, system libraries are not only pre-installed, but rather whatever is available in the default system repository, simply installed with a single command like... $ sudo apt-get install libsodium All such installed packages receive security updates by doing... $ sudo apt-get update $ sudo apt-get upgrade I use Windows and also isn't available by default. Unfortunately Windows lacks a standard repository with a broad range of open source packages installable with a single command. Here it makes more sense to auto-install some package. Perhaps a particular version from the project In any case, how do you ensure libsodium system lib matches your interface code? What do you do now if target has a different version? Good question. I guess its unit tests and manual effort. The next question is whether its worth the effort. For a given production environment, you might take a hit every couple of years when you move distro-versions. For a more turnkey system suiting a broader range of new users, maybe downloading a particular version of libsodium from the project site is a better option. Checking just now i see the Ubuntu 16.04 LTS libsodium library is version 1.0.8... which actually is unsupported... so perhaps downloading from the project site is a better option. cheers -ben P.S. Did you indicate Crypto-Nacl was being (or could be) updated to latest libsodium? If it could, and the auto-installed library was downloaded and sig-checked from the project site, I'd be interested in dropping my own hack and using Crypto-Nacl.
|
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |