cultural reviewer and dabbler in stylistic premonitions

  • 45 Posts
  • 281 Comments
Joined 4 years ago
cake
Cake day: January 17th, 2022

help-circle




  • If a payment processor implemented this (or some other anonymous payment protocol), and customers paid them on their website instead of on the website of the company selling the phone number, yeah, it could make sense.

    But that is not what is happening here: I clicked through on phreeli’s website and they’re loading Stripe js on their own site for credit cards and evidently using their own self-hosted thing for accepting a hilariously large number of cryptocurrencies (though all of the handful of common ones i tried yielded various errors rather than a payment address).


  • So like, it’s a situation where the “lock” has 2 keys, one that locks it and one that unlocks it

    Precisely :) This is called asymmetric encryption, see https://en.wikipedia.org/wiki/Public-key_cryptography to learn more, or read on for a simple example.

    I thought if you encrypt something with a key, you could basically “do it backwards” to get the original information

    That is how it works in symmetric encryption.

    In many real-world applications, a combination of the two is used: asymmetric encryption is used to encrypt - or to agree upon - a symmetric key which is used for encrypting the actual data.

    Here is a simplified version of the Diffie–Hellman key exchange (which is an asymmetric encryption system which can be used to agree on a symmetric key while communicating over a non-confidential communication medium) using small numbers to help you wrap your head around the relationship between public and private keys. The only math you need to do to be able to reproduce this example on paper is exponentiation (which is just repeated multiplication).

    Here is the setup:

    1. There is a base number which everyone uses (its part of the protocol), we’ll call it g and say it’s 2
    2. Alice picks a secret key a which we’ll say is 3. Alice’s public key A is ga (23, or 2*2*2) which is 8
    3. Bob picks a secret key b which we’ll say is 4. Bob’s public key B is gb (24, or 2*2*2*2) which is 16
    4. Alice and Bob publish their public keys.

    Now, using the other’s public key and their own private key, both Alice and Bob can arrive at a shared secret by using the fact that Ba is equal to Ab (because (ga)b is equal to g(ab), which due to multiplication being commutative is also equal to g(ba)).

    So:

    1. Alice raises Bob’s public key to the power of her private key (163, or 16*16*16) and gets 4096
    2. Bob raises Alices’s public key to the power of his private key (84, or 8*8*8*8) and gets 4096

    The result, which the two parties arrived at via different calculations, is the “shared secret” which can be used as a symmetric key to encrypt messages using some symmetric encryption system.

    You can try this with other values for g, a, and b and confirm that Alice and Bob will always arrive at the same shared secret result.

    shia labeouf magic gif

    Going from the above example to actually-useful cryptography requires a bit of less-simple math, but in summary:

    To break this system and learn the shared secret, an adversary would want to learn the private key for one of the parties. To do this, they can simply undo the exponentiation: find the logarithm. With these small numbers, this is not difficult at all: knowing the base (2) and Alice’s public key (8) it is easy to compute the base-2 log of 8 and learn that a is 3.

    The difficulty of computing the logarithm is the difficulty of breaking this system.

    It turns out you can do arithmetic in a cyclic group (a concept which actually everyone has encountered from the way that we keep time - you’re performing mod 12 when you add 2 hours to 11pm and get 1am). A logarithm in a cyclic group is called a discrete logarithm, and finding it is a computationally hard problem. This means that (when using sufficiently large numbers for the keys and size of the cyclic group) this system can actually be secure. (However, it will break if/when someone builds a big enough quantum computer to run this algorithm…)



  • Can someone with experience doing ZK Proofs please poke holes in this design?

    One doesn’t need to know about zero-knowledge proofs to poke holes in this design.

    Just read their whitepaper:

    You can read the whole thing here but I’ll quote the important part: (emphasis mine)

    Double-Blind Armadillo (aka Double Privacy Pass with Commitments) is a privacy-focused system architecture and cryptographic protocol designed around the principle that no single party should be able to link an individual’s real identity, payments, and phone records. Customers should be able to access services, manage payments, and make calls without having their activity tracked across systems. The system achieves this by partitioning critical information related to customer identities, payments, and phone usage into separate service components that communicate only through carefully controlled channels. Each component knows only the information necessary to perform its function and nothing more. For example, the payment service never learns which phone number belongs to a person, and the phone service never learns their name.

    Note that parties (as in “no single party”) here are synonymous with service components.

    So, if we assume that all of the cryptography does what it says it does, how would an attacker break this system?

    By compromising (or simply controlling in the first place) more than one service component.

    And:

    obi wan "of course i know him, he's me" meme gif

    I don’t see any claim that any of the service components are actually run by independent entities. And, even if they were supposedly run by different people, for the privacy of this system to stop being dependent on a single company behind it doing what they say they’re doing, there would also need to be some cryptographic mechanism for customers to verify that the independent entities supposedly operating different parts were in fact doing so.

    In conclusion, yes, this is mostly cryptography-washing. Assuming good intentions (eg not being compromised from the start), the cryptographic system here would make it slightly more work for them to become compromised but does not really prevent anything.

    The primary thing accomplished by cryptography here over just having a simple understandable “we don’t record the link between payment info and phone numbers, but you’ll just have to trust us on that” policy is to give potential customers a (false) sense of security.


  • SMS can have end to end encryption

    in theory it can, but in practice i’m not aware of any software anyone uses today which does that. (are you? which?)

    TextSecure, the predecessor to Signal, did actually originally use SMS to transport OTR-encrypted messages, but it stopped doing that and switched to requiring a data connection and using Amazon Web Services as an intermediary long ago (before it was merged with their calling app RedPhone and renamed to Signal).

    edit: i forgot, there was also an SMS-encrypting fork of TextSecure called SMSSecure, later renamed Silence. It hasn’t been updated in 5 (on github) or 6 (on f-droid) years but maybe it still works? 🤷







  • I think you misunderstood me

    Go ahead and post the same link for Google job listings. I’ll wait.

    My comment was in response to your comments (bolded below) in this thread:

    I was already thinking of getting a Linux phone next, this is helping to seal the deal. Fuck Apple the genocide enablers.

    please do explain how Apple is doing anything here. If Israel wants to provide their military with iPhones they’re going to no matter what Apple does.

    They don’t have to do business with/in Israel.

    That still will not stop a nation state (especially Israel) from getting their hands on Apple devices.

    My point was not to say that Google is better than Apple here - in fact, unlike Apple (as far as I know), Google has actually built AI tools specifically tailored for Israel’s genocidal business requirements.

    My point is that if Apple wanted to boycott a country (which in the case of Israel they obviously don’t, which job listings at their R&D centers are just one of many points of evidence of) it would actually make it difficult-to-impossible for any substantial part of the boycotted country’s government to rely on using iPhones.

    (Unlike Android derivatives which can easily be used without direct reliance on Google’s services…)

    As an aside, while I would not use iOS (due to it being proprietary), it is hard to dispute that (for most adversaries, at least) compromising it is generally much more expensive/difficult/unlikely than Android. So, given that Apple is very friendly to them, the IDF’s policy decision to use iPhones makes sense.




  • no transcoding quality loss

    is jellyfin actually transcoding when people don’t want it to?!

    otherwise, “no transcoding” doesn’t sound like a feature. transcoding is very useful when you actually need it, eg watching something remotely which is stored at a higher bitrate than your network connection can stream. one way to do it with mpv is ffmpegfs, btw.

    (fellow mpv user here; i’ve only used other people’s jellyfin instances… but i’d be very surprised if they’re always unnecessarily transcoding everything they watch.)