Use high-level constructs designed and peer-reviewed by cryptographers who know what they're doing.
Basically: use libsodium.
One implementation docs says:
"I'm experiencing some issues on Windows. Do you have any idea?
I'm sorry but I'm completely clueless about Windows environment, but if you have any suggestions or PR changes. They will be more than welcome."
Can I trust them? How do I know there are no some Windows-specific issues in this implementation?
Another library listed on this page does not have a single release? Could it be trusted?
Next has been abandoned and moved into Apache Foundation incubator. Good but will it be maintained? Maybe use this, or maybe Lazysodium, which has a nice Github page?
If I am to verify if any of those ports is a proper one probably I would have to really become a crypto expert.
Isn't it safer to learn and understand how to use, say, AES algorithm as it is provided as a part of Java? There is a few important config choices, but still it looks easier than analyzing someone's libsodium port?
AES by itself is just a function that provides symmetric encryption of one fixed size block. You can't do anything with "just AES". Bad libraries will throw a choice of block cipher modes at you, and tell you to pick CBC or CTR. Then you won't even realize that you have no integrity checking at all on these messages. If you do, you'll maybe add an HMAC, and end up with encrypt-then-MAC or MAC-then-encrypt and ughhhh.
Just use a high level library that provides idiot-proof APIs with descriptive names like "secret box".
> If I am to verify if any of those ports is a proper one probably I would have to really become a crypto expert.
These things aren't ports!!! They're simple FFI bindings. Take a quick look at the code (heck, the readmes say things like "Java Native Access" already, this should ring a bell).
As for the maintenance, it hardly needs any. Should I get hit by a bus tomorrow, you'd still have something useable today. If you want client server security, I'm currently working on Noise like protocols, and should add that during the summer. After that, my library should be mostly frozen.
Now there is this thing where you might not trust yourself enough to decide whether you should trust me…
crypto_box_easy(ciphertext, MESSAGE, MESSAGE_LEN, nonce, bob_publickey, alice_secretkey)
Even if there was some choice, it would've been a choice between known good options, no footguns.