terl / lazysodium-java

A Java implementation of the Libsodium crypto library. For the lazy dev.

Lazysodium for Java

Lazysodium is a complete Java (JNA) wrapper over the Libsodium library that provides developers with a smooth and effortless cryptography experience.

Features

This library is fully compatible with Kotlin.

You can find an up-to-date feature list here.

Quick start

Please view the official documentation for a more comprehensive guide.

The following example is for users of the build tool Gradle:

// Top level build file
repositories {
    // Add this to the end of any existing repositories
    mavenCentral() 
}

// Project level dependencies section
dependencies {
    implementation "com.goterl:lazysodium-java:VERSION_NUMBER"
    implementation "net.java.dev.jna:jna:JNA_NUMBER"
}

Substitute VERSION_NUMBER for the version in this box:

Substitute JNA_NUMBER for the latest version of JNA.

Documentation

Please view our official documentation to get started.

Examples

There are some example projects available here.

Lazysodium for Android

We also have an Android implementation available at Lazysodium for Android. It has the same API as this library, so you can share code easily!

---

Created by Terl.

lazysodium-java's Issues

Implement AES256?

For feature completion implement AES 256, but is it absolutely necessary given what it does?

crypto_shorthash_siphashx24() cannot be found by Android

The native function crypto_shorthash_siphashx24() cannot be found in libsodium.so by Android. It can be found on Java though 😕

Perhaps there is an underlying function that is causing this error in Android. Will have to investigate further.

For now, I have removed the function in version 1.0.3.

Generic hashing is prone to errors

For some reason, when using functions such as cryptoGenericHashUpdate and cryptoGenericHashFinal the tests irregularly fail. I say irregularly because they fail 1/10 times on my local Mac environment and all the time on Linux (through SemaphoreCI).

Oddly, generic hashing works if I use key sizes KEYBYTES (which is equivalent to 32) upwards but fails for KEYBYTES_MIN.

Things I've tried:

• Changing the GenericHash.State to just byte[]. It used to be the case that Lazysodium was using a custom class to handle state, but after reading this issue, I changed all the generic hash stream functions to accept byte[] instead.
• A successful thing that I tried was changing cryptoGenericHashUpdate to go through less functions which fixed generic hashing on linux for key sizes KEYBYTES upwards.

Documentation plan

Many parts of the docs still need completing, such as the collaborator's guide and how to add native functions. I think the best plan of action is to centralise the documentation into one place.

Plan of action:

• Buy lazycode.co.
• Setup GitBooks.
• Transfer documentation.

Raspberry Pi and Lazysodium

@gurpreet- Thanks for the feedback. Very much appreciated.

I made an error in my original write-up. I was testing on an Ubuntu 16.04 box, not 18.04 as I said above. Sorry. And I think that explains why my apt-cache search libsodium is reporting libsodium18, which sounds like it's the issue. I assume if I test on a real 18.04 box, I'll not have a problem. Or if I test on a 16.04 box using the bundled libs, I also not have an issue. That's great and explains everything. Thanks!

Just to be clear about what I was doing... The only reason I was testing on Ubuntu with an OS-installed libsodium was because I was trying to test my logic that first tries a bundled libsodium, then falls back to an OS-installed libsodium. In my test code, I purposely caused the bundled libsodium to not be loaded. Under normal circumstances on Ubuntu, the bundled libsodium will be used and all will be good.

But, if I could shift gears for a second... I have a number of users who want to use my app on a Pi3. From what I can tell, the LazySodium jar doesn't include libs for that platform. Is that correct? Therefore, when they install libsodium using apt, they get libsodium18.

What's the solution in that use case? Should they compile libsodium for that platform? Or, would it be possible for you to include that lib in the LazySodium jar?

---

Originally posted by @mhilbush in #34 (comment)

Host this project

Host this project online on somewhere like Apache Maven Repository.

Lazier detached functions please

The "detached" variants return two items at a time.

For example, the function cryptoBoxDetached(cipher[], mac[], message[]...) populates a cipher[] and a mac[].

I suppose we could do something like:

cryptoBoxDetached(String cipher, String mac, String message...);
saveToDatabase(cipher);
saveToDatabase(mac);

But it's not clear what's happening, what's being manipulated and what you provide as initial values for cipher and mac.

Or we could do something like:

class Detached {
    byte[] cipher;
    byte[] mac;
}

Detached detached = cryptoBoxDetached(...);
detached.getCipher();
detached.getMac();

Which I believe is a lot better. Whichever one we choose, it will mean some breaking changes.

Incorrect value for TAG_MESSAGE (SecretStream)

SecretStream.java defines TAG_MESSAGE as:

lazysodium-java/src/main/java/com/goterl/lazycode/lazysodium/interfaces/SecretStream.java

Line 35 in 280481f

TAG_MESSAGE = XCHACHA20POLY1305_TAG_PUSH | XCHACHA20POLY1305_TAG_REKEY;

but that is clearly not the same as libsodium's definition (https://github.com/jedisct1/libsodium/blob/a161dd9fa10fb316ae27ca62d1da2cf0edd4c5c9/src/libsodium/include/sodium/crypto_secretstream_xchacha20poly1305.h#L37):

#define crypto_secretstream_xchacha20poly1305_TAG_MESSAGE 0x00

In fact, this is a serious bug, as TAG_MESSAGE has the same value as TAG_FINAL (whoops).

Is this just an oversight or is there a reason? In either case, these values should probably use the exported methods (crypto_secretstream_xchacha20poly1305_tag_message(), etc.)

Questions about implementation

This looks great, and I doubly agree that the other java implementations leave a lot to be desired.

I had a couple questions regarding secure memory that I didn't see addressed in the readme or faq. I don't see anything about secure memory - what were your thoughts regarding that and how you implemented this library? Any considerations regarding using Strings vs byte arrays? Availability of the secure lock and allocation functions?

I'm using native Java crypto + bouncycastle in my current project, but I keep on hitting requirements like this so I'll probably be back soon.

Lazysodium under windows

Stumbled across a similar error as in Issue #34:

Exception in thread "main" java.lang.UnsatisfiedLinkError: Unable to load library 'c:\temp\libsodium\libsodium.dll':

Native library (win32-x86-64/c:\temp\libsodium\libsodium.dll) not found in resource path (...)
at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:302)
at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:455)
at com.sun.jna.Native.register(Native.java:1716)
at com.goterl.lazycode.lazysodium.utils.NativeUtils.loadLibraryFromJar(NativeUtils.java:109)
at com.goterl.lazycode.lazysodium.SodiumJava.registerFromResources(SodiumJava.java:156)
at com.goterl.lazycode.lazysodium.SodiumJava.(SodiumJava.java:21)
at de.fhg.iwes.opsim.mcp.webserver.Activator.main(Activator.java:93)
Suppressed: java.lang.UnsatisfiedLinkError: Module not found.
at com.sun.jna.Native.open(Native Method)
at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:191)
... 6 more
Suppressed: java.lang.UnsatisfiedLinkError: Modul not found.

	at com.sun.jna.Native.open(Native Method)
	at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:204)
	... 6 more
Suppressed: java.io.IOException: Native library (win32-x86-64/c:\temp\libsodium\libsodium.dll) not found in resource path (...)
	at com.sun.jna.Native.extractFromResourcePath(Native.java:1089)
	at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:276)
	... 6 more

Windows:
Running Win 7 x64

java -version:
java version "1.8.0_181"
Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)

In Issue #34 is written something about dependency problems and updating your os seems to help with unix, But unfortunately not with windows. Also FAQ doesn't help. Maybe you could provide some insight on how to fix this on windows? Which libraries to install / is lazysodium compiled against, etc.

Thx!

Request for HMAC :)

My use case is generating authentication tokens so a user's password doesn't have to be remembered in as many places.

I think this can be worked around by hashing + then using crypto_auth, but it's more steps and I think ends up repeating some operations.

No urgent need because of workaround, but 👍 for this feature.

cryptoPwHashStrVerify sometimes has false negatives

Hello,

When using cryptoPwHashStrVerify argon2 hashing for my project, sometimes the password verification fails (sometimes a lot) despite the password being entered correctly.

Sample code (verifies a password that is "lol" when not hashed):

while (true) {
    byte[] hashedPassword = "$argon2id$v=19$m=65536,t=2,p=1$ZrWMVZiMs4tvs0QwVc7T7A$LIl6XlgIZsuozRpC3bCe5ew8LEWgDQvQE8qwsZ9ISps".getBytes(StandardCharsets.UTF_8);
    byte[] pass = "lol".getBytes(StandardCharsets.UTF_8);

    boolean success = pwHash.cryptoPwHashStrVerify(hashedPassword, pass, pass.length);

    if (!success) {
        System.out.println("Failure");
        break;
    } else {
        System.out.println("Success");
    }
}

Demonstration:

Please fix this. 😢

Implement SecretStream

The Libsodium SecretStream api needs implementing.

Help us, Patreon and Liberapay

Open-source isn't particularly well-funded.

Some of the most popular libraries often go unfunded and therefore are disbanded. I've created a Patreon page and a Liberapay page to make sure that Terl's present and future open-source projects remain well-maintained and open-source.

It'll help us to keep improving Lazysodium and hopefully branch out to more languages 🙌

Thanks!

Path error on Windows

Hi,
I tested on Windows but it failed to initialize. And below is what I found from the source code.
In Windows the path is like "\windows\libsodium.dll", so the check of path.startsWith("/") in NativeUtils will fail.

​Ed25519 to Curve25519

Hello, when is it planned to introduce support for converting Ed25519 to Curve25519?

lazysodium cryptoSignDetached returning incorrect sig

Implement Auth

Implement secret key Authentication.

Implement GenericHash

Integrate Generic hashing into Lazysodium.

Missing resource-loader dependency

Hi! In 4.1.0 release you added a dependency to com.github.libly:resource-loader:1.3.3, but it is not published on Maven Central. I see that you are a contributor of that library as well - could you please publish it?

Modifying crypto_sign to use blake2b internally

Tests fail if using non-nio methods

In commit e067072, SemaphoreCI tests fails if using standard Java methods to copy a file. This is where it causes a segfault, I think 😕

public static void copy(InputStream in, File dst) throws IOException {
      try (OutputStream out = new FileOutputStream(dst)) {
            // Transfer bytes from in to out
            byte[] buf = new byte[1024];
            int len;
            while ((len = in.read(buf)) > 0) {
                out.write(buf, 0, len);
            }
      }
}

I'm recording this issue here for posterity.

Lazysodium does NOT respect LD_LIBRARY_PATH

LD_LIBRARY_PATH points to all the native paths that the system should load. Lazysodium should also search the paths set by LD_LIBRARY_PATH so that it can load libsodium.so.

Implement Argon2 password hashing

Provide an implementation of the Argon2 password hashing scheme.

Additional Signing Key Support

Sometimes its useful to get a public key, given a Ed25519 private key (or to get the seed). Please add support for crypto_sign_ed25519_sk_to_pk and crypto_sign_ed25519_sk_to_seed.

Library loading concurrency issues

Library loading, which happens on lazysodium instantiation, has a couple of issues:

1. It always uses the same temporary directory, and clears it on instantiation and application exit. That leads to various concurrency issues when multiple processes use LazySodium. I bumped into LinkageError when ran several processes simultaneously, but I suspect a process crash is also possible with unlucky timing.
2. It is not thread safe. If multiple threads instantiate SodiumJava about the same time, the process will crash with segfault. Here is a test demonstrating that:

  @Test
  public void testConcurrentLoading() throws Exception {
    int numThreads = 32;
    List<Thread> threads = new ArrayList<>(numThreads);
    CyclicBarrier startBarrier = new CyclicBarrier(numThreads);
    for (int i = 0; i < numThreads; i++) {
      threads.add(new Thread(
          () -> {
            try {
              startBarrier.await();
              LazySodiumJava lazySodium = new LazySodiumJava(new SodiumJava());
              assertNotEquals(-1, lazySodium.sodiumInit());
            } catch (InterruptedException e) {
              // Just return
            } catch (BrokenBarrierException e) {
              e.printStackTrace();
            }
          }
      ));
    }

    threads.forEach(Thread::start);

    for (Thread t : threads) {
      try {
        t.join();
      } catch (InterruptedException e) {
        threads.forEach(Thread::interrupt);
        throw e;
      }
    }
  }

3. If app instantiates SodiumJava several times with the default constructor, it will copy libsodium.so as many times to the temp directory as invoked.

I've locally resolved the first issue and will submit the PR soon. I suggest to resolve the other too in the same PR, as they are closely related, WDYT?

Implement AEAD

Implement the whole set of AEAD constructions.

3.6.1 requires JNA classes in public APIs

Hi,

3.6.1 changed the method parameter of some public APIs from long to NativeLong from JNA library (e.g., cryptoSignDetached). However, JNA types are not accessible because it has runtime scope in the generated pom.xml. Shan't its scope be changed to compile so that the lazysodium clients don't have to add a dependency on JNA to use lazysodium APIs?

See also exonum/exonum-java-binding@5e7356d

windows

crypto_box_open_detached interface wrong

In LazySodium,
public boolean cryptoBoxOpenDetached(byte[] message, byte[] cipherText, byte[] mac, byte[] cipherTextLen, byte[] nonce, byte[] publicKey, byte[] secretKey)
seems to be wrong with defining
byte[] cipherTextLen instead of long.
This goes all the way down in the interface, and eventually ends with a crash as byte[] in java is passed by reference, so converting a long to a byte[4] will not work.

Maven usage

Bintray is nonstandard and I found it fairly difficult to use compared to standard (maven central) releases where all I need is a dependency. I had these issues:

1. Just adding a dependency doesn't work, you need to define a new maven repository.
2. The bintray "set me up" button says you need a settings.xml and need to create a profile, add repositories and pluginRepositories to it. You don't - all you need is the repositories section and you can add it directly to pom.xml.
3. The dependency mustn't have <type>pom</type> - the dependency won't resolve if it's present.

TBH it might not have been difficult if the repository config was documented next to the dependency config.

Implement CryptoBox Seal and Sign

Implement public key signing.

Running v 4.10 lib search path wrong (?)

Might be my misunderstanding...
Upgraded from 4.01 to 4.10.

With 4.0.1 the jar will find and load the libsodion.so.

With 4.1.0 is does not. It looks like it looks for it in /lazysodium-java-4.1.0.jar/linux-x86-64/..., but there are only /lazysodium-java-4.1.0.jar/linux64 & /lazysodium-java-4.1.0.jar/linux.

"libsodium.so: cannot open shared object file: No such file or directory
Native library (linux-x86-64/libsodium.so) not found in resource path"

4.0,1 & 4.1.0 tried on the same server with the exact same setting, so i suspect it is some setting in the jar.

-Yishai

Implement KeyExchange

Implement the Key Exchange functions.

Missing functions

95% of native functions have been added and are now accessible via LazySodium.java and Sodium.java. However, work still needs to be done in completing Lazysodium's API, which means documentation and more functions need to be added.

Here's a short summary of what's done and what needs doing:

• AEAD: lazy AND native functions needed.
• Auth.
• Box: A few functions left.
• GenericHash.
• KeyDerivation.
• KeyExchange: Documentation needed.
• Padding: possibly unneeded as the native API works on a low-level anyway.
• PwHash.
• Random.
• SecretBox: Need lazy detached variants.
• SecretStream: Lazy functions and documentation.
• ShortHash.
• Sign: Needs a little more documentation.

Let's get it done 💯 👍

java.lang.UnsatisfiedLinkError: Unable to load library 'C:\Users\ADMINI~1\AppData\Local\Temp\nativeutils14683980698824\libsodium.dll

Can you help me about this?
how do for this?

Incompatible with Older Android Devices

When used with lazysodium-android, this library is only compatible with API 26+ devices (Android Oreo), due to usage of the Paths, StandardCharsets and other classes that were only recently added. Additionally, the try-with-resources pattern is not available prior to API 19.

A few small updates will make this library compatible back to Jelly Bean (API 16) and possibly even older devices.

Add initial documentation

Improve the documentation by adding build and distribution sections.

Add CryptoBox functions

We need to implement secret key crypto functions.

Unable to load library

hi, I have a problem.
Can anyone help?
win10 64-bit
java.lang.UnsatisfiedLinkError: Unable to load library 'C:\Users\yfhua\AppData\Local\Temp\libsodium\libsodium.dll': Native library (win32-x86-64/C:\Users\yfhua\AppData\Local\Temp\libsodium\libsodium.dll) not found in resource path ([file:/D:/workspace/lazysodium-java/bin/, file:/C:/Users/yfhua/.p2/pool/plugins/org.junit_4.12.0.v201504281640/junit.jar, file:/C:/Users/yfhua/.p2/pool/plugins/org.hamcrest.core_1.3.0.v201303031735.jar, file:/D:/workspace/lazysodium-java/gradle/wrapper/gradle-wrapper.jar, file:/D:/workspace/lazysodium-java/lib/jna-4.5.1.jar, file:/D:/Program%20Files/eclipse/configuration/org.eclipse.osgi/383/0/.cp/, file:/D:/Program%20Files/eclipse/configuration/org.eclipse.osgi/382/0/.cp/])
at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:303)
at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:427)
at com.sun.jna.Native.register(Native.java:1647)
at com.goterl.lazycode.lazysodium.utils.NativeUtils.loadLibraryFromJar(NativeUtils.java:109)
at com.goterl.lazycode.lazysodium.SodiumJava.registerFromResources(SodiumJava.java:156)
at com.goterl.lazycode.lazysodium.SodiumJava.(SodiumJava.java:21)
at lazy.BaseTest.(BaseTest.java:19)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at org.junit.runners.BlockJUnit4ClassRunner.createTest(BlockJUnit4ClassRunner.java:217)
at org.junit.runners.BlockJUnit4ClassRunner$1.runReflectiveCall(BlockJUnit4ClassRunner.java:266)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.BlockJUnit4ClassRunner.methodBlock(BlockJUnit4ClassRunner.java:263)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)

Support configuring which library gets priority

Overview

Currently lazysodium can be instantiated either:

• with a bundled library from its JAR: new SodiumJava(),
• or with a system (installed) one: new SodiumJava("sodium"),
• or a custom one: new SodiumJava("/home/john.doe/app/libsodium.so").

For applications which are deployed in a known environment that is perfectly enough. However, if lazysodium is used in a library, or an application that is likely to be deployed in a wide range of environments (uncontrolled by the dev), it might be needed to get the following behaviour:

1. Prefer system library, fall-back to bundled. That allows the app/lib to benefit from updates to system sodium (e.g., security fixes) without the need to wait for lazysodium release, update and release their app/lib.
2. System-only mode. That might be useful if using the system sodium is a requirement.
   It is currently achievable with new SodiumJava("sodium").
3. Bundled-only mode. Might be useful if some incompatibilities are discovered with the system version and it is not possible to upgrade it. It is currently achievable with new SodiumJava().

Workaround

Option 1 (prefer system library) can currently be achieved with the following client code:

    SodiumJava sodium;
    try {
        // Try to use the system one, using its name
        sodium = new SodiumJava("sodium");
    } catch (UnsatisfiedLinkError e) {
        // Use the bundled library 
        sodium = new SodiumJava();
    }

Whilst it works, it is not intuitive to write, especially for new users.

Questions

1. Shall lazysodium support such functionality, or leave it to the users?
2. Shall it support all three options through a single interface for easy of use and discoverability (e.g., SodiumJava(LibraryLoadingMode))?
3. What shall be the default mode for SodiumJava() — bundled or prefer-system? First is guaranteed to work, but second is more likely to receive timely updates.

NoSuchMethodError after upgrading to 3.6.0

After upgrading from 3.5.1 to 3.6.0, I get a java.lang.NoSuchMethodError when calling sodium.cryptoSignDetached(sig, sigLen, m, (long)m.length, sk).

Is it possible that there is that there is a mismatch in with the function signatures because of the NativeLong or long attributes?

Note that I am using Clojure, but I do not think it has a direct impact.

Make sure that the libsodium shared library can be used by more than 1 process

The problem is that if 2 processes are using Lazysodium, one of them will fail because not more than one process can access the shared library.

Caused by: java.io.FileNotFoundException: C:\Users\mark\AppData\Local\Temp\lazysodium\libsodium.dll (The process cannot access the file because it is being used by another process)
	at java.io.FileOutputStream.open0(Native Method)
	at java.io.FileOutputStream.open(FileOutputStream.java:270)
	at java.io.FileOutputStream.<init>(FileOutputStream.java:213)
	at com.goterl.lazycode.lazysodium.utils.LibraryLoader.copyFromJarToTemp(LibraryLoader.java:244)
	at com.goterl.lazycode.lazysodium.utils.LibraryLoader.loadBundledLibrary(LibraryLoader.java:155)

I have recently changed lazysodium to load from the lazysodium folder that is not unique - this is highly likely where the error comes from. There are two ways we can solve this:

1. If we can copy the Lazysodium shared library into a special unique temp folder, then this bug will be resolved.
2. If we can make the Java loading code atomic across processes, this bug can be resolved.

BLAKE2b-256

hashPrevouts：
BLAKE2b-256（'ZcashPrevoutHash'，b''）
= d53a633bbecf82fe9e9484d8a0e727c73bb9e68c96e72dec30144f6a84afa136
How to write this project, thank you @gurpreet-

Implement ShortHash

Also known as Short input hashing.

Trouble installing the lazysodium library in maven

Hi, I am getting the Could not find artifact co.libly:resource-loader:pom:1.3.5 in lazysodium-java (https://dl.bintray.com/terl/lazysodium-maven) error when compiling the pom.xml

Here is my maven pom.xml following the instruction from https://docs.lazycode.co/lazysodium/usage/installation

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>xx</groupId>
    <artifactId>testlazysodium</artifactId>
    <version>1.0-SNAPSHOT</version>

    <repositories>
        <repository>
            <id>lazysodium-java</id>
            <url>https://dl.bintray.com/terl/lazysodium-maven</url>
        </repository>
    </repositories>

    <dependencies>
        <dependency>
            <groupId>com.goterl.lazycode</groupId>
            <artifactId>lazysodium-java</artifactId>
            <version>4.2.3</version>
        </dependency>

        <dependency>
            <groupId>net.java.dev.jna</groupId>
            <artifactId>jna</artifactId>
            <version>5.5.0</version>
        </dependency>
    </dependencies>


</project>

I also tried to install library using the gradle instruction; gradle works fine. Must be a maven problem then.

cryptoBoxEasyAfterNm pointer problem

Hi,

When i run:

    fun encrypt(secretKey: Key, nonce: ByteArray, message: ByteArray): ByteArray {
        var cipherText = ByteArray(message.size)

        sodium.cryptoBoxEasyAfterNm(cipherText, message, message.size.toLong(), nonce, secretKey.asBytes)

        return cipherText
    }

I get:

munmap_chunk(): invalid pointer

Is it me or it's a bug ? What can I do ?

Sorry for my basic English

Error using the new Detached Signature mode

I saw you added Lazy Detached Signing in 1.1.4 but unfortunately when I try to use this, I get this error:

libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)

Either when using my own compiled *.so or the default provided ones. I'll take a look at the implementation for Lazy detached signing to see if I can find anything.

Expose buffer sizes for native interfaces

Hey there! LazySodium looks like it's shaping up to be probably the best Libsodium Java binding library, but it doesn't expose libsodium's pre-calculated authenticated encryption interface properly.

In particular, in the Box interface, the value of BEFORENMBYTES etc is not publicly accessible. The code I'm writing needs to fill a shared secret k using the LazySodium.cryptoBoxEasyBeforeNm() method, but I had to dig around to figure out that the buffer size should be 32 bytes long.

I'm doing something like

        byte[] sharedSecret = new byte[32];
        if (!sodium.cryptoBoxBeforeNm(sharedSecret, bobsPubKey, alicesSecKey)) {
            return false;
        };

But it would be much more clear if I could do something like:

        byte[] sharedSecret = new byte[LazySodium.BEFORENMBYTES];

Could this buffer size (and others) be exposed publicly?

Consider a more politically correct - enterprise friendly name for the library

Hi,

I currently work as freelancer for a communication company and I am looking for open source libraries to implement AEAD for an IOT project.

Technically your work is very interesting for my Java team but I am embarrassed by the name of the project which sounds non professionnal. Sorry if this sounds killjoy but my understanding is that your dedicated work deserve real feedback.

Regards,
CMH