News for hackers. Stuff that matters.
Re:Stanford JavaScript Crypto Library by arvinsim on Monday June 15, 2020 @09:32PM (#23535053)
Hmm I am currently testing out node-forge for encrypting/decrypting AES-256.

Would you say that libsodium.js is better?

Re:Stanford JavaScript Crypto Library by technion on Monday June 15, 2020 @09:55PM (#23535190)
I haven't used this, so I went and read the documentation.

node-forge is a good example of giving a user too many options in my view. As a developer looking to secure something, you've apparently decided on AES-256 against options like "DES" and "RC2" that are on offer. That's a good step.

Now you get to choose between ECB, CBC, CFB, OFB, CTR. Which is a good idea? Which isn't? The documentation appears to just say "here is a great example of using CBC mode". That example is vulnerable to a padding oracle (uses PKCS#7 and has no form of MAC). From what I'm reading it's left as an exercise to the reader to record the iv somewhere. If you did want a hash, it helpfully suggests MD5 as reasonable.

This isn't a great example of crypto engineering.

Re:Stanford JavaScript Crypto Library by buu700 on Monday June 15, 2020 @09:51PM (#23535165)
I would go with libsodium.js (which binds to the native C library in Node.js) if you just need to encrypt/decrypt in general, especially if you anticipate building out other cryptographic features in the future.

If you need AES in particular, node-forge is probably fine, although from a quick glance it looks almost identical to Node's built-in crypto API, in which case you could just use that, but they both look pretty inconvenient (excessively low-level) to use directly.