221–230 of 294 posts
I'm going to plug my project PageCrypt here too, which predates StatiCrypt, has a web UI that's good for one-off page encryption, and does use the WebCrypto API. https://github.com/MaxLaumeister/pagecrypt https://www.maxlaumeister.com/pagecrypt/
I'll echo the other sentiments here that I wouldn't consider this "static HTML", and I was expecting something about .htaccess. That said, this seems to be a strengthening of what used to be somewhat common "protection", namely variations consisting of: - Password in plaintext in the source e.g. "if(password=='hunter2') ..." - No correlation between password and page contents (either the content is merely hidden and…
why not? this could be served on a server which does not have any dynamic execution capabilities, and does not require the server to handle any other request other than just the HTML.
Earlier quoted context omitted.
The more general solution is to use a password-protected archive.
But then it's not self contained and every time you want to access the archive you also need a program that can decrypt/encrypt that format. Using a self-contained HTML file means it's currently the most portable way to encrypt something and have it available anywhere you can get the file on. By the way, I don't advocate for this idea. But still, I find it a pretty ingenious way to store encrypted data portably. Esse…
that's just a self-extracting archive, which is a very common idea and easily created as well (very popular with both shareware distribution).
The problem is that you have to trust the extracting code to not install anything else malicious. The browser provides the perfect sandbox - you cannot install malware into the system via javascript in the browser, and thus you can trust it to run.
Earlier quoted context omitted.
If your server supports it, a fast and easy way to password protect a page is to put it in a folder and password protect that folder with htaccess: https://ithemes.com/blog/what-is-the-htaccess-file/#password...
Keep in mind the same server will lock you out for a day or so if you autofill the wrong password, be warned. :D
Earlier quoted context omitted.
It’s unclear why you’re being so flippant about “adding on HMAC.” The things you are describing are difficult and dangerous for developers to build.
Mostly because we have a bloody simple use case in this topic. 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 proba…
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.
I note down two other possible methods in the post. Would love to hear about more info.
Earlier quoted context omitted.
You keep saying "the Galois Field" as if that was a thing. It's GCM. The components of GCM are CTR mode and the GMAC authentication code, which is based on GHASH. If you're afraid of Galois fields, you don't get to use AES at all! Nobody should be implementing any of these primitives themselves, very much including CBC, which, as you saw downthread, left both you and the author of this project with an insecure crypto…
> You keep saying "the Galois Field" as if that was a thing You're kidding, right? You've never looked at how GCM-mode works? The entire set of math is inside of the GF(2^128) field. That's why its called a Galois Counter Mode. I don't think anyone should be implementing their own GCM mode. Its very subtle and potentially full of traps. CBC on the other hand is pretty dumb and simple, and surprisingly secure and robu…
Regardless there's no good reason not to use a vetted open source implementation instead, preferably with an even higher level of abstraction so your not having to worry about ciphers or modes of operation at all[1].
[1] https://doc.libsodium.org/secret-key_cryptography/secretbox
Earlier quoted context omitted.
> You keep saying "the Galois Field" as if that was a thing You're kidding, right? You've never looked at how GCM-mode works? The entire set of math is inside of the GF(2^128) field. That's why its called a Galois Counter Mode. I don't think anyone should be implementing their own GCM mode. Its very subtle and potentially full of traps. CBC on the other hand is pretty dumb and simple, and surprisingly secure and robu…
The math used in AES (Rijndael) utilize operations in GF(2^8) tho, so you're doing operations using Galois fields whether your utilizing GCM or CBC. I don't really see how adding the GCM mode utilizing GF(2^128) on top is significantly more difficult or error prone than implementing the AES block cipher itself. You should still be familiar with operations over Galois fields regardless if you've for some reason (fooli…
> Regardless there's no good reason not to use a vetted open source implementation instead, preferably with an even higher level of abstraction so your not having to worry about ciphers or modes of operation at all[1].
I think that's generally the preferred solution, yes.
Why html though? They do have some js and interactive functionality in there. I can slice and dice my monthly report within the single html page they send which is actually quite handy (and there’s the default “show me my transactions in a list with opening and closing balance” option as well).