I’m a developer and I’ve created websites and mobile/desktop apps for business and self-employees.

I’m a person who always liked privacy and I’m planning to create a Google photos open source alternative. Alternatives already exist but what makes this project different is that it’s going to be quantum resistant.

This is my plan:

  • Photos backups, sharing, see photos locations in Open Street Map.

  • Use recommended post quantum algorithms by The National Institute of Standards and Technology.

  • Take an hybrid approach, this is quantum and already known encryption.

  • Create the app with Material 3 design.

I’m just creating this post just to see if there would be people interested in this project and to ask if you could share your opinion.

  • Do you think there would be a market for this?

  • Would you be interested in being an early adopter and test it out?

Please share suggestions and opinions! 😁

      • The Bard in Green@lemmy.starlightkel.xyz
        4·
        1 year ago

        As a fellow (and somewhat informed) post quantum enthusiast, I would take that debunk with a carton of salt. A lot of it comes down to “we don’t trust the gubmint!”

        One of the objections, for example, is “unless you’re inside NIST… blah blah blah.”

        I live in Boulder Colorado. I’ve been inside NIST and I have friends who work there. They’re not NSA spooks, they’re science and math nerds (some with PHDs). YES the NSA sticks it’s fingers in stuff (I’ve heard friends complain about this), but MOST of that has to do with funding and priorities (as it impacts the researchers there). They’re just science and math nerds who happen to have government jobs.

        One thing about the NSA is YES they want to break crypto and spy on people, but they ALSO want to create safe crypto (so they can use it without worrying China and Russia are going to find their little back doors and backdoor THEM).

        On the flip side, Daniel Berstein is an interesting guy who’s done cool stuff to support free software and opensource as far back as the 90s. He’s probably right that NIST needs to be more transparent in setting their standards and in the math that they use and as things progress him and others advocating for transparency should absolutely keep pushing. But is that a reason for the internet to freak out an say “Don’t play with Kyber, the NSA P0w3ned it!!11!!!” Absolutely not! We should be playing with Kyber (I’m using it in two different projects right now), so that we can learn and understand how to implement it (and other, future post quantum algorithms). I’m assuming Kyber is NOT going to be the be all and end all of post quantum. We’re still at very early stages here.

  • BeefPiano@lemmy.worldEnglish
    17·
    1 year ago

    Where do the encryption algorithms come in to play? In flight or at rest? What threat vectors are you hardening against?

  • folkrav@lemmy.world
    91·
    1 year ago

    I’m not too sure if “it uses a different encryption algorithm” is enough to differentiate from the competition. And to be perfectly honest, from one developer to another, I’m always extremely skeptical when a developer says “I plan to develop X” before I see something concrete like a codebase or some kind of alpha 😛

  • sloppy_diffuserEnglish
    2·
    1 year ago

    A few notes as I’ve been doing some PQ research for my own projects:

    • NIST PQ encryption algorithms are typically for encrypting small amounts of data due to poor performance (like an AES symmetric key)
    • NIST PQ encryption algorithms use public key cryptography to securely exchange keys between two parties (usually to establish a AES symmetric key… aka Key Encapsulation Mechanism, or KEM, with a Key Derivation Function, or KDF, which frequently uses Hash-based Message Authentication Code, or HMAC)
    • Hybrid-PQ, as you mentioned, should be used since there are not years of testing on the new PQ algorithms
    • AES256 is PQ with good performance, but lacks a way to securely exchange the shared key, so typically public key cryptography is used to bootstrap

    With that said, I’d want to know where and how the encryption is going to be applied.

    An ideal solution for me:

    • Data is stored using AES on device and remote
    • I have soul access to the AES key (can be derived, see last note)
    • App generates and index of meta searchable fields and thumbnails also AES encrypted, but is decrypted when opening the app to make it usable.
    • I can choose my backup (checkout rclone)
    • All over the top features like OSM are done client side (or self-hosted backend)
    • PQ would really only come into play to seal the AES key on my device. Instead of unlocking my photos with my AES key directly, its sealed behind a passphrase, pin code, hardware token, or other type of key. Pretty much what LUKs and Bitwarden do. Option for multiple keys would be great. A new device might take a passphrase and hardware key, but then might be sealed by a pincode.

    I suppose you could use a PQ TLS, but if the payload is already AES encrypted, I see little value. You could use PQ to sign each object I suppose in case your AES key is broken, but that would mostly detect tampering of the data.