3 ms·

I really would like to use libsodium, but I use Java. Looking at https://libsodium.gitbook.io/doc/bindings_for_other_languages https://libsodium.gitbook.io/doc/

I really would like to use libsodium, but I use Java. Looking at https://libsodium.gitbook.io/doc/bindings_for_other_languages https://libsodium.gitbook.io/doc/bindings_for_other_language... it seems that there are 5 different ports. The question which one is save to use? 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?

floatboth 7y ago
> Isn't it safer to learn and understand how to use, say, AES algorithm No. 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).
djsumdog 7y ago
Honestly on Java, I would stick to Bouncy Castle. It's tried and tested, has regular releases, good documentation and is regularly maintained.
- floatboth 7y ago
  It's not equivalent in any way. Bouncy Castle is a kitchen sink library that provides everything except for a high-level, modern construction based, idiot proof secret_box/crypto_box/crypto_sign API.
loup-vaillant 7y ago
If you have portability issues, I happen to have written a crypto library¹ in portable C99/C++. It has been tested on a stupidly wide range of platforms, and is simple enough that you could bind to the higher-level constructions yourself. Platform specific issues are pretty much impossible. Oh, and it's just 2 files (one header, one source file), pretty easy to just paste them into your own project. 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… 1: https://monocypher.org/ https://monocypher.org/

floatboth 7y ago

> Isn't it safer to learn and understand how to use, say, AES algorithm No. 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).

djsumdog 7y ago

Honestly on Java, I would stick to Bouncy Castle. It's tried and tested, has regular releases, good documentation and is regularly maintained.

floatboth 7y ago
It's not equivalent in any way. Bouncy Castle is a kitchen sink library that provides everything except for a high-level, modern construction based, idiot proof secret_box/crypto_box/crypto_sign API.

loup-vaillant 7y ago

If you have portability issues, I happen to have written a crypto library¹ in portable C99/C++. It has been tested on a stupidly wide range of platforms, and is simple enough that you could bind to the higher-level constructions yourself. Platform specific issues are pretty much impossible. Oh, and it's just 2 files (one header, one source file), pretty easy to just paste them into your own project. 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… 1: https://monocypher.org/ https://monocypher.org/