4 ms·

Encryption takes time, and energy. I suspect they are trying to avoid adding latency to anything that’s not super sensitive.

• mikepurvis 6y ago
  Those final gasps of data while a vehicle is breaking up could be critical for understanding what went wrong with it. I can definitely see how missing out on the final milliseconds of telemetry because some encryption buffer wasn't full enough to trigger a frame or something would be unacceptable.
  • myself248 6y ago
    I think this is the true reason that telemetry is as raw as possible. The happy-path telemetry tells you very little you didn't already know, but when something goes wrong, those last few bits before the transmitter went silent can make or break your analysis. Sitting on bits until you have enough to run a block through the cipher seems like a terrible idea, even if that's only a few microseconds. Things happen mighty fast when you're trying to get data that might represent the structural collapse or propagation of a blast wave through the body of a hypersonic vehicle.
  • vardump 6y ago
    You don't need any buffering if you pick your encryption mode correctly. That is, use a stream cipher.
    • mikepurvis 6y ago
      How much would that affect the ability to recover a partially-corrupted stream, though? I feel like that's part of this too— where the last few seconds might have an increasing amount of the content scrambled, and encryption would render that completely unusable, whereas having it in plaintext would still permit some degree of inference about the fragments you do have.
      • vardump 6y ago
        It would not affect at all. Flipped bits / transmit errors have no avalanche effect, unless the bit was flipped in the encryption module.
        • mikepurvis 6y ago
          What if you have gaps in your stream with uncertain length, though? Based on quick read about stream ciphers, it seems like the alignment of the key and data is pretty critical.
          • vardump 6y ago
            Might be some truth here. Although at this point automatically interpreting plain text data would fail as well. In both cases, you could add separating symbols in the raw data stream. Also, timing should help here. Sure there can be gaps, but at a given data rate the receiving end should be able to compensate for it, as long as velocity doesn't have large unexpected changes (doppler). Even then it should be decodable afterwards. There are a lot of ways you can compensate for any of these issues. That said, of course plain text is going to be the easiest option for a human to decode when everything else fails.
  • Rebelgecko 6y ago
    I think this is a very plausible reason. After a F9 blew up in 2016 or so, the NASA accident review even threw a little bit of shade because the telemetry right before the explosion was lost to bufferbloat