src/libsodium/include/sodium/crypto_generichash_blake2b.h, line 46:

#define crypto_generichash_blake2b_BYTES         32U

org.abstractj.kalium/NaCl line #80:

 public static final int BLAKE2B_OUTBYTES = 64;

Is that intentional?

sodium_init is responsible for access to /dev/urandom. However, Random.java appears to work fine and have tests... I'm not sure what sodium does if you forget to call sodium_init; it may lazily open urandom, which is usually fine except when it's not (chroots come to mind).

I started off with the goal of adding all of the currently documented Libsodium interfaces to Kalium. I may have gotten a bit carried away cleaning up code though. Anyway this is my progress so far, no need to merge yet.

Goals

• Add all of the documented libsodium interfaces
• Provide OO style interfaces
• Review other OO style bindings to libsodium to see if we can make Kalium's bindings better
• Take a crack at #41
• Keep backwards compatibility to Kalium 0.4.0

Just added a maven dependency to Kalium to my project

<dependency>
			<groupId>org.abstractj.kalium</groupId>
			<artifactId>kalium</artifactId>
			<version>0.6.0</version>
		</dependency>

Attempting to use the framework, I'm running into the following exception:

java.lang.NoClassDefFoundError: jnr/ffi/Platform$OS
	at org.abstractj.kalium.NaCl$1.<clinit>(NaCl.java:37) ~[kalium-0.6.0.jar:na]
	at org.abstractj.kalium.NaCl.libraryName(NaCl.java:37) ~[kalium-0.6.0.jar:na]
	at org.abstractj.kalium.NaCl.<clinit>(NaCl.java:34) ~[kalium-0.6.0.jar:na]
	at org.abstractj.kalium.crypto.Password.verify(Password.java:35) ~[kalium-0.6.0.jar:na]

Do I have to bundle any DLL of sodium with my application? I was hoping you would package that for me with the Kalium jar file.

Cheers, Florian

I recently ran into the issue described in #65. I see that it is marked as revolved and merged. Do you have an ETA for a release of kalium with this change? Or should I post a PR with doc changes suggesting how to work around this?

If the encryption / decryption fails on SecretBox, then Util.isValid is called -- this throws RuntimeException.

https://github.com/abstractj/kalium/blob/master/src/main/java/org/abstractj/kalium/crypto/Util.java#L46

Because RuntimeException is so general, if I want to catch this specific exception I have to check the message:

https://github.com/wsargent/play-kalium/blob/master/app/controllers/HomeController.scala#L25

This is not good -- there should be a specific EncryptionFailedException that extends from RuntimeException that can be checked individually.

This adds equals, compare, and isZero operations to Util.java that are comparable to sodium/util.h versions.

Running these functions in Java is much faster than going though to the overhead to the native libsodium implementations.

• memcmp -> https://github.com/jedisct1/libsodium/blob/1.0.8/src/libsodium/sodium/utils.c#L98-L117
• compare -> https://github.com/jedisct1/libsodium/blob/1.0.8/src/libsodium/sodium/utils.c#L132-L155
• is_zero -> https://github.com/jedisct1/libsodium/blob/1.0.8/src/libsodium/sodium/utils.c#L158-L167

I cannot use kalium at all:

java.lang.IncompatibleClassChangeError: Found interface org.objectweb.asm.ClassVisitor, but class was expected
    at jnr.ffi.provider.jffi.AsmLibraryLoader.generateInterfaceImpl(AsmLibraryLoader.java:74)
    at jnr.ffi.provider.jffi.AsmLibraryLoader.loadLibrary(AsmLibraryLoader.java:59)
    at jnr.ffi.provider.jffi.NativeLibraryLoader.loadLibrary(NativeLibraryLoader.java:43)
    at jnr.ffi.LibraryLoader.load(LibraryLoader.java:265)
    at jnr.ffi.LibraryLoader.load(LibraryLoader.java:244)
    at org.abstractj.kalium.NaCl$SingletonHolder.<clinit>(NaCl.java:41)
    at org.abstractj.kalium.NaCl.sodium(NaCl.java:28)
[...]

Fix: If a new KeyPair was created based on an existing PrivateKey the publicKey-field stayed null forever. Each time .getPublicKey() was called the PublicKey was recalculated.

Moved this code in the constructor where it belongs to.

Hi! I downloaded latest release of libsodium (https://download.libsodium.org/libsodium/releases/libsodium-1.0.11-msvc.zip), extracted appropriate libsodium.dll, set up java.library.path property... but jnr-ffi failed to load sodium library (throws LinkageError). If I rename libsodium.dll to sodium.dll it works fine. Is it correct behaviour on Windows platform?

OS: Windows 7 SP1 x86 Kalium 0.5.0

See https://github.com/ysangkok/NaclTest/blob/master/src/main/java/com/mycompany/nacltest/NaclTest.java

If I change the public key parameter to null (public key shouldn't be needed for decryption, right?), the JVM crashes.

Even if a public key is needed, it should not segfault, it could throw an exception.

Why are annotations such as @Nullable not used?

Thanks for you efforts however, the library is useful.

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

It would be very convenient to have more control on the paths (and order) queried for loading native libraries (apart from the std three currently taken into account); prepending the paths from LD_LIBRARY_PATH evn var would be a very welcome addition and common linux behavior.

The underlying jnr-ffi lib does allow to append some extra paths, but unfortunately those did not help us out (ref https://github.com/jnr/jnr-ffi/issues/129). They were only appended to the std search paths.

Added an annotation to the sodium_version_string() method so it is always read as an ASCII string. Avoids some issues on Windows with reading multi-byte strings by default.

Added a test to make sure version string matches the expected pattern.

For issue #87.

Kalium with libsodium 1.0.15 & 1.0.16 is broken, due to incorrect string handling in jnr-ffi.

• libsodium stores the version string in 1.0.15 as 1.0.15\0\0xsalsa20.... (https://github.com/jedisct1/libsodium/issues/665)
• jnr-ffi does not correctly read NULL-terminated static strings from binaries - its look for a double null (\0\0\0\0). (https://github.com/jnr/jnr-ffi/issues/108)

As a result, sodium_lib_version returns "1.0.15\0\0xsalsa20", and checkVersion fails because it tries to convert 15\0\0xsalsa20 to an integer.

Short of fixing jnr-ffi, Kalium could update its regex when parsing the input string to avoid this bug.