> 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 stream cipher): It's absolutely possible to do key derivation for a symmetric stream cipher asymmetrically.
> the telco must know the secret key
No, the telco must not know the secret key if they're serious about confidentiality.
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.
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.
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!
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.
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.
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.
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.
> 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.
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.
Conversely, you might be vastly overestimating channel capacity. If ALL subscriber calls were on WhatsApp or Signal, the network would grind to a halt.
Besides making no sense (modern networks are already largely VoIP based, so what’s the difference from a capacity point of view): What does that have to do with anything discussed in this thread, i.e. the feasibility of encrypting VoIP calls?
I'm really starting to wonder: Did I unintentionally send some kind of bat signal through time, channeling Bellhead objections to the feasibility of VoIP that have been thoroughly and empirically disproven years ago when the POTS largely switched to NGN and IETF standards, and people around the world have moved on entirely to Internet-based OTT VoIP services?
I was not commenting on VoIP, it works nicely and has for a long time, in the network core too. Mobile carriers do not use VoIP with the MS, to my knowledge. There's "Wi-Fi Calling", but that is the closest you're gonna get to packetized data streams reaching your phone (it sees traction where other reception is bad and the carrier has to rely on the Internet). Your use of "Bellhead" as a derogatory term is noted, and is more reflective on you than anything else. Feel free to have the last word, though.
No, they do, exclusively. LTE and beyond don’t even support circuit switched calls anymore.
Bellhead wasn’t intended in a derogatory way, just as a reference to the “Netheads vs. Bellheads” schools of thinking about networks.
I do have great respect for historical phone systems and the clever engineers making them work. In terms of absolute reliability, I think VoIP was indeed a step back (although I think that’s mainly due to modern engineering and QA practices than inherent limitations).
Exclusively? You make it sound like VoLTE is mandatory. That is not the case, to my knowledge. On a 4G network, for example, one does not always have VoLTE available, and yet one is always able to place voice calls. Since your conviction is palpable, if you could please provide a reference then that would help further the discussion. If not, then no worries, will find the information on my own.
> 4G and Evolved Packet Core (EPC) architectures do not include support for circuit-switched voice and video calls. Two tracks are available that provide interoperable voice services on 4G smartphones: Circuit-Switched Fallback (CSFB) and VoLTE.
Circuit switched fallback means falling back to 3G or 2G (or maybe CDMA) for voice calls; if such networks are no longer available in a given area, VoLTE is indeed mandatory if voice calls are to be supported. (Which is often mandated by regulations, so networks sometimes even block non-VoLTE UEs from attaching.)
Even if that were relevant (you can easily convert a block cipher to a stream cipher): It's absolutely possible to do key derivation for a symmetric stream cipher asymmetrically.
> the telco must know the secret key
No, the telco must not know the secret key if they're serious about confidentiality.