Earlier quoted context omitted.
I don't know what "being a stream" has to do with anything (you should virtually always use "stream" modes of AES); the meaningful distinction between CBC and GCM is that GCM authenticates the ciphertext, so you can't tamper with it.
> so you can't tamper with it. ... if the API provided is correctly designed, and either the language made it practical to design the API in a misuse-resistant way /or/ the programmer was actually careful and used it properly. We both know it's way more likely the problem in your actual system is "Oops, we use the bogus plaintext here despite the validation error" than "Dastardly enemy cryptographers have made a brea…
Password protect a static HTML page
101–110 of 294 posts
Re: Password protect a static HTML page
#102Not sure I'd trust it myself, but it definitely seems like a good option for those with limited hosting options (like GitHub pages or Neocities) and a need to secure some content.
Re: Password protect a static HTML page
#103Earlier 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…
Re: Password protect a static HTML page
#104Earlier quoted context omitted.
> Or... you can have a more nuanced viewpoint The nuanced viewpoint is never implement your own cryptography. > Its so stupid simple I don't think that even a novice would make a critical error. Ask Microsoft about that one: https://learn.microsoft.com/en-us/security-updates/securityb...
That's a Padding Oracle vulnerability, not a CBC error.
Re: Password protect a static HTML page
#105Earlier quoted context omitted.
> Or... you can have a more nuanced viewpoint The nuanced viewpoint is never implement your own cryptography. > Its so stupid simple I don't think that even a novice would make a critical error. Ask Microsoft about that one: https://learn.microsoft.com/en-us/security-updates/securityb...
That's a Padding Oracle vulnerability, not a CBC error.
Re: Password protect a static HTML page
#106A more lightweight solution would be to hash the password and have a copy of that file at this url. windows.location = hash(password);
A more lightweight solution would be to let the Webserver (nginx, https, whatever) password-protect the site. No JavaScript required a d highly efficient
Re: Password protect a static HTML page
#107Pagecrypt does the same thing, but with the Web Crypto API. More (including a sample repo) at https://render.com/blog/static-site-auth-pagecrypt .
It works with a GPG-encrypted file. I figured that was safer than developing my own encryption format. As it is, any vulnerability in the decryption process is equivalent to a vulnerability in GPG.
Re: Password protect a static HTML page
#108I'm not a cryptographer, but I'm pretty sure that CBC ( https://github.com/robinmoisson/staticrypt/blob/main/lib/cry... ) should be replaced with GCM ( https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt... ) since this is not a stream. https://security.stackexchange.com/questions/184305/why-woul... (also, use the built-in WebCrypto API instead of the crypto-js package)
It seems that the hmac validation makes the GCM unnecessary in their thread model
Re: Password protect a static HTML page
#109Re: Password protect a static HTML page
#110Earlier quoted context omitted.
I would call any server side or client side code which alters the HTML non-static. A static HTML page is just an HTML file which is stored on the server and displayed as-is in the browser.
Exactly. I don't know where the confusion is, but I'm saying that it doesn't matter how the page is generated. It is sent to the website visitor as just HTML. When the user views it it is all there, just html. No changes. For example, I have a perl script that generates a set of .html files every night to show new additions to my library. They are static .html files on disk and never modified before the user views th…
If your perl script is saving the HTML to the disk, then yeah, your website is static. If it's generating HTML on the fly, it's dynamic. That's the widely agreed upon meaning, and that's it.