Nobody implements GCM themselves; they get it from a library. CBC, implemented the way you're describing, is almost always insecure.
I too loved playing with crypto - read a ton of books, attended some crypto classes in University, implemented some crypto systems which I thought were secure, etc. - but nowadays I wouldn't dare use anything that isn't considered secure by a large audience unless I had extremely good reason to do so.
So now what?
https://cryptojs.gitbook.io/docs/
Because CBC mode is easier to implement, you'll find it in far more libraries. And honestly, if your underlying block-cipher is secure (that's the hard part: where your side-channels all exist), then CBC mode is really the easy part and can be safely implemented yourself. It really is that simple.
-----------------
CBC doesn't have authentication. So add on an HMAC. Done. It takes up a few more bytes but that's not a big deal these days.
If you are serving out an encrypted HTML page insecurely, your users are already hosed, because someone on the path could inject a script that sends the password to evil[.]com when they type it in.
Literally one of the most common things to fuck up when doing crypto yourself.
The things you are describing are difficult and dangerous for developers to build.
HTML uses some Javascript to encrypt a file. Then later, the Javascript decrypts the file and returns it to normal.
This is a "beginner level" cryptography situation. Yes, I know there's all sorts of traps all around the field of cryptography. But I also know that this particular use case is simple enough that beginners can try their hand at it, and probably make something useful. And with low-probability of a critical error.
-------------
Don't write your own AES-GCM implementation. Don't write your own TLS1.2 implementation. Etc. etc. There's all kinds of subtle errors involved. IVs, Padding, side-channels, man-in-the-middle... more than I can count and very subtle to think about.
The fact that this subthread has gone down a rabbit-hole of hypotheticals that are _COMPLETELY IRRELEVANT_ to the use-case discussed in this github is proof enough. The community is a bit rabid over its "advice" on this subject.
I see what you’re saying, but the fact is that these hypotheticals are not irrelevant. They’re important intricacies and potential trip mines associated with implementing your own encryption.
In any case, I think reimplementing CBC is absolutely beginner level as far as implementation is concerned. Yes, you can be tripped up by various _uses_ of CBC, but the failure modes are extremely well studied at this point.
Of course, a proper AEAD implementation would avoid that. But AEAD is commonly established today with GCM, which is not beginner level. So now we're trapped. What am I supposed to tell a young programmer who is interested in playing around with encryption on their own?
Perhaps you wish to stop anyone from studying that subject. But on the contrary, I think the only way a programmer can truly learn this stuff is to implement the easiest stuff and try it out themselves from the ground up.
--------
The _proper_ advice, is... don't write your own production encryption. But... if you have to, stick with the simplest implementation that avoids the most common errors (side channels, timing attacks, etc. etc.), and focus on the simplest use cases that have the largest amount of history.
Of course, there's an entire class of crypto-bugs these days are found at the higher levels, in the "use of encryption" (ex: SSL3.0, TLS1.0, TLS1.1, etc. etc.). Nonce reuse, IV generation, in-advertent side channels due to padding oracles, etc. etc.
Even a "perfect" implementation of CBC will come across these crypto-bugs (and is why modern algorithms do focus on AEAD from the ground up these days, which largely avoids the problem).
So yes, there are a lot of traps and footguns in the world of encryption. But that's true of programming in general. Eventually, someone will want to make their own encryption, maybe the library doesn't work out just right (as is in this case: the Crypto-library doesn't have GCM mode implemented), and other modes need to be used. The use of CBC seems to be done properly here for static-HTML encryption.
Tell them to stop if they’re trying to do it for anything real, or do it as a toy protect that never sees the light of day. And if they select the latter, then they may as well try GCM.
Tell them to leave encryption writing to the professionals.
We're well deep into a "professional" discussion about the pros and cons of particular implementation details of cryptography.
------------
Go back to the top. Look at the Github code. See that it uses a crypto-library. What should have the original writer have done differently?
The answer is absolutely not "write their own implementation of GCM". They chose correctly: using a well known, well supported CBC mode of operation with AES. (And IMO, _IF_ CBC mode were unsupported, the correct move would have been to write CBC themselves, as it is far less complex than GCM, which includes GHASH and other such side-channel issues).
There's context to everything. From my understanding of this current situation, the CBC choice was perfectly valid.