5 ms·

This would be neat if you could build a wrapper of this around GitHub pages. Then you could finally use GitHub pages sites for private content! Also, as a non-

This would be neat if you could build a wrapper of this around GitHub pages. Then you could finally use GitHub pages sites for private content! Also, as a non-security person, just how secure is this? Like is it used more for "eh, I don't really want something to see this, but it's not the end of the world if they do" or more like "yeah, use this for extremely secure content, it's safe."

sleepychu 9y ago
In part it depends on the strength (and secure transmission of your passphrase (though if you have a good way of transmitting the passphrase this becomes less useful)) The encryption itself is solid (assuming it is implemented correctly and as described, I've not inspected the code) but as mentioned a short pass phrase combined with predictable plain text format would make this quite easy to brute force.
- falcolas 9y ago
  The pass phrase also can't be changed, without reencryping the entire page. Once leaked, the contents are effectively publicly available. Also, you can't revoke access (again, without site-wide re-encryption). An interesting POC, but not something that is really practical for broader use.
  - sleepychu 9y ago
    I considered both these points when I was composing my answer but came to the conclusion that this is true for basically any encryption strategy, if I've transmitted contents signed with your public key then when your private key becomes known so does the contents. Even when you manage to keep the key secret I can't revoke your access to the material or prevent you re-transmitting it to others.
    - falcolas 9y ago
      True, but if there's one shared key for each page, the chances of that key getting loose are higher. There are alsomethods of encrypting a message where you can specify multiple recipients (i.e. multiple keys), letting you remove one key without affecting the viewership of the page for people with the other keys. It's a hard problem, and this is certainly a novel solution to that problem, but I still don't really see myself using it.
  - plaguuuuuu 9y ago
    you could just do the encryption on the server side, in which case you just change the key and done. /s
dangom 9y ago
Doesn't the GitHub pages content itself live in a repository visible to all? One could just look up the password. Or is it possible to have pages for private repos as well?
- Darphe 9y ago
  The passphrase wouldn't be included in the repo; that's the purpose of using client-side encryption.
- bluetidepro 9y ago
  What Darphe said in their reply. But yeah, you can setup pages for private repos. That's mainly what I was thinking. I currently do that for a few projects. You can have a private repo and still use github-pages, it just obviously exposes the pages to the public technically (but not the repo code).
nico_h 9y ago
Not an encryption expert, and would likely use it myself. My guess is it's about as secure as putting an encrypted file on the internet. Except this has almost all the information you need to know how it was encrypted. Plus it has a useful guess-the-password form. There is no attempt-limiting or rate-limiting if you can download the file.
- codazoda 9y ago
  I'm no expert but I think if they use a cryptographic function that requires a lot of CPU cycles, such as bcrypt, it will still be hard to brute force as long as you use a secure password. It looks, however, like they might have used something like sha256. I don't think that requires a lot of CPU and so it's much easier to brute forced. It's probably good enough for stuff like an informational product that you want to put behind a password but not good enough for storing your credit card details.
olkid 9y ago
short answer: no, it's not secure longer answer: look at the last script tag in the demo page, it exposes the encrypted HMAC string, the encrypted HTML text, the encryption method and even the library used to decrypt. You can easily brute force the passphrase ...or better yet embed some code in a popular web page and have the netizens brute force it for you (distributed computing). In general, client side obfuscation is difficult to perform securely as it shares too much information to be secure.

sleepychu 9y ago

In part it depends on the strength (and secure transmission of your passphrase (though if you have a good way of transmitting the passphrase this becomes less useful)) The encryption itself is solid (assuming it is implemented correctly and as described, I've not inspected the code) but as mentioned a short pass phrase combined with predictable plain text format would make this quite easy to brute force.

falcolas 9y ago
The pass phrase also can't be changed, without reencryping the entire page. Once leaked, the contents are effectively publicly available. Also, you can't revoke access (again, without site-wide re-encryption). An interesting POC, but not something that is really practical for broader use.
- sleepychu 9y ago
  I considered both these points when I was composing my answer but came to the conclusion that this is true for basically any encryption strategy, if I've transmitted contents signed with your public key then when your private key becomes known so does the contents. Even when you manage to keep the key secret I can't revoke your access to the material or prevent you re-transmitting it to others.
  - falcolas 9y ago
    True, but if there's one shared key for each page, the chances of that key getting loose are higher. There are alsomethods of encrypting a message where you can specify multiple recipients (i.e. multiple keys), letting you remove one key without affecting the viewership of the page for people with the other keys. It's a hard problem, and this is certainly a novel solution to that problem, but I still don't really see myself using it.
- plaguuuuuu 9y ago
  you could just do the encryption on the server side, in which case you just change the key and done. /s

dangom 9y ago

Doesn't the GitHub pages content itself live in a repository visible to all? One could just look up the password. Or is it possible to have pages for private repos as well?

Darphe 9y ago
The passphrase wouldn't be included in the repo; that's the purpose of using client-side encryption.
bluetidepro 9y ago
What Darphe said in their reply. But yeah, you can setup pages for private repos. That's mainly what I was thinking. I currently do that for a few projects. You can have a private repo and still use github-pages, it just obviously exposes the pages to the public technically (but not the repo code).

nico_h 9y ago

Not an encryption expert, and would likely use it myself. My guess is it's about as secure as putting an encrypted file on the internet. Except this has almost all the information you need to know how it was encrypted. Plus it has a useful guess-the-password form. There is no attempt-limiting or rate-limiting if you can download the file.

codazoda 9y ago
I'm no expert but I think if they use a cryptographic function that requires a lot of CPU cycles, such as bcrypt, it will still be hard to brute force as long as you use a secure password. It looks, however, like they might have used something like sha256. I don't think that requires a lot of CPU and so it's much easier to brute forced. It's probably good enough for stuff like an informational product that you want to put behind a password but not good enough for storing your credit card details.

olkid 9y ago

short answer: no, it's not secure longer answer: look at the last script tag in the demo page, it exposes the encrypted HMAC string, the encrypted HTML text, the encryption method and even the library used to decrypt. You can easily brute force the passphrase ...or better yet embed some code in a popular web page and have the netizens brute force it for you (distributed computing). In general, client side obfuscation is difficult to perform securely as it shares too much information to be secure.