Several code and cryptographic quality issues

1. You should never, ever have a default key, a default key is as good as no key, if no secret is given, an error should be thrown.
2. !secret is not the correct way to check whether the secret variable is undefined or not, neither is algorithm || 'aes256'. If you want to check whether the argument was passed or not, you should do secret == null.
3. You should make sure secret is either a string or a buffer.
4. The encrypt and decrypt functions will throw a TypeError if passed null or undefined as any attempt to access their properties results in one. This is potentially correct behaviour, but should be documented, and the error should potentially be caught and a more descriptive error thrown.
5. The default cipher is aes256, which OpenSSL aliases to AES-256-CBC, CBC mode is a bad idea, a more sane default cipher would be AES-256-CTR, as it should be supported everywhere, and does not suffer the same issues as CBC mode. Additionally, NaCl, often considered one of the most secure cryptographic libraries available, uses CTR mode for their unauthenticated secret-key encryption, authenticated encryption would be a better choice, but GCM is unsupported in Node as it requires more arguments than other modes.

[joepie91]

@KoryNunn Existence checking and type checking are two separate checks (and the algorithm checking code remains wrong in your PR). I don’t see how a unit test would be relevant here - I’ve already pointed out the problem quite clearly.

If you consider it appropriate to demand practical proof of a theoretically provable problem, you really should not be writing crypto code. Any crypto-related code that is any less than 100% perfect is to be considered broken and needs-fixing, because of how hard it is to get crypto right.

Seriously, just don’t write/publish crypto code if you’re not willing to fulfill the associated effort required. Just point people at an established implementation, preferably libsodium/NaCL.

[KoryNunn]

@MauriceButler and myself are well aware of how JavaScript works.

Checking that algorithm is not null or undefined will not help users that pass other non-string values.

Given that the code in the PR is functional correct, this is now a discussion on style.

If you do not think the code is functionally correct, you can show this via a unit test.