Oh come on, you don’t really believe that Nazi shit, do you?

edit: this post title said ‘que’ when i first posted this comment, but was later edited

!lifeprotips@lemmy.ml

No. Unless Stripe has also implemented the ZK protocol in their whitepaper (which i’m sure they haven’t) then whatever PCI stuff Stripe does is entirely unrelated to the privacy guarantees implied by phreeli’s new protocol.

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 g^a (2³, 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 g^b (2⁴, 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 B^a is equal to A^b (because (g^a)^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 (16³, or 16*16*16) and gets 4096
2. Bob raises Alices’s public key to the power of his private key (8⁴, 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.

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…)

Much respect to Nick for fighting for eleven years against the gag order he received, but i’m disappointed that he is now selling this service with cryptography theater privacy features.

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.

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? 🤷

a summary can be helpfull

No. LLMs can’t reliably summarize without inserting made-up things, which your now-deleted comment (which can still be read in the modlog here) is a great example of. I’m not going to waste my time reading the whole thing to see how much is right or wrong but it literally fabricated a nonexistent URL 😂

Please don’t ever post an LLM summary again.

Did you miss that OP mentioned they’re blind?

see also: Conscription of people with disabilities. It’s ongoing in present-day Ukraine.

Phew! I am extremely relieved to find out those videos are fake.

It’s pretty fucked up of TikTok to have tricked us like that, but I’m sure under Larry Ellison’s new leadership they’ll sort things out.

not the first time OP is raising questions like this 🤔