Hacker News Reader

Comment by bmurray7jhu | Hacker News Reader

Matt Blaze's analysis of the flawed OTPs used by Cuban numbers stations: https://www.mattblaze.org/blog/neinnines/

Trying to understand why the Nein Nines could happen. My first thought for a “fill” algorithm would be to just fill with zeros, and hence read out the pad, since it is going to be used up anyway. But I suppose that’s bad since if it did accidentally get re-used then that cyphertext would be fully compromised (versus say having two cyphertexts from the same pad to run a frequency analysis against). Another fill would be to add random data and pad against it, but then if your random data is flawed, you may still leak the OTP. So, I guess the actual algorithm must be derived from the OTP, but not padded with it? (Since if it were padded, there is no way to avoid a 9 digit). It just seems like zero or semi-random fill seems safer…

> My first thought for a “fill” algorithm would be to just fill with zeros, and hence read out the pad, since it is going to be used up anyway.

That also would use up the pad when there are no messages, requiring some secure way to get a new pad to the operatives when their existing pad is consumed. This is difficult enough (secure delivery of new pad) that it is unlikely that spy-HQ wishes to consume pad data for fill.

> But I suppose that’s bad since if it did accidentally get re-used then that cyphertext would be fully compromised

Yes, if they reused any part of any pad for more than one single message, they have compromised (and revealed) the contents of the reused pad messages. This is the other difficulty with OTP's. The OTP data must never be reused. Which is alo why spy-HQ would not want to use it (the OTP) up for the fill, because to avoid reuse then they have to get new pad material to the operatives in some secure way.

> So, I guess the actual algorithm must be derived from the OTP, but not padded with it?

The 'implication' of the article is that the fill is just random data (without using up any pad material). Possibly with the appropriate headers in place so that it looks indistinguishable from a read message in the same slot.

The further implication is that the Cuban station did something essentially like this:

    for (count=0; count<20; count++) {
        send(int(rand()*9));
    }

With a rand() implementation that returned a number from zero to 1.0 exclusive of 1.0 and an int() implementation that merely truncated any fraction from the multiplication. With the result that 9 is never sent.

Even if it returned 1.0, that would still leave 9 being produced a _very_ small amount of the time (like 1 in 18 quintillion assuming the full range of a float mapped from 0.0-1.0). Even at 20 characters, 24 times a day, year round, you’d only see a 9 pop up once in every 100 trillion years or so.

Lots of ways to mess that up (`rand() % 9`?). I’m more surprised that nobody noticed for so long. It’s not like this was some subtle cryptographic bug that would have required deep analysis to catch… “you had one job”, and just glancing at the output was, evidentially, enough for a lot of other people to catch on.

that's kind of the beauty of the system. we actually have no way of knowing if it was just random fill.

maybe they were just random digits with an off by one error or some other problem with the symbol set missing one symbol.

or maybe the supposed fill messages can actually be cryptographically confirmed as authentic fill messages via some clever scheme (that the implementation of turned out to be buggy).

or maybe someone from some sort of field operations chain of command just slammed the table and said "my people are tired of trying to decrypt fill messages, i don't care, just cut the nines out so the field agents know if there's a message."

that's what makes numbers stations fun. :)

It says in the article me that the spies would decrypt and verify a header before moving on to the main message. Presumably the fill messages would simply not have a valid header, or it would have a special header that indicated it was a fill message.

According to the Matt Blaze article, the Radio Havana numbers station sends 3 messages per hour. At the start of the transmission, three 5-digit message identifiers are sent for the 3 messages to be transmitted.

My guess is there's some cryptographic structure to these indicators that tells agents if the messages are for them, so they can shut down their listening early if none of the three messages are for them. If it were otherwise, I would expect each indicator group to be before (or inserted at a secret agent-specific offset within each message) each message. If you listen to the mp3 recording linked from Matt's article, you'll notice that the three indicator groups are repeated before the actual messages begin. Presumably the repetition is to guard against the indicator groups being garbled, since if the indicator group gets garbled, the whole message is garbled. On the other hand, a garbled regular message group would only result in a few characters of the plaintext being garbled.

Placing the indicator groups at constant (and secret) per-agent offsets within the messages has been known since at least WWII. In the case of an OTP, having a secret offset of the indicator group makes it harder to detect if the fatal error of pad reuse has been made. In the case of other ciphers, making the location of the indicator group secret also complicates cryptanalysis.

It wouldn't make sense to separate out the indicator groups like that unless it provides some operational advantage to offset the small cryptoanalytic toehold provided by highlighting the indicator groups. Allowing agents to shut down their listening early is the most obvious advantage I can think of.

The simplest cryptographic structure (and devoid of bias if the OTP is devoid of bias) would be to simply have the indicator group be the first 5-digit group for the next page in the OTP. The agent would need to check the next several pages of their OTP to verify they hadn't missed any messages. Encrypted headers within the messages could be used to handle the rare cases of collisions across agents, rather than introduce extra stucture (weaknesses!) to prevent any two agents from ever having duplicate indicator groups across their next few pages of OTP material.

Of course, it is also possible that these repeated indicator groups at the start of the transmission are just decoys and the real indicator groups are somehow hidden within the messages in some way that provides redundancy without revealing which groups are the indicator groups. Maybe the first three groups of the OTP page are placed at 3 constant offsets within the message or something.

But, my guess is that these repeated indicator groups at the start of the transmission really are there to let the agents know that they can shut down their listening early when there are no messages for them.

There's no way they have time to listen to Radio Havana every 20 minutes though.

Much more likely is that everybody has a time slot during which he's supposed to listen.

I didn't mean to imply that. What I meant to imply is that at the beginning of their appointed hour, they tune in to see if they have a message that day/week.

That seems reasonable.

However don't you think your own explanation of improving security against accidental key reuse could be the explanation, with the repetition being there only for that purpose?

The extra protection against key reuse requires the attacker to be uncertain of which group is the indicator group. Placing indicator groups at the beginning of the broadcast would prevent that, but would allow agents to better avoid detection by minimizing the time they need to listen.

Ah, yes.

And his recording of the Cuban numbers station, if you want to hear what these sound like: https://www.mattblaze.org/private/17435khz-200810041700.mp3

Here's a sample of the referenced "Linconshire Poacher": https://priyom.org/media/247818/e3.mp3

For a more thorough description of OTP see https://cryptosmith.com/2007/06/09/one-time-pads/

Reply on news.ycombinator.com