• 0 Posts
  • 25 Comments
Joined 2 years ago
cake
Cake day: June 30th, 2023

help-circle
rss



  • @sloppy_diffuser@sh.itjust.workstoPrivacy@lemmy.mlGrapheneOS
    link
    fedilink
    English
    10
    edit-2
    3 months ago
    1. Not sure on this one.

    2. The auditor is to make sure you are installing an authentic version of graphene. That it is not a modified version that has been tampered with (e.g., backdoors).

    3. Automatically enables MAC randomization. This can help with being tracked on public networks. Fingerprinting techniques have gotten better though with deep packet inspection and even measuring radio characteristics. I’ve seen demos of two brand new and identical models of iPhones being distinctly picked out due to variances in the radios during manufacturing.

    Doesn’t help with advertisers tracking behavior based on IP. VPNs help with “blending-in” by putting multiple users behind the same IP. Provider matters here. Needs to be a VPN provider that won’t just sell your data or cave to law enforcement. Mullvad is my preference. Paid with crypto. RAM only logs. That said, use Tor or I2P for anything you don’t want subpoenaed.

    For additional tips:

    • Can’t remember if its on by default, but auto-reboot to put data at rest (encrypted and not in RAM). This is for a state-actor threat level, and less about advertisers.
    • I prefer pin codes to unlock my device and don’t use biometrics. Graphene has a feature to randomize the pin pad every time to protect against a recording of the pin be entered. Specifically where the numbers aren’t picked up on the video but the pattern your hand makes can be seen. Again, more of a state-actor threat level.

  • There is anonymity and pseudonymity.

    Do you need your opsec to be resistant to state-level actors (oppressive regime, censorship, illegal activities)? Well then you need to make sure you don’t introduce anything that will deanonomize you.

    Are you trying to be resistant to mass data collection efforts used for profit? Being on the pseudonymity spectrum is a good step.

    Dealing with the latter is like dealing with a bully. Make it not worth their time. They just want to put you in bucket X so they can estimate the most likely way to influence you for reason Y. Pseudonymity is about having multiple aliases that get put into different buckets so their privacy invasive efforts are less effective.




  • One of the pirate bay founders created https://njal.la/#home but with the caveat:

    For instance, when you register a domain name in our system, we can register with our own data. We will be the actual registrant of the domain – it’s not an ownership by proxy as found with all other providers. However, you will still have the full control over the domain name. You can either use our information (and our nameservers) or you can go with your custom data. And you can move at any time. Simple, flexible.

    I believe it is required (ICANN?) to have a real entity attached to every domain, even with a proxy for the public whois. They simply offer to be that identity to avoid giving any identifying information, but they will have all claim on it if it came to a legal dispute.







  • As another poster said, the underlying tech is not private: https://jmp.chat/privacy

    For backwards compatibility, what your proposing is unlikely unless driven through regulation (personal opinion).

    Use something over the top (like Signal was suggested), use a non-KYC provider (like Jmp), or use a burner phone.

    A non-KYC provider I wouldn’t trust to be private personally, especially as a secondary SIM. Maybe slightly above average (the company can’t sell the number attached to my name), but I’m sure enough information leaks that a state-level actor could correlate the device to me. The IMEI the tower gets is probably enough to run to Google to figure out who bought the phone.

    Even burners may trace back to you through GPS or triangulation depending on how private you really want to be.




  • I’ve been getting in the habit of using per service emails and rotating them like my passwords (if the service allows). MS allows this (assuming the account is not for your email). I’ve changed it 5-6 times. Except for Skype which I don’t use. Can’t seem to change that one myself.

    Others mentioned YubiKey. Another alternative I use is both an OnlyPass and Mooltipass, interchangeably. They act as keyboards and work with any device I’ve tried that supports USB keyboards without some agent always running. With it I’ll add an extra 56 random characters on top of my memorized passphrase for critical systems (disk encryption, system login, password manager).


  • 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.