Hacker News new | past | comments | ask | show | jobs | submit login

Yes. Stop entirely. Developers in fact MUST NOT use ANY crypto primitives directly. "If you're typing the letters A-E-S into your code, you're doing it wrong." You WILL do something subtly (or not so subtly) wrong and it won't be secure.

Use high-level constructs designed and peer-reviewed by cryptographers who know what they're doing.

Basically: use libsodium.

I really would like to use libsodium, but I use Java. Looking at 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?

> Isn't it safer to learn and understand how to use, say, AES algorithm


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).

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/

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

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.

Should we not be using bcrypt anymore?

bcrypt is a password hashing algorithm. It's totally fine, but newer better ones exist (scrypt and now Argon2). libsodium provides them.

With libsodium you still have to choose parameters though not that different from other crypto libraries(including .NET)

What parameters do you have to choose? Apart from nonce, which is confusing for most people who don't read documentation, and computational params for password hashing (unavoidable), there's no parameters to choose from (no curves, no hash functions, cipher modes, etc.)

    crypto_box_easy(ciphertext, MESSAGE, MESSAGE_LEN, nonce, bob_publickey, alice_secretkey)
Where do you see a place for parameters?

Even if there was some choice, it would've been a choice between known good options, no footguns.

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact