[RHSeeger]

I would argue it depends on context. E2EE means it's encrypted until the "target" receives it. For a messaging protocol, it's the intended recipient of the message. For what the person you're replying is discussing, the intended recipient IS the bank.

That being said, the person you're replying to seems to be saying that "the server" is always an "intended" end, which is wrong.

[modeless]

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.

[RHSeeger]

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?

[modeless]

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.

[RHSeeger]

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.

[jstanley]

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.

[RHSeeger]

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.

[modeless]

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

[stephen_g]

While what you're saying makes sense, it's not the normal use of the term - in fact, the term 'end to end encryption' was basically coined to differentiate user-to-user encryption (through an intermediary service that can't decrypt the message) from the regular case (user to service encryption) that you're talking about!

[calebio]

It wasn't coined, it was reused. It historically meant things that were encrypted from the client to the server, e.g. SSH, SSL, TLS, etc.

RFC 4949 (Internet Security Glossary, Version 2) from 2007: https://datatracker.ietf.org/doc/html/rfc4949

     $ end-to-end encryption
      (I) Continuous protection of data that flows between two points in
      a network, effected by encrypting data when it leaves its source,
      keeping it encrypted while it passes through any intermediate
      computers (such as routers), and decrypting it only when it
      arrives at the intended final destination. (See: wiretapping.
      Compare: link encryption.)

      Examples: A few are BLACKER, CANEWARE, IPLI, IPsec, PLI, SDNS,
      SILS, SSH, SSL, TLS.

      Tutorial: When two points are separated by multiple communication
      links that are connected by one or more intermediate relays, end-
      to-end encryption enables the source and destination systems to
      protect their communications without depending on the intermediate
      systems to provide the protection.

There's a bunch of older references as well. Since SSL/TLS wasn't really adopted by a lot of services until 2008+ usages of it are mainly in papers, old forum posts, etc. I saw it used and was discussing it back in the day on IRC with folks who were way more knowledgeable than me on this topic and had been in the trenches for a while :D