Deprecate library and reccomend standardized APIs

[jonkoops]

Since the Web Crypto API is now widely supported both on the Web and Node.js this library serves little to no purpose in modern JavaScript development. This library is also very clearly no longer actively maintained.

Given these arguments I would like to propose this library be deprecated as follows:

• Add a section to the README instructing users to use the Web Crypto API instead.
• Deprecate all versions of the NPM package using npm deprecate.
• Archive the repository on Github.

[jonkoops]

ping @emn178

[phtdacosta]

I may disagree with you when it comes to "serves little to no purpose". WebCryptoAPI requires HTTPS to work wheareas @emn178's library does work in both HTTP and HTTPS. It IS really handy.

[jonkoops]

Realistically, in what scenario would you deploy an application without HTTPS?

[phtdacosta]

That's half the catch!

1. For testing, in local environments, it is useful as a "decoy" while you do not put it for production over the www
2. In very resource-constrained environments where you need to be precise as a needle, (IOT for example) you may only need specific libraries to work with and having HTTPS may be complete overkilll or even an actual "threadlock" to deal with
3. This one is much less common but when dealing with legacy systems one also may need to use some "silver tape" solution like this

From my personal experience, those are the only three specific scenarios where this library is still greatly useful to work with.

[jonkoops]

1. In this case localhost is considered a secure domain, so the Crypto API will work. If someone is testing with a custom domain locally they could use a self-signed certificate or whitelist their domain.
2. I guess it could be the case that some IoT devices are not on a secure connection, but I sincerely doubt that running an HTTPS connection is that resource constrained.
3. Legacy solutions use legacy code, nobody is stopping folks from running old code (including this lib).

[f478ccf2]

The Web Crypto API for hashing is not very good, there might be some cases for when this library might be needed, those cases being any other case than hashing an entire chunk of text at a time.

[jonkoops]

The Web Crypto API for hashing is not very good

Could you elaborate on this a little? I'd be curious if there is a specific example to this.

[f478ccf2]

There's no way to hash data in chunks (i.e create a hash object and update data). If this functionality was added I would definitely stop using this library (or any other SHA library), but for now it does have a use.

[dimhatz]

The Web Crypto API for hashing is not very good

Also, SubtleCrypto API is async-only. This library is useful where async is not allowed / not feasible, e.g. within an IndexedDB transaction (the transaction will automatically expire before the async microtask is finished and it's not always possible to pre-calculate all the required checksums beforehand).

[timofei-iatsenko]

+1 for non-async usage. Example i want to make a universal function which would work in node and browser. I might use standard WebCrypro api, but it's async only, and my use case is synchronous (generating ids inside babel transformation).

[f478ccf2]

Well, if you are going for speed and can fit the entire file into memory, SubtleCrypto may be faster. It uses (BoringSSL/OpenSSL/whatever crypto library your browser uses)'s crypto functions under the hood (AFAIK), which may use CPU intrinsics as available to speed up the computation. On my laptop with an 11th-gen Intel i3, I can hash a 500MB Uint8Array in 723ms.

But for small use cases where synchronous hashing is required, this library is nice.

[jonkoops]

Closing this, as there obviously seems to be a common use-case for a synchronous API.