First Cryptography Puzzle

Question

When adam and eve sinned,
apple was the key.
Lies of the Serpent,
they both believed.

Alternate:
56 108 87 97 119 53 97 43
57 49 68 105 66 51 121 115
84 54 120 51 81 65 61 61

I'm looking for just one word.

Answer 1

I believe the word you're looking for is

life.

OK, so how did I figure that out? Well, let's start with the obvious outer layer first:

The numbers are ASCII code, and work out to the string 8lWaw5a+91DiB3ysT6x3QA==. This in turn is obviously Base64-encoded, but decoding it just gives 16 bytes of seemingly random, mostly non-ASCII data.

Now, since this is a crypto puzzle, and since your little verse happens to mention

Serpent, the name of a block cipher that operates on 16-byte blocks, it stands to reason that the 16 random-looking bytes are probably encrypted with that cipher.

Of course, we need to know the key to have any hope of decoding that, but

it says right there in the verse that "apple is the key". Of course, a proper Serpent key should be either 16, 24 or 32 bytes long, whereas "apple" is only five bytes. But I decided to enter it into an online crypto decoder anyway, just to see what happens, and what do you know? It worked.

In particular, while I'm still not 100% sure how that website actually expands too-short keys to the expected length, just typing in apple as the key and 8lWaw5a+91DiB3ysT6x3QA== as the Base64-encoded ciphertext, and selecting Serpent in ECB mode as the cipher, yields (what looks like) the plaintext Z_X^j^YF00000.

This still isn't exactly readable, but it's also definitely not the kind of unprintable pseudorandom line noise you'd expect to get from an incorrect decryption. At this point, I thought that

the "Alternate" keyword might be a (quite obscure) hint that the remaining layer could be a simple XOR cipher. And besides, that's the kind of thing that's generally worth testing anyway.

Since the Serpent output ended in a string of zeroes, I figure that the ASCII code for "0" (hex 0x30) might be worth trying. And what do you know, XORing the other bytes with 0x30 yields the readable ASCII string johnZniv.

At this point, however, I was kind of stumped for a while:

From the vaguely biblical theme of the verse, I guessed that "john" and "niv" might be references to the Book of John and, specifically, to the New International Version of the Bible, but what to make of the "Z"? Sure, it could stand for the number 26, but there are only 21 chapters in John, and in any case, that would hardly be enough to specify a single word. For a while, I even considered the possibility that the "Z" might be just a word separator, and that the solution might be "God", but you'd hardly need to specify the NIV for that.

However, eventually I realized that I'd missed something:

Namely, the plaintext output from the decryptor website actually contained three invisible control characters between Z_X^ and j^YF00000. I should've actually noticed that sooner, both from the fact that Serpent ECB mode plaintext is always a multiple of 16 bytes long, and also from the fact that my shell freaked out when I tried to copy-paste the plaintext into it. But they were invisible both on the page and in Chrome's DOM inspector, so I didn't actually spot them before I decided to eavesdrop on the actual Ajax request between the website and the server using Chrome's developer tools.

Anyway, those three invisible bytes have the ASCII values 3, 1 and 6, and XORing them with the ASCII code for "0" just turns them into the corresponding numbers. (ASCII is kind of cleverly designed that way.) So the actual plaintext, after Serpent decryption and XOR, is john316Zniv (plus five null bytes at the end).

That made a lot more sense, since

John 3:16 in the NIV has exactly 26 words:

For God so loved the world that he gave his one and only Son, that whoever believes in him shall not perish but have eternal life.

The 26th and last of those words, "life", is presumably the word you're looking for.