91–100 of 112 posts
One of the problems with hacking the hashtag (#) in the URL is that this fragment identifier is supposed to be used to identify a portion of the document. As such unexpected things can happen when you try to exploit the hash tag for other purposes. For example, with older of versions of Microsoft Office you cannot use a pound character in a hyperlink: https://support.microsoft.com/en-us/help/202261/you-cannot-u... So…
Earlier quoted context omitted.
Well on the site it was said "We encrypt the content with that random key. In this case, we only encrypt the content once with the random key so we don’t need an iv and can leave it filled with 0 (I hope…)." Anyone think that is a good idea?
It's a good idea if you encrypt with the same key _once_ — you can avoid attaching nonces to your ciphertext (less code and data), and have only 16-byte key in the URL. In fact, using a random IV with AES-GCM is not exactly safe: 12-byte nonce is too small to avoid collisions with many encryptions. The recommendation is to not encrypt more than 2^32 messages with the same key if you use the random nonce.
I appreciate the effort, but this is one of those cases in which there isn't much security added by encryption. If I assume the website owner is malicious (or subverted by powers that be), I cannot trust the JS code provided by the website. Key disclosure is as trivial as one line hidden somewhere in megabytes of JS code delievered from the server. Which makes "end-to-end" part nearly meaningless.
I appreciate the effort, but this is one of those cases in which there isn't much security added by encryption. If I assume the website owner is malicious (or subverted by powers that be), I cannot trust the JS code provided by the website. Key disclosure is as trivial as one line hidden somewhere in megabytes of JS code delievered from the server. Which makes "end-to-end" part nearly meaningless.
Are there any current browser standards for validating that the served JS is ‘safe’? I can see such a thing being also useful for applications like ProtonMail, for example? What about something like a browser extension that queries an audit server for a list of signed hashes of ‘safe’ JS? - Well-known code auditors could perform reviews of JS - They could sign JS they find safe with their PGP keys and upload it to so…
I appreciate the effort, but this is one of those cases in which there isn't much security added by encryption. If I assume the website owner is malicious (or subverted by powers that be), I cannot trust the JS code provided by the website. Key disclosure is as trivial as one line hidden somewhere in megabytes of JS code delievered from the server. Which makes "end-to-end" part nearly meaningless.
How does that differ from a native app? In any E2E context you have to trust the client code. Sure, there are a couple extra steps needed here: - The website author needs to avoid casually throwing in dependencies (unlike perhaps the average JS project) - HTTPS for loading code resources is crucial; maybe even CDNs need to be avoided - The user needs to avoid having browser extensions enabled But the fundamental prob…
To reduce that risk, and temptation, we want to be in a model where the likelihood of detecting a compromised payload is increased. This is why software distributions like Debian are important, because they serve the same content to all their users, and there is a chain of verification that is established. One vigilant user is enough to detect that breach.
An even better solution is if the source code is available because it makes it easier for vigilant users to find those undesirable changes. This, paired with reproducible builds also allow to independently verify that the compiled output is indeed produced from that given source code.
Somewhere on that line we also have App stores which don't gives much more guarantees than the website but transfer that trust from the publishers to the application distribution platform. A compromised user still has the opportunity to capture the binary and submit it for analysis.
Earlier quoted context omitted.
Yeah, the WebCrypto API has a built-in function for this. I hope the author fixes the code, because this is otherwise a dangerous tutorial. window.crypto.getRandomValues(new Uint8Array(12)); If the author followed the MDN guides for it, they would have noticed that the example code also uses a random array. https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt...
No, it doesn't need to be random if the key is used only once. PS The author didn't just copy something from a tutorial without knowing what he was doing, he actually asked for advice https://github.com/excalidraw/excalidraw/issues/610
Though I have two thoughts on that:
1. It wouldn't add very much complexity to implement random IV's. You can send it with the ciphertext, or in the generated URL. In my own project, I use btoa(JSON.stringify({ key: generatedKey, iv: randomIv })) and reverse the operation when the URL is accessed:
const fragmentData = window.location.hash.substr(1);
const keyParameters = JSON.parse(atob(fragmentData));
const key = HexMix.hexToUint8(keyParameters.key);
const iv = HexMix.hexToUint8(keyParameters.iv);
Edit #2: Ah-ha, and now I've learned something else from the Excalidraw team; I can skip my hex/uint & base64 conversions if I export the key as jwk.
2. There are a _lot_ of tutorials out there that incorrectly reuse the key with a fixed IV. I was more concerned about this being yet another tutorial that someone blindly follows and ends up reusing the key regardless.
Earlier quoted context omitted.
Why? It makes it easy to share a sketch with someone else while still preventing the server from decrypting the data. Anything stored in a location hash (after the # symbol) does not get passed to the server. The threat model the author tried to work around is not the user dumbly compromising their own work. The author wants to prevent proprietary and PII data from being stored on their own server. End-to-end encrypt…
> Why? It makes it easy to share a sketch with someone else while still preventing the server from decrypting the data. Anything stored in a location hash (after the # symbol) does not get passed to the server. I'll hit the URL bar and hit control-C. That's way better than any javashit which wants to touch my clipboard. Copying the current URL also copies the key in that case. Now I'm accidentally sharing my encrypti…
Earlier quoted context omitted.
Are there any current browser standards for validating that the served JS is ‘safe’? I can see such a thing being also useful for applications like ProtonMail, for example? What about something like a browser extension that queries an audit server for a list of signed hashes of ‘safe’ JS? - Well-known code auditors could perform reviews of JS - They could sign JS they find safe with their PGP keys and upload it to so…
dat:// can give you that.
Earlier quoted context omitted.
Others have said it's open-source. Build it yourself, inspect what your browser downloads, hash and compare like normal.
It doesn't even have to be open-source. Any JS that will get run is handed to your browser and you are able to inspect it.
To add on to that, when there's an update, you usually can't diff it properly because large parts of the transpiled Javascript may change because of a one line change in the actual source code.
This is all assuming the website isn't actively trying to make it difficult for you to analyze their code.
At least if it's open source, you can inspect the source code then verify that the output is the same.