3 ms·

Of course I know how TLS works, as well as PFS. I recommend Kaufman on the subject. The general scheme you refer to is known as hybrid cryptography, and the key

by ngneer 2y ago

Of course I know how TLS works, as well as PFS. I recommend Kaufman on the subject. The general scheme you refer to is known as hybrid cryptography, and the key material that is derived is used to generate symmetric keys for the TLS session (several keys, in fact, separately for confidentiality and integrity, and for duplex communications). You missed my point completely, though. Unlike TLS sessions, which rely on packets, calls are multiplexed with TDMA or CDMA, for example. Unlike TCP, these channels have realtime requirements that necessitate stream ciphers be employed. I could ask you if you know how telecom works, but that would be childish and demeaning. As ephemeral as you wish to make it, the telco must know the secret key, for imagine if the call is being relayed to Timbuktu and must be passed in plaintext.

lxgr 2y ago
> 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.
- 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.
andrewflnr 2y ago
You're telling me it's absolutely impossible to run a key exchange over these channels?
- ngneer 2y ago
  Not without redesign. I am telling you that whatever key exchange you run, it will result in key material that is accessible by the telco and therefore by your adversary (e.g., PRC). This is true even if you deployed authenticated Diffie-Hellman between endpoints. You might be able to do secure VoIP on top of that, but you cannot use existing telco infrastructure for your calls without expecting the tower to be able to decrypt the call. The ability of the telco to decrypt the call is the very basis of CALEA and LI, or lawful interception modules, and the reason why Salt Typhoon works.
  - andrewflnr 2y ago
    The point is to limit the damage of a key leak, not eliminate it. Limiting the scope of a compromise to a single connection rather than all communications for the past and future is an improvement. And yeah, of course we're talking about a redesign. If we were content with the status quo why would we be here?
    - ngneer 2y ago
      Sorry about that. Assumed you were trying to piggyback on the existing, to come up with a practical fix. Never entered into my mind that you were suggesting to overhaul the infrastructure. Yes, if you redesigned everything from scratch everything is possible. I will say, however, that getting rid of legacy is often harder than people think.

by ngneer 2y ago

lxgr 2y ago

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

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.

andrewflnr 2y ago

You're telling me it's absolutely impossible to run a key exchange over these channels?

ngneer 2y ago
Not without redesign. I am telling you that whatever key exchange you run, it will result in key material that is accessible by the telco and therefore by your adversary (e.g., PRC). This is true even if you deployed authenticated Diffie-Hellman between endpoints. You might be able to do secure VoIP on top of that, but you cannot use existing telco infrastructure for your calls without expecting the tower to be able to decrypt the call. The ability of the telco to decrypt the call is the very basis of CALEA and LI, or lawful interception modules, and the reason why Salt Typhoon works.
- andrewflnr 2y ago
  The point is to limit the damage of a key leak, not eliminate it. Limiting the scope of a compromise to a single connection rather than all communications for the past and future is an improvement. And yeah, of course we're talking about a redesign. If we were content with the status quo why would we be here?
  - ngneer 2y ago
    Sorry about that. Assumed you were trying to piggyback on the existing, to come up with a practical fix. Never entered into my mind that you were suggesting to overhaul the infrastructure. Yes, if you redesigned everything from scratch everything is possible. I will say, however, that getting rid of legacy is often harder than people think.