libsodium-php | The PHP extension for libsodium | Cryptography library

If a class is not in any namespace, you can reference from inside a namespace by prefixing it with a leading \, as in $foo = new \Google_Client;

Meanwhile, the string you specify in a use statement isn't a "path" as such, it's just the "fully-qualified class name", that is, the class name with its namespace included on the front. So for a class in no namespace, it's just the name, use Google_Client;

The code was indeed not designed for 32 bit versions of PHP.

If you change P to V, you need to:

• Do it both in calls to unpack() and calls to pack()
• Change the number of bytes read/written from 8 to 4.

But the best thing to do would actually be trying to understand what the code does.

It stores the memory limit and iterations at the beginning of the file, so that these parameters can be recovered later when reading the file, without having to hard-code them.

pack() encodes a value in a fixed number of bytes. unpack() does the opposite. pack('P') encodes a 64 bit value into 8 bytes. unpack('P') reads 8 bytes and converts them into a value.

If your environment doesn't support 64 bit values, pack/unpack to 4 bytes, but you then need to write 4 bytes, not 8. And read 4 bytes as well, not 8.

1. Nothing is totally bulletproof. Anyway, this is far from it. It's your implementation that lacks. First you encrypt it, but then you store the encrypted message along with the secret key in a database.

2. This is all that's required to decrypt it. So any SQL injection flaws OR server/database breaches could compromise the encrypted messages and render it useless. Don't store the private key on the server; especially not with it's intended message. It's nothing more than expensive cleartext if you do that.

3. Don't even store the database connection file in the web root. It's trivial for an hacker to grab that way, look up LFI. You can store it outside e.g. in /var/www/ and serve your index.php from /var/www/public/.

As noted in the comments, it's a little odd what you're doing here anyway. You'd probably be much better off using SSH keys with a pass phrase.

Same on alpine and PHP 7.1... I am installing it via PECL.

There is a bug report about it: https://github.com/jedisct1/libsodium-php/issues/156

You can overcome this issue by forcing to use 2.0.8 until the issue gets fixed: pecl install -f libsodium-2.0.8