You will probably not get any (even partially) readable text out until you've figured out the decryption of the most common characters in at least two adjacent base64 positions (1 and 2, 2 and 3, or 3 and 4).
That's because the eight bits of each plaintext byte get spread across two adjacent six-bit base64 characters during the encoding process. Thus, even if you manage to correctly decrypt one of these two characters, you've still only recovered at most six of the eight bits. That leaves at least two bits whose value you'll just have to guess.
That said, the difficulty of guessing those two missing bits depends a lot on which bits happen to be missing. In particular, the ASCII codes for all letters (
z) have their highest two bits out of eight set to
01. (The third-highest bit is
0 if the letter is uppercase, and
1 if it's lowercase.) So, if your plaintext is actually ASCII text, you may be able to get some partially readable output just by trying to decrypt the last base64 character in each group of four, and just assuming that the previous character decodes into something that ends in the bits
(However, do note that the most common plaintext byte, if your plaintext is indeed ASCII text, is most likely not a letter at all, but the space character, whose ASCII code 32 =
00100000 in binary begins with
01. The same is true of numbers, line feeds and most but not all punctuation.)
More generally, you will likely want to exploit the structure of the ASCII code, which makes the highest two or three bits of each plaintext byte quite predictable. In particular, if you take any group of three eight-bit plaintext bytes (representing three ASCII characters) and split them into four groups of six bits (as base64 encoding does), you'll end up with something like this:
ABC??? ??DEF? ????GH I?????
where the bits
GHI (corresponding to the highest three bits of each plaintext byte) can be:
000 only if the byte represents a control character (of which the only ones likely to appear in plain ASCII text are the line feed =
00001010, the carriage return =
00001101, which is usually always followed by a line feed, and possibly the tabulator =
001 for spaces (
00100000), numbers (for which the next bit is always
1) and most punctuation characters;
010 for uppercase letters (and the characters
011 for lowercase letters (and the characters
Note that, in plain ASCII text, the highest bits of each eight-bit byte (i.e. bits
G above) are always
0. (That said, they could be
1 if your plaintext was actually written in some "extended ASCII" encoding like ISO Latin 1, or perhaps Unicode in the UTF-8 encoding, and contained some non-ASCII characters.)
For example, let's say that you guess that the most common byte in your plaintext is probably an ASCII space (binary
00100000), and therefore that the most common base64 character (let's arbitrarily say it's
X) at the end of each 4-character group probably encodes the bits
This means that this base64 character
X should basically never appear as the first character of a 4-character group (since that would make bit
1), and should only rarely appear as the second character (since that would make bits
000, which should be pretty rare unless the plaintext is full of line breaks). If that's indeed the case, you can be pretty confident that you've guessed correctly.
Also, you can then look at the base64 characters that precede
X in the ciphertext, and be pretty sure that they all represent six-bit base64 codes that end in
00 (since bit
G must be
0 in ASCII text anyway, and if bit
1, that would decode to the rather uncommon plaintext byte
`), which (together with their frequencies in the four different positions) should help narrow down their possible values.
Similarly, you can guess that the most common base64 character in the first position of a four-character group probably encodes the bits
001000, and that the two most common characters following it in the second position probably encode
000101 (assuming that a space is most often followed by a lowercase letter; of course, the bit sequences
000111 are also likely to be fairly common, since they arise from a space followed by an uppercase letter).
And the most common base64 character in the third position most likely represents the bits
000001 (i.e. a space followed by a letter), especially if it does not usually precede the most common fourth-group character (i.e.
X above), as that would again yield a rather unlikely plaintext sequence involving the backtick character
Also, assuming that your plaintext is indeed English ASCII text, another approach you can use to get started is to look for common repetitive sequences of base64 characters in the ciphertext, and assume that they likely correspond to common sequences of characters in English text.
For example, probably the most common five-byte sequence in English ASCII text is
the (i.e. "the" surrounded by spaces on both sides). When broken up into three-byte groups for base64 encoding, depending on where the group boundary happens to fall, you can end up with either:
? t and
he ; or
? stands for some variable byte (most likely a letter). Thus, the 4-character base64 groups encoding
he should all be pretty common, and appear with roughly the same frequency (although note that the frequencies can be skewed not only by random chance, but also by the presence of other common English words sharing the same beginning or end, such as "that", "this", "those", "these", "they", "there" and "then", as well as "he" and "she", and of course the capitalized form "The").
Furthermore, you can distinguish the base64 groups encoding these different 3-byte sequences by looking at the surrounding encrypted base64 characters. For example, the group that encodes
the should very frequently be preceded by the base64 character that encodes the lowest six bits of an ASCII space (i.e.
100000) and followed by the base64 character that encodes the highest six bits of an ASCII space (i.e.
001000). Furthermore, since they encode spaces, which are common in general, these two base64 characters should usually each be the most common ones in that position of a 4-character group.
(Of course, the group
the won't always be preceded or followed by a space, since it can also appear as part of a longer word, or possibly at the beginning or the end of a line. But the most common plaintext bytes before and after it should still be spaces.)
Similarly, the four-character group encoding
th should begin with the base64 character that encodes the first six bits of an ASCII space (and is thus rather common in the first position of a group), and should be commonly followed by a specific sequence of three base64 characters that encodes
e followed by a letter. And, correspondingly, the group that encodes
he should end in the common character that encodes the last six bits of a space, and should typically be preceded by the two base64 characters that correspond to
t at the end of the previous group.
Some other fairly common byte sequences in English text that you may want to look for include
I (i.e. "a" and "I" surrounded by spaces), both of which can be quite easy to recognize if you've already determined which base64 characters corresponding to spaces at the beginning and the end of a group, as well as
and (another fairly common three-letter word surrounded by spaces, occurring in a similar pattern as
the above, but typically sufficiently less common to be fairly easily distinguishable) and the four-byte sequences
at , etc. You'll probably want to mostly ignore the latter until you've managed to decode at least some common letters, though, since there are rather many common two-letter words in English, and their relative frequency can vary a lot based on the topic and style of writing.
*) That said, everything always depends on what the plaintext actually it. For example, the Markdown source code of this very answer is full of backticks, most often following or followed by a space, since that's the Markdown syntax for