6 ms·

But how do you know that the outcome you have is the right one? It's text. It's not something formatted. If I encrypted a JSON string, gave it to you, you can

But how do you know that the outcome you have is the right one? It's text. It's not something formatted. If I encrypted a JSON string, gave it to you, you can brute-force all day trying to parse the output as a JSON string. If it works, you probably have it right. But here? Because of how the Engima machine works you still get an output. And since we don't need to decode this output (like JSON to an actual JavaScript Object) we don't have that many ways of validating the output. It's German from 1945. Abbreviations, different (older) spelling, spelling mistakes, ... all make it really hard to distinguish real output from incorrect output.

tehbeard 3y ago
As mentioned elsewhere, a signature of enigma ciphertext is that a letter can never encode as itself. This gives you some crude form of error checking. The rest of it as you mentioned makes it difficult to determine, data mining the possible results for common abbreviations from other plaintext could narrow.It down.
- sebzim4500 3y ago
  That doesn't help at all because every key you try will lead to a candidate plaintext with no letters in common with the ciphertext.
RichieAHB 3y ago
I’m not sure being German or from 1945 has much to do with this. I’d think if I had some candidate plaintext that looked German and where a letter didn’t map to itself it’s likely to be right. Sure, you could argue that it’s not quite as unambiguous as JSON but, in the realm of all possible plaintext, I’d say JSON and 1945 German aren’t too far apart in terms of likelihood of getting a false positive on a string of non-trivial size. If you want a bit more certainty you could just try it on another string (which is the next step in the process either way), and then another. At least to me the constraints of “German and a char doesn’t map to itself” seem like pretty limiting factors here.
- dylan604 3y ago
  It would be awesome if there's a message that when decoded incorrectly said "Drink your Ovaltine", but when decoded correctly was a different message
  - RichieAHB 3y ago
    Remind me of “Deniable Encryption”[1], where a single encrypted input decrypts to multiple plausible plain texts (including the real one, obviously) so that, if, for example, you were caught and asked to decrypt it, you can decrypt to the non-incriminating version. [1] https://en.m.wikipedia.org/wiki/Deniable_encryption https://en.m.wikipedia.org/wiki/Deniable_encryption
- DSMan195276 3y ago
  I don't think it's as simple as you're assuming. The "char doesn't map to itself" is a feature of the hardware design, there's no such thing as a key that allows that to happen so it doesn't reduce your search space. But additionally, the messages were extremely terse (~250 character limit), had no punctuation or spaces, and only had the 26 alphabet characters. Depending on the message in question it already doesn't look much like German, and the ones writing these messages also purposely vary their spelling/names/wording to make it harder to analyze. IMO the chance of finding "potentially plausible messages" seems higher than you'd want if you're starting with zero idea what the plaintext is supposed to be.
  - wkat4242 3y ago
    Why was there a character limit? I always thought the only limit was the slow transmission speed of morse messages.
    - DSMan195276 3y ago
      From what I have read it was specifically to make it harder to decrypt the messages :D Longer messages are easier to analyze.
  - 3y ago
tasty_freeze 3y ago
Although all keys generate some string of letters and numbers, the right key will produce a message with reasonable letter frequencies and of course with legible words. For English, about 13% of letters are "e", so if the frequency is too far off that it is probably not the right key; likewise, if 13% of the letters are "z" it is also not likely to be the right key. By applying frequency checks to the most and least common letters it should be a fairly strong filter for plausible keys.
- jcranmer 3y ago
  This is what the successful decrypt of another Enigma message looks like: UUUVIRSIBENNULEINSYNACHRXUUUSTUETZPUNKTLUEBECKVVVCHEFVIERXUUUFLOTTXXMITUUUVIERSIBENNULZWOUNDUUUVIERSIBENNULDREIZURFLENDERWERFTLUEBECKGEHENXFONDORTFOLGTWEITERESX There's enough code language being used in these messages that frequency analysis is not going to a major help (especially since it doesn't work well on very short texts anyways).
  - Normal_gaussian 3y ago
    Was frequency analysis based on already decoded messages used?
  - wkat4242 3y ago
    Well the triple U (not sure why they use that) and the spelling of the letters is simple enough to check for that I guess. From what I can gather this says something like: To U4701 Sync message, Lubeck base, From commander 4th U-boat fleet, go with U4702 U4703 to Flender Shipyard Lubeck, more to follow It's less gibberish than it looks like at first. They really shot themselves in the foot by not having numbers on the enigma system, this would have really made messages much shorter because they had to write them all out. There's so much specific jargon in there that would make it really easy to detect a correct message IMO. Just make a simple list of very common words and tally up. Indeed frequency analysis wouldn't work though but it's still pretty possible IMO.
    - copperbrick25 3y ago
jonathankoren 3y ago
You validate the same way they did back in the 30s and 40s. You use Cribs. https://en.wikipedia.org/wiki/Known-plaintext_attack https://en.wikipedia.org/wiki/Known-plaintext_attack
cryptonector 3y ago
Worse than that: there's no authentication tag!
sam0x17 3y ago
When it says something funny and german
richdougherty 3y ago
I mean I'd use known text of other messages to get some likely statistical properties of the message. I'd make a fast approx check for some of these properties that can run during brute force, then feed anything that passes that check to a better check, then finally to a human (maybe nowadays put an LLM before the human stage). There's a chance to miss the translation if it doesn't match other messages but this seems like a decent approach.

tehbeard 3y ago

As mentioned elsewhere, a signature of enigma ciphertext is that a letter can never encode as itself. This gives you some crude form of error checking. The rest of it as you mentioned makes it difficult to determine, data mining the possible results for common abbreviations from other plaintext could narrow.It down.

sebzim4500 3y ago
That doesn't help at all because every key you try will lead to a candidate plaintext with no letters in common with the ciphertext.

RichieAHB 3y ago

I’m not sure being German or from 1945 has much to do with this. I’d think if I had some candidate plaintext that looked German and where a letter didn’t map to itself it’s likely to be right. Sure, you could argue that it’s not quite as unambiguous as JSON but, in the realm of all possible plaintext, I’d say JSON and 1945 German aren’t too far apart in terms of likelihood of getting a false positive on a string of non-trivial size. If you want a bit more certainty you could just try it on another string (which is the next step in the process either way), and then another. At least to me the constraints of “German and a char doesn’t map to itself” seem like pretty limiting factors here.

dylan604 3y ago
It would be awesome if there's a message that when decoded incorrectly said "Drink your Ovaltine", but when decoded correctly was a different message
- RichieAHB 3y ago
  Remind me of “Deniable Encryption”[1], where a single encrypted input decrypts to multiple plausible plain texts (including the real one, obviously) so that, if, for example, you were caught and asked to decrypt it, you can decrypt to the non-incriminating version. [1] https://en.m.wikipedia.org/wiki/Deniable_encryption https://en.m.wikipedia.org/wiki/Deniable_encryption
DSMan195276 3y ago
I don't think it's as simple as you're assuming. The "char doesn't map to itself" is a feature of the hardware design, there's no such thing as a key that allows that to happen so it doesn't reduce your search space. But additionally, the messages were extremely terse (~250 character limit), had no punctuation or spaces, and only had the 26 alphabet characters. Depending on the message in question it already doesn't look much like German, and the ones writing these messages also purposely vary their spelling/names/wording to make it harder to analyze. IMO the chance of finding "potentially plausible messages" seems higher than you'd want if you're starting with zero idea what the plaintext is supposed to be.
- wkat4242 3y ago
  Why was there a character limit? I always thought the only limit was the slow transmission speed of morse messages.
  - DSMan195276 3y ago
    From what I have read it was specifically to make it harder to decrypt the messages :D Longer messages are easier to analyze.
- 3y ago

tasty_freeze 3y ago

Although all keys generate some string of letters and numbers, the right key will produce a message with reasonable letter frequencies and of course with legible words. For English, about 13% of letters are "e", so if the frequency is too far off that it is probably not the right key; likewise, if 13% of the letters are "z" it is also not likely to be the right key. By applying frequency checks to the most and least common letters it should be a fairly strong filter for plausible keys.

jcranmer 3y ago
This is what the successful decrypt of another Enigma message looks like: UUUVIRSIBENNULEINSYNACHRXUUUSTUETZPUNKTLUEBECKVVVCHEFVIERXUUUFLOTTXXMITUUUVIERSIBENNULZWOUNDUUUVIERSIBENNULDREIZURFLENDERWERFTLUEBECKGEHENXFONDORTFOLGTWEITERESX There's enough code language being used in these messages that frequency analysis is not going to a major help (especially since it doesn't work well on very short texts anyways).
- Normal_gaussian 3y ago
  Was frequency analysis based on already decoded messages used?
- wkat4242 3y ago
  Well the triple U (not sure why they use that) and the spelling of the letters is simple enough to check for that I guess. From what I can gather this says something like: To U4701 Sync message, Lubeck base, From commander 4th U-boat fleet, go with U4702 U4703 to Flender Shipyard Lubeck, more to follow It's less gibberish than it looks like at first. They really shot themselves in the foot by not having numbers on the enigma system, this would have really made messages much shorter because they had to write them all out. There's so much specific jargon in there that would make it really easy to detect a correct message IMO. Just make a simple list of very common words and tally up. Indeed frequency analysis wouldn't work though but it's still pretty possible IMO.
  - copperbrick25 3y ago

jonathankoren 3y ago

You validate the same way they did back in the 30s and 40s. You use Cribs. https://en.wikipedia.org/wiki/Known-plaintext_attack https://en.wikipedia.org/wiki/Known-plaintext_attack

cryptonector 3y ago

Worse than that: there's no authentication tag!

sam0x17 3y ago

When it says something funny and german

richdougherty 3y ago

I mean I'd use known text of other messages to get some likely statistical properties of the message. I'd make a fast approx check for some of these properties that can run during brute force, then feed anything that passes that check to a better check, then finally to a human (maybe nowadays put an LLM before the human stage). There's a chance to miss the translation if it doesn't match other messages but this seems like a decent approach.