Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2...
by mikepurvis on Thursday March 11, 2021 @02:43PM
(#26428141)
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.
[ Parent
| on HN ]
Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2...
by vardump on Thursday March 11, 2021 @02:49PM
(#26428217)
It would not affect at all. Flipped bits / transmit errors have no avalanche effect, unless the bit was flipped in the encryption module.
Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2...
by mikepurvis on Thursday March 11, 2021 @03:27PM
(#26428608)
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.
Re:Receiving SpaceX Falcon 9 Telemetry with a HackRF and 1.2...
by vardump on Thursday March 11, 2021 @09:52PM
(#26431757)
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.