ajgb / crypt-nacl-sodium Goto Github PK

Hi @ajgb, I'm currently trying to tidy up the bindings linked on the libsodium website. If this library is still maintained, then please let me know; otherwise, the link to this library will likely be removed from the bindings page to help users find up to date and maintained bindings.

when i try to use this module, it says AES256-GCM is not supported by this CPU.

Hi,

I have a question about internal workflows of Crypt::NaCl::Sodium::sign and Data::BytesLocker

Consider following code:

#!/bin/env perl

use strict;
use warnings;
use Crypt::NaCl::Sodium qw/:utils/;

my $secret = hex2bin('a25b84b660c62019b7db57fc612e52a0accf99bd17490f4d65d3c118c09970e90a20c8312f2bbeb4a377a151e25fff1ec7be049526716a64b771e26e44a56bcc');
my $bl = Data::BytesLocker->new($secret);

my $crypto_sign = Crypt::NaCl::Sodium->sign();
my $mac = $crypto_sign->mac('message to sign', $bl);
printf "mac: %s\n", $mac->to_hex;

base on my evaluation of $crypto_sign->mac() and Data::BytesLocker's stringification method I conclude that the workflow leave copy of secret in RAM as a side effect of computing mac. This is because mac() calls SvPV(seckey, skey_len) which calls stringification method which in return does newSVpvn() on secret data.

newSVpvn:

Creates a new SV and copies a string into it, which may contain NUL characters (\0 ) and other binary data. 

I double checked this workflow by amending above code to:

#!/bin/env perl

use strict;
use warnings;
use Crypt::NaCl::Sodium qw/:utils/;

my $secret = hex2bin('a25b84b660c62019b7db57fc612e52a0accf99bd17490f4d65d3c118c09970e90a20c8312f2bbeb4a377a151e25fff1ec7be049526716a64b771e26e44a56bcc');
my $bl = Data::BytesLocker->new($secret);
bless $bl, 'Data::BytesLocker::NoOverloading';

my $crypto_sign = Crypt::NaCl::Sodium->sign();
my $mac = $crypto_sign->mac('message to sign', $bl);
printf "mac: %s\n", $mac->to_hex;
exit 0;

package Data::BytesLocker::NoOverloading;
use parent '-norequire', 'Data::BytesLocker';
use overload '""' => sub { warn "stringification access"; my $coderef = Data::BytesLocker->can('(""'); $coderef->(@_) }, 'fallback' => 1;
1;

this outputs:

stringification access at test.pl line 18.
mac: b412a4b610f4fb1e855153ab4bb4d8a3d4ec2efadd10c4e4b670f82a01e3f979762d00626928b2415257990db091c01419114c64db2e55ee6ae22a25186e3003

Does this sound right?

If so I would expect $crypto_sign->mac() to access underlying mprotected Data::BytesLocker's buffer directly and not silently copying protected data to unprotected memory region.

I have libsodium installed by debian:

$ dpkg -l libsodium18
ii  libsodium18:amd64                    1.0.11-1

$ dpkg -l libsodium-dev
ii  libsodium-dev:amd64                  1.0.11-1

By convincing Alien::Sodium that this is sufficient for it, that now builds and installs, in a state where it just wraps this pkg-config-provided library:

$ perl -MAlien::Sodium -E'say Alien::Sodium->libs'
-lsodium

$ perl -MAlien::Sodium -E'say Alien::Sodium->cflags'
[empty]

This ought to be sufficient to build Crypt::NaCl::Sodium, but it is not:

$ perl Makefile.PL 
Is Alien::Sodium available? Could not locate libsodium.a in /usr/share/perl5/auto/share/dist/Alien-Sodium/lib

I believe this is because Makefile.PL is being overly picky about looking for the libsodium.a file, rather than just trusting whatever pkg-config (via Alien::Sodium) told it.

Compatibility issue when installing Crypt::NaCl::Sodium on Debian server

Description:
I'm trying to install the Perl module Crypt::NaCl::Sodium on my Debian server, but I'm running into compatibility issues with the libsodium library. The installation fails with several error messages indicating missing functions and constants in libsodium.

Installation attempt:

Command used: sudo cpanm Crypt::NaCl::Sodium
Error message: The most important errors relate to undefined identifiers such as crypto_stream_aes128ctr_NONCEBYTES, crypto_stream_aes128ctr_KEYBYTES and crypto_stream_aes128ctr.
System details:

Operating system: Debian 12 (latest version)

uname -mi
x86_64 unknown

Perl version: 5.036000
libsodium version: 1.0.19
Steps already taken:

Attempting to install via CPANminus.
Checking and uninstalling the current libsodium version.
Try to find and install an older version of libsodium that contains the required features.
Main problem:
The main problem seems to be that the required features (crypto_stream_aes128ctr_*) are not present in the current version of libsodium (1.0.19) and I'm having difficulty finding an older version of libsodium that includes these features.

Solution sought:
I'm looking for a way to either find and install a compatible version of libsodium or an alternative solution to successfully install Crypt::NaCl::Sodium on my Debian server.

I have tried the following without success:
sudo apt-get remove --purge libsodium-dev
wget http://archive.debian.org/debian/pool/main/libs/libsodium/libsodium18_1.0.11-2_amd64.deb
sudo dpkg -i libsodium18_1.0.11-2_amd64.deb
sudo cpanm Crypt::NaCl::Sodium

The solution mentioned in the forum and wiki doesn't work for me:

`cpan Crypt::NaCl::Sodium --force
...
make: *** [Makefile:367: Sodium.o] Fehler 1
AJGB/Crypt-NaCl-Sodium-1.0.8.0.tar.gz
/usr/bin/make -- NOT OK

(error): Could not expand [--force]. Check the module name.
(info): I can suggest names if you install one of Text::Levenshtein::XS, Text:: Levenshtein::Damerau::XS, Text::Levenshtein, and Text::Levenshtein::Damerau::PP
(info): and you provide the -x option on invocation.
(error): Skipping --force because I couldn't find a matching namespace.`

I've been trying to build a debian package of this distribution. For long and complex reasons, anything derived from Alien::Base is more awkward here than I'd like. Instead of building libsodium via that method, I've gone and built a native debian package for it.

I then applied a relatively small hack to your Makefile.PL to avoid the use of Alien::Sodium and instead use ExtUtils::PkgConfig directly. This patch is currently applied as part of my debian package.

I have libsodium version 1.0.11 installed, and have managed to get Crypt::NaCl::Sodium to build against it.

If I do that, one single test fails; it is lines 53-54 of t/sodium_sign.t:

my $mod_opened = $crypto_sign->open( $mod_sealed, $pk_bin );
is(bin2hex($mod_opened), $test->{msg}, "message $t is malleable");

The failure:

t/sodium_sign.t ............. 1/? Message forged at t/sodium_sign.t line 53, <TEST> line 1024.
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 255 just after 8.
t/sodium_sign.t ............. Dubious, test returned 255 (wstat 65280, 0xff00)
All 8 subtests passed 

Simply commenting out this single test allows the others to pass.

I am unsure yet whether this is a fragile test that ought to have failed anyway, that it's correctly identifying a real bug in libsodium 1.0.11, or what's going on.

Hi,
could you update your library to libsodium 1.0.18 ?

Cheers,
Xavier

Would you mind to add Alien::Sodium to the actual dependency list in the meta data so that it will automatically be installed by cpan before Crypt::NaCl::Sodium?

Maybe even Alien::Base::ModuleBuild could be added at least as a recommended package as Alien::Sodium only refers to Alien::Base and Alien::Base::ModuleBuild would still be missing. I have asked you here ajgb/alien-sodium#4 to approve a pending pull request that would solve that issue properly but it seems the request is pending since 3 years already and there is no much hope... Maybe this issue request might help in any way to fix both modules?