HN Reader

Interesting. I liked the explanations in the accepted answer. This rule especially,“Never repeat in the clear the identical text of a message once sent in cryptographic form, or repeat in cryptographic form the text of a message once sent in the clear.”

As a child I learned about codes from a library book. Fascinated with one-time pads, I convinced a friend to try a correspondence. We exchanged a few messages, and then got bored, because the juice wasn’t worth the squeeze.

Which makes me wonder about people who work in secrets. Encrypted communications seem opposite of scientific communications. Secrets peeps seem prolly aligned to politics.

I forget who told me this story, but at some point the British tried a crazy known-plaintext attack by planting handwritten notes in dead German soldiers’ pockets that contained an “important message” to be sent, and then in the following days they would attempt to decrypt enigma communications against the known plaintext.

> Never repeat in the clear the identical text of a message once sent in cryptographic form, or repeat in cryptographic form the text of a message once sent in the clear

And (more or less) that’s how the Enigma was cracked. Turns out starting weather report with ‘weather’ every single time is not a good idea.

ETA: Note that I appear to have been mistaken about the connection to ENIAC.

Note that it is equally dangerous to send paraphrased messages using the same key (which is called sending messages "in depth"). This was used to crack the Lorenz ("Tunny") cipher. Interestingly Bletchley Park hadn't gotten their hands on a Lorenz machine, they cracked it based on speculation. And it lead to the development of the first tube computer, Collosus (which influenced the ENIAC). Nowadays we use nonces to avoid sending messages in depth, but nonce reuse can be similarly disastrous for systems like AES-GCM. For example there have been Bitcoin hardware wallets that reused nonces, allowing the private key to be extracted & the Bitcoin stolen. (To be clear, cryptocurrencies and AES-GCM are completely different systems that have this one property in common.)

https://en.wikipedia.org/wiki/Cryptanalysis_of_the_Lorenz_ci...

https://www.youtube.com/watch?v=Ou_9ntYRzzw [Computerphile, 16m]

As an aside does anyone know why it's called "in depth?" I'm guessing that it's related to Bletchley Park's penchant for naming things after fish? But possibly also their techniques that involved arranging messages together and sliding a stencil over them to visually spot patterns (so they're sort of overlayed)? I tried some casual searching but it's a very generic phrase and so difficult to search. It's defined in the The 1944 Bletchley Park Cryptographic Dictionary but it doesn't give an etymology.

https://www.codesandciphers.org.uk/documents/cryptdict/crypt... [Page 28]

The term to google for more information about this would be Known plaintext attack.

For people interested in these kinds of things, there is a very interesting military manual on the internet archives which goes though all the various pre computer pen and paper ciphers and how to crack them.

1. https://archive.org/details/Fm3440.2BasicCryptAnalysis/mode/...

This is a familiar concept from reading about WW2 spy stuff (Between Silk and Cyanide, for example, which I highly recommend). But what REALLY intrigues me is the typeface of the letter with its upper-case 'E' used in place of 'e'. What's up with that?

The repeating of the message is how the Allies initially broke the Geheimskreiber a much more secure encryption machine to Enigma that used XOR and rotors:

https://en.wikipedia.org/wiki/Siemens_and_Halske_T52

Hasn’t known invariants been used to break modern encryption in TLs, etc? Like a SSH packet will always contain some known info, etc.

I was able to find the 2 earlier manuals mentioned:

RadioNerds-TM 11-485 (PDF) (33.22 MB) 4

Internet Archive-US Army Cryptography Manuals Collection (see "TM_11-485.pdf")

https://radionerds.com/index.php/File:TM_11-485.pdf

https://archive.org/details/US-Army-Cryptography-Manuals

Tangentially related — sending everyone in a company a slightly different document can help catch the person leaking confidential documents to the press.

Does this also apply if someone were to do the following: Receive encrypted transmission -> unencrypt it -> need to pass it on, so re-encrypt it and pass it on?

I would imagine that the paraphrasing wouldn't be necessary in this case because it isn't quite as useful to compare two encrypted versions of the text versus an encrypted version and an unencrypted version (also I feel like there is some risk of a game of 'telephone' in that the meaning would change bit by bit to the point of having a different meaning over time, even if not intentionally)

> In this process, deletion rather than expansion of the wording of the message is preferable, because if an ordinary message is paraphrased simply by expanding it along its original lines, an expert can easily reduce the paraphrased message to its lowest terms, and the resultant wording will be practically the original message.

This bit has me perplexed. If you had a single message that you wanted to send multiple times in different forms, wouldn't compressing the message exponentially limit possible variation whereas expanding it would exponentially increase it? If you had to send the same message more than a couple of times I'd expect to see accidental duplicates pretty quickly if everyone had been instructed to reduce the message size.

I guess the idea is that if the message has been reduced in two different ways then you have to have removed some information about the original, whereas that's not a guarantee with two different expansions. But what I don't understand is that even if you have a pair of messages, decrypt one, and manage to reconstruct the original message, isn't the other still encrypted expansion still different to the original message? How does that help you decrypt the second one if you don't know which parts of the encrypted message represent the differences?

Knowing the original plaintext is a big leg up in cracking encryption.

So it would make sense for the first message in a chain to be very verbose and repetitive to make it easier to modify down the chain. Bureaucrats must've had fun writting those.

Ironically, stating this at the beginning of telegram would precisely cause what it seeks to prevent (vulnerability to known plaintext attacks).

Which makes me wonder: how many permutations of this rule could be conceived (and needed) that on the one hand would keep the point clear to the receiver, but on the other hand prevent such attacks?

In any case the best option is to not have (to repeat) this rule inside messages.

First thought that came into my mind, when I read this article header, was regarding the Chat Control and the Telegram IM. Then I saw the history.stackexchange...

And the revolution is: It's really nice that nowadays we have telegrams that are more safe that they were during WW2 for example even with the military infrastructure available back then...

Or maybe we did have?

“Close” meant secret in the 1940s. A “close secret” was next to “top secret” classification.

See also the use of the word “close” in literature, eg The Lord of the Rings “Gandalf is closer that ever”.

To keep it close or to hold it close meant to keep it secret.

As close to the original as possible not using the same phrasing? Obviously?

What an interesting find!

Not that this specific quirk is covered in the novel, but a reading of Neal Stephenson's Cryptonomicon would certainly help make one understand the kind of necessary paranoia that would lead to this kind of (important!) protective measure.

Lowercase E is unusual in the text. Is it a special teletype font?

This reminds me of similar discussions we've been having about this topic. The key challenge I see is implementation at scale.

Known-plaintext attacks aside, if you're going to compress text, it must be done before encryption.

I don't know if compression offers much protection against plaintext attacks.

This also makes me wonder how helpful AI is in such situations. AI is essential an extremely effective, lossy, compression algorithm.

How come this isnt a problem with modern cryptography? What did we invent?

How is this solved in modern cryptography?

I guess CBC and IVs (or similar) weren't invented yet?

Well, that's one way to make it CPA-secure

LLMs would be amazing for this

I didn’t know that. I read somewhere that they kept reusing expressions, and even the weather updates kicked off with the same words each time

I was trained with regards to realtime control systems to put salt in the messages to reduce repetition. Many systems just repeat a status or number from which you could more easily get the keys. Never knew if it was a real concern or not. Interesting to see from the post and comments how old a concept this is. With today’s encryption is this still a concern?