4 ms·

That’s because there isn’t a point. In order for encryption to work, you need to exchange keys at some point. Doing that half a world away is rather pointless.

That’s because there isn’t a point. In order for encryption to work, you need to exchange keys at some point. Doing that half a world away is rather pointless. Doing it over the air, how do I know Alice won’t intercept and broadcast her keys louder than me? Or just interfere and prevent me from sending keys? As we all learned in WWII, a code is better than encryption when you need complex PKI to achieve encryption. It’s more flexible, and can even convey nuances not intended. Ah, sorry I mean a language, not a code. But still, code words and phrases are still a thing.

charcircuit 3y ago
You are ignoring HTTPS allows people half a world awaywo exchange keys with a server and prevents other people follow interfering other than DoS attacks. >As we all learned in WWII, a code is better than encryption when you need complex PKI to achieve encryption I was never in WWII and I'm not sure what you mean by code as typically that's just encryption but less formalized.
- withinboredom 3y ago
  Https works because there is a destination address that goes to a physical network card. Over the air, there is no 'routing'. Alice can intercept my transmission, then literally, just use a more powerful radio to 'talk over me' with her keys. Ergo, MITM. I worked with guys in the military who did this for a living... Radio is like being able to packet sniff (and modify) packets from anywhere.
  - jiggawatts 3y ago
    HTTPS is secure against man in the middle attacks and will protect transmissions even over radio.
    - withinboredom 3y ago
      Yes, once you form the connection it is secure. The handshake is the part that isn't secure on open airwaves. This is how 'evil middle boxes' mitm connections from corporate networks. Edit to add: yes, there are CA's to sign the bits on a network. There is no CA for the radio, only proprietary ones. These can be reverse engineered, subpoenaed, or bought by state actors. Chances are, if you're broadcasting loud enough to be heard by them, they're going to start listening.
      - uw_rob 3y ago
        I think there is some confusion here. HTTPS is secure. Even with MITM attacks. This is because the MITM will not have a valid certificate to provide authenticity for the public key returned. The reason why middle boxes in corp networks can MITM is because the the corp owns the device and has installed their own domain trust to the device. This means the MITM can return a cert and public key that your device will trust. This is because the cert returned will be signed by the installed domain trust. Another way to think about why HTTPS is secure over radio: HTTPS is at the highest level of the OSI networking model. You could do HTTPS with pen and paper and the mail if you wanted. Think about starlink! The internet today is literally going over radio waves. This is likely why there isn't progress on encrypting old fashion radios! There is no need to encrypt old fashioned radios -- you'll just use internet over radio instead if you wanted encryption. You bring a good point through. Since it's radio, anyone can jam your transmissions, but, they won't be able to spoof your intended friend if you are using https via radio.
        withinboredom 3y ago
        HTTPS is only as secure as the CA that signs the certificate. My point is, at some point you have to bootstrap the trust. That is the single most vulnerable point (and why becoming a trusted CA is quite complex and easy to lose if you mess it up)! Without the CA, HTTPS is insecure (try self-signed certs and you'll see your browser agree with me). If you try and bootstrap a CA over the radio, it is vulnerable to MITM attacks. There is absolutely nothing inherently secure about HTTPS without a secure CA.
  - thrashh 3y ago
    No, https works because we already agreed upon on one authority and one protocol and it’s called ICANN and DNS respectively. This could be done with radio too but we don’t because a typical website transfers hundreds of megabytes and the traffic involved in negotiating an encrypted connection is a drop in the bucket, whereas with most radio traffic, it would comprise a much higher percentage of all your radio traffic. Plus your average radio equipment has a tiny CPU (although this is changing) whereas your phone or desktop computer has hundreds of gigaflops to do all the encryption and decryption math that you want and then still draw a gif.
  - rokkitmensch 3y ago
    If one treats pubkeys as handles, without any of the theatrics of "real person identity", this entire branch of objections disappears.
  - ArnoVW 3y ago
    https works because you have previously agreed on a key. The key of the Certificate Authority that signs certificates. Https (or IP for that matter) does not use the physical card to authenticate. That wouldn't make sense, except for very local networks. And since IP relies on ARP for the physical network addreess, even local IP networks can suffer MITM, by way of ARP spoofing.
    - withinboredom 3y ago
      A radio "hears" only the loudest signal (due to necessary filters). A packet is directed via routes; a network interface only picks up packets on that physical route. It's the equivalent of using a directional antennae ... kinda. At the beginning of the connection, you must establish some sort of "trust" between your radio and the other radio (if you want to use encryption). Your wifi does this with a Pre-Shared Secret (PSK). Your https connection does this with CA certificates. This 'baseline trust' allows you to know the other end is who you expect it to be. With traditional radios, there's not much of that. There's just: - something you have (the radio characteristics) - something shared (past experiences/conversations) - something you are (your voice) If you don't squint that hard, that's the basis of any kind of authentication. Thus we have that covered. So, I can "authorize" myself as my person. Then I can send my keys over the air so we can have a private conversation. Here's the issue, as soon as I broadcast my keys, someone with a "louder" (technically, brighter) radio broadcasts my voice with different keys. Next, they do the same thing when you broadcast your keys. Bam, we've been MITM'd without even realizing it. So, ok, you say. Maybe we'll snail mail our keys to each other. Sure, that'll work. Yet still, even then, we'd only be able to talk to each other. At that point, why not just pick up a phone or start up a telegram chat? The weakest link in any kind of encryption is always during the key exchange. Always. Mostly because we are human... we click through warnings, get our mail stolen, misstype things, and all kinds of dumb things. My other point about code: we can agree on a dictionary. It's virtually uncrackable and fluent to have a coded conversation. For example, there's 0% chance you'd have any idea what this actual phrase from Afganistan means: "the dust is blowing in, so we'll need about 5 mins to pick up my sister and head home" spoiler: "the americans are here, so we'll need about 5 mins to set up the guns and be the rendezvous." Code is always better than encryption. Always. The issue is the "dictionary" and the fact that it can be leaked. Encryption gives better guarantees in that regard. But when you already have 'authentication and authorization' via the things I mentioned above, code does quite well...
- withinboredom 3y ago
  [flagged]
  - niij 3y ago
    I'd take it easy with the name calling. Your replies in this thread have shown a pretty fundamental misunderstanding of the OSI model, PKI, and encryption in general.
    - withinboredom 3y ago
      > Your replies in this thread have shown a pretty fundamental misunderstanding of the OSI model, PKI, and encryption in general. Hmmm. Yes, I'll take my 20 years of experience in this field and see myself out the door... I'm really sucking at explaining this to strangers on the internet.
- rootw0rm 3y ago
  Referring to Navajo code talkers I assume... https://en.m.wikipedia.org/wiki/Code_talker https://en.m.wikipedia.org/wiki/Code_talker
  - SAI_Peregrinus 3y ago
    Which is especially funny, because their communications were encrypted after they encoded them into Navajo.
    - withinboredom 3y ago
      Encryption uses math, code uses a dictionary. These communications were not “encoded” but an actual language.
      - quonn 3y ago
        That‘s an arbitrary distinction, since encryption uses a key just like „code“ uses a dictionary. In a one time pad where your key is long, how is it different from a dictionary? And in a trivial cipher the key may still encode a dictionary. Basically you are taking a subset of encryption using only substitution and calling that a code.
        withinboredom 3y ago
        Yep! You've pretty much nailed it. Cipher: exchanging letters to hide a message. Code: exchanging words/phrases to hide a message. Encryption: combining math + ciphers (sometimes code too!) to hide a message. Codes are great for real people having fluent conversations, not so great for computers. We actually use "codes" all the time, but when they're used in large groups (and not a 'secret'), we call it "jargon." "Push it to main, and I'll pull it in to my buggy branch to see if that works" will make almost no sense to anyone but a programmer who works with git and even then, only someone who's used git since everyone renamed the 'master' branch to 'main.'
    - cynwoody 3y ago
fortran77 3y ago
> In order for encryption to work, you need to exchange keys at some point. Not since 1976. https://en.wikipedia.org/wiki/Public-key_cryptography https://en.wikipedia.org/wiki/Public-key_cryptography
- withinboredom 3y ago
  You still need to exchange keys. You can't get around that. Otherwise, how do I know the public key you sent me over the radio is YOUR public key and not someone else with a more powerful radio?
  - krisoft 3y ago
    By having the key signed by someone who you trust. Which in a military typically means the central command.
    - kelnos 3y ago
      Sure, but then you need the central command's public key in order to verify that signature. How do you get that? Ultimately it boils down to you needing to bootstrap your web/chain of trust somehow. In a military it might be easier; radios would be distributed to field troops with the needed trusted keys already present. But more "public" radio? We don't have a sort of "radio CA", and there are no radios that know how to deal with such a thing. I suppose we could reuse the TLS CAs, though, and build SDRs to use it, which wouldn't rely on any particular hardware. But the point is that this just isn't set up at all.
    - Gordonjcp 3y ago
      You still need to physically meet someone you trust to exchange keys, however you slice it.
stevezsa8 3y ago
I watched some documentary where the US were monitoring enemy communications but didn't know what a specific code word was referring to. If I recall correctly, the US staged a fake transmission that one of their islands had some issue or other... and suddenly they picked up enemy broadcast with the code word in question. So then the US knew what the code word referred to.
- Y_Y 3y ago
  AF meant Midway https://www.history.navy.mil/content/dam/museums/nmas/education/Codes%20and%20Ciphers%20Activity.pdf https://www.history.navy.mil/content/dam/museums/nmas/educat... It's very easy to look these things up.
- wkat4242 3y ago
  As the other poster said, midway. Wasn't it that movie that just came out, by any chance? Because this featured in there as a plot point too.
  - stevezsa8 3y ago
    It was a Netflix WW2 documentary. Most likely "WWII in Color: Road to Victory". We switched to Disney+ at the start of the year, otherwise I'd have been able to confirm the show.
deleted 3y ago
[deleted]

charcircuit 3y ago

You are ignoring HTTPS allows people half a world awaywo exchange keys with a server and prevents other people follow interfering other than DoS attacks. >As we all learned in WWII, a code is better than encryption when you need complex PKI to achieve encryption I was never in WWII and I'm not sure what you mean by code as typically that's just encryption but less formalized.

withinboredom 3y ago
Https works because there is a destination address that goes to a physical network card. Over the air, there is no 'routing'. Alice can intercept my transmission, then literally, just use a more powerful radio to 'talk over me' with her keys. Ergo, MITM. I worked with guys in the military who did this for a living... Radio is like being able to packet sniff (and modify) packets from anywhere.
- jiggawatts 3y ago
  HTTPS is secure against man in the middle attacks and will protect transmissions even over radio.
  - withinboredom 3y ago
    Yes, once you form the connection it is secure. The handshake is the part that isn't secure on open airwaves. This is how 'evil middle boxes' mitm connections from corporate networks. Edit to add: yes, there are CA's to sign the bits on a network. There is no CA for the radio, only proprietary ones. These can be reverse engineered, subpoenaed, or bought by state actors. Chances are, if you're broadcasting loud enough to be heard by them, they're going to start listening.
    - uw_rob 3y ago
      I think there is some confusion here. HTTPS is secure. Even with MITM attacks. This is because the MITM will not have a valid certificate to provide authenticity for the public key returned. The reason why middle boxes in corp networks can MITM is because the the corp owns the device and has installed their own domain trust to the device. This means the MITM can return a cert and public key that your device will trust. This is because the cert returned will be signed by the installed domain trust. Another way to think about why HTTPS is secure over radio: HTTPS is at the highest level of the OSI networking model. You could do HTTPS with pen and paper and the mail if you wanted. Think about starlink! The internet today is literally going over radio waves. This is likely why there isn't progress on encrypting old fashion radios! There is no need to encrypt old fashioned radios -- you'll just use internet over radio instead if you wanted encryption. You bring a good point through. Since it's radio, anyone can jam your transmissions, but, they won't be able to spoof your intended friend if you are using https via radio.
      - withinboredom 3y ago
        HTTPS is only as secure as the CA that signs the certificate. My point is, at some point you have to bootstrap the trust. That is the single most vulnerable point (and why becoming a trusted CA is quite complex and easy to lose if you mess it up)! Without the CA, HTTPS is insecure (try self-signed certs and you'll see your browser agree with me). If you try and bootstrap a CA over the radio, it is vulnerable to MITM attacks. There is absolutely nothing inherently secure about HTTPS without a secure CA.
- thrashh 3y ago
  No, https works because we already agreed upon on one authority and one protocol and it’s called ICANN and DNS respectively. This could be done with radio too but we don’t because a typical website transfers hundreds of megabytes and the traffic involved in negotiating an encrypted connection is a drop in the bucket, whereas with most radio traffic, it would comprise a much higher percentage of all your radio traffic. Plus your average radio equipment has a tiny CPU (although this is changing) whereas your phone or desktop computer has hundreds of gigaflops to do all the encryption and decryption math that you want and then still draw a gif.
- rokkitmensch 3y ago
  If one treats pubkeys as handles, without any of the theatrics of "real person identity", this entire branch of objections disappears.
- ArnoVW 3y ago
  https works because you have previously agreed on a key. The key of the Certificate Authority that signs certificates. Https (or IP for that matter) does not use the physical card to authenticate. That wouldn't make sense, except for very local networks. And since IP relies on ARP for the physical network addreess, even local IP networks can suffer MITM, by way of ARP spoofing.
  - withinboredom 3y ago
    A radio "hears" only the loudest signal (due to necessary filters). A packet is directed via routes; a network interface only picks up packets on that physical route. It's the equivalent of using a directional antennae ... kinda. At the beginning of the connection, you must establish some sort of "trust" between your radio and the other radio (if you want to use encryption). Your wifi does this with a Pre-Shared Secret (PSK). Your https connection does this with CA certificates. This 'baseline trust' allows you to know the other end is who you expect it to be. With traditional radios, there's not much of that. There's just: - something you have (the radio characteristics) - something shared (past experiences/conversations) - something you are (your voice) If you don't squint that hard, that's the basis of any kind of authentication. Thus we have that covered. So, I can "authorize" myself as my person. Then I can send my keys over the air so we can have a private conversation. Here's the issue, as soon as I broadcast my keys, someone with a "louder" (technically, brighter) radio broadcasts my voice with different keys. Next, they do the same thing when you broadcast your keys. Bam, we've been MITM'd without even realizing it. So, ok, you say. Maybe we'll snail mail our keys to each other. Sure, that'll work. Yet still, even then, we'd only be able to talk to each other. At that point, why not just pick up a phone or start up a telegram chat? The weakest link in any kind of encryption is always during the key exchange. Always. Mostly because we are human... we click through warnings, get our mail stolen, misstype things, and all kinds of dumb things. My other point about code: we can agree on a dictionary. It's virtually uncrackable and fluent to have a coded conversation. For example, there's 0% chance you'd have any idea what this actual phrase from Afganistan means: "the dust is blowing in, so we'll need about 5 mins to pick up my sister and head home" spoiler: "the americans are here, so we'll need about 5 mins to set up the guns and be the rendezvous." Code is always better than encryption. Always. The issue is the "dictionary" and the fact that it can be leaked. Encryption gives better guarantees in that regard. But when you already have 'authentication and authorization' via the things I mentioned above, code does quite well...
withinboredom 3y ago
[flagged]
- niij 3y ago
  I'd take it easy with the name calling. Your replies in this thread have shown a pretty fundamental misunderstanding of the OSI model, PKI, and encryption in general.
  - withinboredom 3y ago
    > Your replies in this thread have shown a pretty fundamental misunderstanding of the OSI model, PKI, and encryption in general. Hmmm. Yes, I'll take my 20 years of experience in this field and see myself out the door... I'm really sucking at explaining this to strangers on the internet.
rootw0rm 3y ago
Referring to Navajo code talkers I assume... https://en.m.wikipedia.org/wiki/Code_talker https://en.m.wikipedia.org/wiki/Code_talker
- SAI_Peregrinus 3y ago
  Which is especially funny, because their communications were encrypted after they encoded them into Navajo.
  - withinboredom 3y ago
    Encryption uses math, code uses a dictionary. These communications were not “encoded” but an actual language.
    - quonn 3y ago
      That‘s an arbitrary distinction, since encryption uses a key just like „code“ uses a dictionary. In a one time pad where your key is long, how is it different from a dictionary? And in a trivial cipher the key may still encode a dictionary. Basically you are taking a subset of encryption using only substitution and calling that a code.
      - withinboredom 3y ago
        Yep! You've pretty much nailed it. Cipher: exchanging letters to hide a message. Code: exchanging words/phrases to hide a message. Encryption: combining math + ciphers (sometimes code too!) to hide a message. Codes are great for real people having fluent conversations, not so great for computers. We actually use "codes" all the time, but when they're used in large groups (and not a 'secret'), we call it "jargon." "Push it to main, and I'll pull it in to my buggy branch to see if that works" will make almost no sense to anyone but a programmer who works with git and even then, only someone who's used git since everyone renamed the 'master' branch to 'main.'
  - cynwoody 3y ago

fortran77 3y ago

> In order for encryption to work, you need to exchange keys at some point. Not since 1976. https://en.wikipedia.org/wiki/Public-key_cryptography https://en.wikipedia.org/wiki/Public-key_cryptography

withinboredom 3y ago
You still need to exchange keys. You can't get around that. Otherwise, how do I know the public key you sent me over the radio is YOUR public key and not someone else with a more powerful radio?
- krisoft 3y ago
  By having the key signed by someone who you trust. Which in a military typically means the central command.
  - kelnos 3y ago
    Sure, but then you need the central command's public key in order to verify that signature. How do you get that? Ultimately it boils down to you needing to bootstrap your web/chain of trust somehow. In a military it might be easier; radios would be distributed to field troops with the needed trusted keys already present. But more "public" radio? We don't have a sort of "radio CA", and there are no radios that know how to deal with such a thing. I suppose we could reuse the TLS CAs, though, and build SDRs to use it, which wouldn't rely on any particular hardware. But the point is that this just isn't set up at all.
  - Gordonjcp 3y ago
    You still need to physically meet someone you trust to exchange keys, however you slice it.

stevezsa8 3y ago

I watched some documentary where the US were monitoring enemy communications but didn't know what a specific code word was referring to. If I recall correctly, the US staged a fake transmission that one of their islands had some issue or other... and suddenly they picked up enemy broadcast with the code word in question. So then the US knew what the code word referred to.

Y_Y 3y ago
AF meant Midway https://www.history.navy.mil/content/dam/museums/nmas/education/Codes%20and%20Ciphers%20Activity.pdf https://www.history.navy.mil/content/dam/museums/nmas/educat... It's very easy to look these things up.
wkat4242 3y ago
As the other poster said, midway. Wasn't it that movie that just came out, by any chance? Because this featured in there as a plot point too.
- stevezsa8 3y ago
  It was a Netflix WW2 documentary. Most likely "WWII in Color: Road to Victory". We switched to Disney+ at the start of the year, otherwise I'd have been able to confirm the show.

deleted 3y ago

[deleted]