Hacker News new | ask | show | jobs
by modeless 199 days ago
No, it doesn't depend on context. The intended recipient of a financial transaction is not the bank. The intended recipient is the party you're trying to pay. It is possible for financial transactions to be E2EE and completely indecipherable by anyone but the two parties of the transaction. Crypto like ZCash can do it. Banks cannot.
1 comments

Can you expand on this a bit. It was my understanding that you're telling the bank to pay the vendor (from your money/credit). In that case, the bank certainly needs to know about the transaction... so it can make the payment.

Are we talking about 2 different things here?

I suggest researching how ZCash uses zero-knowledge proofs to allow paying money from your balance to another person's balance without any middleman like a bank being able to decrypt your transaction, while still allowing everyone to verify that important invariants are maintained, such as not allowing you to spend more money than you have.

This is what it takes to make a financial transaction E2EE. I'm not saying that banks could or should do this. I'm just saying that their systems do not qualify as E2EE unless they do. It's not ambiguous.

Doesn't the anonymous-ness of crypto/zcash make it impossible for the bank to handle fraud (reversing of charges and such)?

My understanding is that banks, at least in the US, need to have fairly extensive knowledge relating to all transfers of money, both for fraud handling and for non-fraud (money laundering, etc). A transaction they can't know anything about other than "transfer X money to some recipient you can't know anything about" just doesn't seem realistic with the regulations involved.

Plus, even "transfer X money to some recipient you can't know anything about" is a message that you're sending _to_ the bank, that they have to be able to decode and read. And, presumably, you'd encrypt that message and expect the bank to decrypt it.

Honestly, I don't understand what argument is that you're not sending a message TO the bank, and they need to be able to read it in order to act on it, and they need to decrypt it to read it. The bank is the target of the message, they are one of the "ends" in E2EE.

I feel like I need an "Explain this like I'm 5", because clearly you believe differently than me... and I don't understand _how_ it can be otherwise.

Yes, banks have a bunch of regulations which means they can't run an end-to-end encrypted payment service.

That's an argument that their payment service is not end-to-end encrypted, not an argument that you can simply redefine the ends and say that it is.

Can you speak to this part?

> Honestly, I don't understand what argument is that you're not sending a message TO the bank, and they need to be able to read it in order to act on it, and they need to decrypt it to read it. The bank is the target of the message, they are one of the "ends" in E2EE.

That's the part that I'm confused on.

That's an implementation detail of the bank.

You might just as well say that E2EE messaging is impossible because you are sending a message "to" Signal, and they need to read it in order to act on it.

> I'm not saying that banks could or should do this. I'm just saying that their systems do not qualify as E2EE unless they do. It's not ambiguous.

That said, it might not be impossible to implement some enforcement of AML-like rules with zero-knowledge proofs. What's possible with advanced cryptography is not at all intuitive. But banks profit from their middleman position and surely wouldn't be interested in disintermediating themselves. Neither would crypto people be interested in adding AML. So I don't expect anyone to try. This fact still doesn't make existing middleman banks qualify as E2EE.