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

So what is it? Just stop using RSA completely or stop rolling your own RSA? The article sends mixed signals on this, I completely understand the latter as bad but I have used the RSA framework within .NET to sign messages before and I don't recall it being hard at all.

I think the argument is to stop using it.

The problem with RSA is that it's easy to understand and easy to implement well enough to work in the sense of "my test cases verify and reject my good and bad signatures", but extremely hard to implement correctly with respect to a host of subtle number theoretic attacks against prime generation, key selection, and bit banging that have been successful in the wild over the past few decades. Given the number of attacks that have been found and their subtlety, it seems likely that there may be additional holes yet to be found in any given implementation.

There are other options that may be harder to understand and implement, but the trade off is that if you get them to work at all, you have probably done it safely (or more likely used a library written by a cryptographer that did it correctly) - Digital Signature Algorithm (DSA) for signing and Elliptic Curve DSA (ECDSA) and Elliptic Curve Diffie-Helman (ECDH) for key agreement which allows for encryption (via a symmetric method).

The conclusion is to stop using RSA entirely. The article argues that RSA parameters are so easy to screw up, even if you're not implementing the algorithm yourself, you're probably introducing security vulnerabilities by choosing parameters that leave you open to vulnerabilities that you've never heard of which will allow attackers to retrieve secret keys. Instead, you should use ECDSA with curve 25519. If you use that algorithm (obviously not rolling it yourself, but using a well-tested open-source implementation), you're much less likely to introduce vulnerabilities accidentally through bad parameter choices.

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