Is there a way to develop and website using JS (and perhaps PHP) to create an E2EE website. Were all packets sent between the server and the userw device are E2EE, wrapped in a layer of encryption?

I know there is HTTPS but I am looking for something stronger than HTTPS.

By using some JS or PHP E2EE package, would I have to write or structure the website code very differently than you normally would?

  • Sibbo@sopuli.xyz
    link
    fedilink
    arrow-up
    5
    ·
    10 months ago

    Unless you want to go with multiple layers of encryption, there is nothing significantly “stronger” than TLS 1.3 at the moment. And multiple layers are only used for anonymity, for example in Tor. Having multiple layers between just two endpoints without intermediary steps does not make anything significantly better.

    Other examples include mega, which encrypts all files it stores for clients on the client side, and then never transfers the key. This way, the client’s data is E2EE in the sense that only the people with the link can read it, but the mega servers can’t.

    • trymeout@lemmy.worldOP
      link
      fedilink
      English
      arrow-up
      1
      arrow-down
      1
      ·
      10 months ago

      Mega is a good example of what I want to learn to create. Not just to transfer files, but for what text is displayed on the page and the form field values and have it so that the server admins cannot decrypt and is encrypted this data in transit.

      • Evotech@lemmy.world
        link
        fedilink
        arrow-up
        2
        ·
        10 months ago

        I mean, the server would need to have the private keys in order to encrypt the data right

      • jeremyparker@programming.dev
        link
        fedilink
        arrow-up
        1
        ·
        10 months ago

        I had no idea mega did that, that’s awesome. The whole idea that the server doesn’t have the key, like – it’s so simple, but it never occurred to me. Why would the server ever need to decrypt it?

        This shit is wrinkling my brain.

        And I’m even more mad at every cloud provider. Why you decrypting my shit, Google?

        So I guess the question is, for your site idea, where does the encryption start? Like, you want the text on the page and the form data encrypted, but, is the text on the form’s submit button encrypted? If it is, your user has to be a developer to some extent, or you needs to build like a WordPress style wysiwyg editor that also encrypts everything – and, like, that’s kinda cool, but actually writing that code sounds like torture. I’d rather spend all that development time giving myself papercuts and squirting lemon juice into them.

        So an encryption “barrier” has to exist. The Mega server doesn’t decrypt your file, but it knows that it’s getting a file of some kind for you, and it knows the shape of the data. It’s not completely ignorant – and, like the WordPress problem above, you could prevent that – keep the server from even knowing what it’s doing – again, kinda cool, but it sounds like torture to actually write.

        So the question is, where are you putting that barrier? It seems like, wherever that barrier is, is also how deep a non-developer user can get into using it. To put that another easy: the more of the site’s content that’s encrypted, the more development skills the user has to have.

        Or I’m just misunderstanding your project entirely, which I will attribute to the fact that it’s 1am.

  • towerful@programming.dev
    link
    fedilink
    arrow-up
    5
    ·
    10 months ago

    How would it be stronger than HTTPS?
    What makes it stronger than HTTPS?

    What is the attack vector you are trying to protect against?

  • 𝒍𝒆𝒎𝒂𝒏𝒏@lemmy.dbzer0.com
    link
    fedilink
    arrow-up
    3
    ·
    10 months ago

    Honestly I would rely on just using HTTPS if you can, it’s very easy to get crypto stuff wrong.

    My old self-implemented encryption implementations were absolutely horrible. I did not understand what salting was, IVs, or any of that. Most of which I still don’t. The application I developed at the time was using AES, a symmetric encryption algorithm, which meant that if you were to decompile or take it apart, you’d have access to the same keys being used by the backend server - meaning that while data was technically “encrypted”, all the keys were freely accessible to decrypt any traffic that was intercepted. Thankfully the application (an offsite smartcard authentication client) has been long been put out of use, and the backing infrastructure no longer exists.

    Aside from that, here’s an interesting write up of how Valve used a javascript RSA implementation prior to HTTPS being as widespread as it is now: https://web.archive.org/web/20210108003523/https://owlspace.xyz/cybersec/steam-login/ (provided archive link as original site no longer exists). RSA is not a symmetric algorithm so worked fine for this, at least for back then in that time period.

    If you would still prefer to not use HTTPS, I would strongly recommend using something well known and popular, like Signal’s battle tested E2EE protocol (used for RCS messages and WhatsApp messages)