3 ms·

> these channels have realtime requirements that necessitate stream ciphers be employed Even if that were relevant (you can easily convert a block cipher to a

• ngneer 2y ago
  Right, let's redesign telecom infrastructure...
  • lxgr 2y ago
    Isn't every new mobile standard effectively a complete redesign of the core network anyway? Sure, it'll take decades to be fully rolled out, but that's true for every large-scale change. The real problem is that it's not in the interest of stakeholders to have end-to-end security.
    • ngneer 2y ago
      Judging by this and your other comment, you seem to have made up your mind that the powers that be are not interested in end to end security. You seem to be ignoring (or disregarding without explanation) similar engineering feedback independently provided to you by different people. Good luck to you, sir!
      • lxgr 2y ago
        By stakeholders I don't mean the telecom industry, but the governments regulating it. Lawful interception is non-negotiable, and (working) end-to-end encryption would break that, so I predict that we'll never see it on the POTS, VoIP or circuit switched. (And even OTT VoIP is under constant political attack.) > You seem to be ignoring (or disregarding without explanation) similar engineering feedback You mean the other "Bellhead" comments explaining why it's technically impossible to do something on the POTS that's been solved in OTT VoIP for years, like real-time end-to-end encryption using block ciphers etc.? Yeah, I do discount confident statements declaring something technically impossible when I've been happily using such a system for the better part of a decade.
      • jeroenhd 2y ago
        Confidentiality in networking is entirely possible and rolling out such a system would make carriers instantly liable for every phone and internet connection they fail to wiretap. 5G has redesigned several core identifiers to make it harder for middleboxes to MitM/intercept traffic for a specific target. This has led to slowdowns in 5G rollout all over the world, as carriers needed their suppliers to figure out how to wire tap their customers now that they couldn't uniquely identify a customer by a static identifier anymore. Carriers may have the best intentions for the security and reliability of their customers, but they're legally obligated to deliver plaintext dumps of phone calls on their network somehow. Same goes for other unencrypted side channels such as SMS. If 6G redesigns the entire network to be fully E2EE, it's essentially illegal to roll out as a carrier. This isn't an engineering problem as much as it is a legal problem. There are also financial challenges in a secure system. You need to know who to bill for long international three-way calls. That sounds easy, but because of backwards compatibility and many different ways to do roaming, doing billing for mobile phones is an entire industry in itself.
• ngneer 2y ago
  You can "easily" convert a block cipher to a stream cipher on paper (e.g., using OFB or output feedback mode), but you will not get the performance. You clearly have no working knowledge here.
  • lxgr 2y ago
    I don't doubt that it's hard in existing systems, which might not have AES hardware instructions, spare processing power available etc., but my point is more that, if it were made a design goal, it would be absolutely feasible. If we can encrypt basically every HTTP request on the Internet, surely we can encrypt a few phone calls too? But the main problem is not technical, but that stakeholders don't want to anyway (lawful interception etc.), so presumably nothing will change.
    • tsimionescu 2y ago
      > If we can encrypt basically every HTTP request on the Internet, surely we can encrypt a few phone calls too? Again, you seem to not understand the performance requirements of real-time audio. The amount of data is tinry, but the latency (and particularly jitter) requirements are on a completelt different level than HTTP.
      • lxgr 2y ago
        Given that Signal and WhatsApp manage it just fine even on the slowest Android smartphones made in the past decade (without hardware AES acceleration), I’d say you are vastly overestimating the computational load of symmetric encryption. The added latency is probably undetectable, and unless the CPU is at capacity, there’s no extra jitter either.
        • ngneer 2y ago
          Conversely, you might be vastly overestimating channel capacity. If ALL subscriber calls were on WhatsApp or Signal, the network would grind to a halt.
• miki123211 2y ago
  The telco must know the secret key at time of use (because telephone networks are non-e2e nowadays and any new design must be interoperable), it's how the key is derived that is at issue here. If it's derived from symmetric key material, you need to hack the manufacturer, card or telco once, and then it's over. As long as you can observe the over-the-air procedure where the session keys are derived based on the static keys, you can listen in on the entire session. If it's derived from symmetric keys (both static and ephemeral), then if you are ever discovered and lose access to the operator's network, you can't decrypt any further communications.