"TheGiant" Cipher

[Shootinfish]

Ok thanks for that , I have edited the errors

So to get this clear there there is no capital S or o and no  lower case l

If you don't include the / "slash" that make it 59 characters used

And the message length is 189 bytes in total

last word is 3 characters

2nd to last is 16 characters

This really doesn't make sense to be a cipher and seems to be an encoding of some sort like you have mentioned unless we use the /

Can you post your string so others can work on it ?

[certainpersonio]

@Shootinfish I agree that there is no capital "S". As for the other two, there is a character that is either a capital "O" or the number zero. There is also a character that is either a capital "i"(I) or a lowercase "L" (l). In both cases, due to the font I don't think you can tell the difference between the two. As such, it could be either but it probably is consistent throughout. Here are each of those 4 possibilities:

“L” and 0

kCmlgFi6GUJNgkNl1Q41fbfyLoCFTCvlqkZil0KlAXAzP1U1uy1BE4U

fPBfpKmmL0bjYnQNRBaPtKiVWzc5A4v0w3xle8F0hAGJZ7g4in0wn

dJxM0v03dc1M82at2T6935roTqyWDgtGD/hwwRF3oHqFM5Vcw1

JtlNbsgWRm4o4/quEDkZ7x1B275bX3/Fo1

 

“i” and 0

kCmIgFi6GUJNgkNI1Q41fbfyLoCFTCvIqkZiI0KIAXAzP1U1uy1BE4U

fPBfpKmmL0bjYnQNRBaPtKiVWzc5A4v0w3xIe8F0hAGJZ7g4in0wn

dJxM0v03dc1M82at2T6935roTqyWDgtGD/hwwRF3oHqFM5Vcw1

JtINbsgWRm4o4/quEDkZ7x1B275bX3/Fo1

“L” and O

kCmlgFi6GUJNgkNl1Q41fbfyLoCFTCvlqkZilOKlAXAzP1U1uy1BE4U

fPBfpKmmLObjYnQNRBaPtKiVWzc5A4vOw3xle8FOhAGJZ7g4inOwn

dJxMOvO3dc1M82at2T6935roTqyWDgtGD/hwwRF3oHqFM5Vcw1

JtlNbsgWRm4o4/quEDkZ7x1B275bX3/Fo1

 

“i” and O

kCmIgFi6GUJNgkNI1Q41fbfyLoCFTCvIqkZilOKIAXAzP1U1uy1BE4U

fPBfpKmmLObjYnQNRBaPtKiVWzc5A4vOw3xle8FOhAGJZ7g4inOwn

dJxMOvO3dc1M82at2T6935roTqyWDgtGD/hwwRF3oHqFM5Vcw1

JtINbsgWRm4o4/quEDkZ7x1B275bX3/Fo1

I personally think this is the base64 alphabet. IT IS NOT A BASE64 CIPHER THOUGH; if you put all of these in to a decrypter you get gibberish, and not to mention you don't use the key: TheGiant. Instead, I think that this cipher does 1 of 2 things: 1) uses base64 alphabet in a classical cipher the same way that you would use a regular 26 letter alphabet. 2) converted message to base64 and then did something to it afterwards using TheGiant to get the current cipher text. These are my personal thoughts and I would love to hear other theories about it too.

[certainpersonio]

So I decided to statistically compare the cipher text to base64. I generated base64 by taking random text from wikipedia pages, converted them to base64, and then did frequency analysis on them. The results are in this spreadsheet: https://docs.google.com/spreadsheets/d/1NKj9SsjhT5n8DZN_kVDt9QdpL45Vp_zRQScIbh-8g3A/edit?usp=sharing

I was specifically interested in the percentages of capital letters, lowercase letters, numbers, and other characters present in confirmed base64 text and how they compared to the cipher.  Base64 text almost always has about 10-15% numbers, 40-50% percent each of capital letters and lowercase letters, and no other characters (namely /) are present.

I noticed 2 things:

1) The closest I can come to this is by using an "O" variant cipher text (instead of 0) to get more letters into the mix, but there are still about 2x (18-20%) as many numbers than there should be for a true base64 text. 

2) There are way to many unique characters in the cipher than in base64. There are 61 unique characters in TheGiant cipher, but the next closest of the true base64 was 50 unique characters. 

Implications: This is probably not a transposition of base64 text using the key "TheGiant". It could be a substitution of some sort. Who knows, it might not even be base64 text. Does anyone else have other thoughts?

 

[Shootinfish]

The problem I have with The Giant being a key to use for column transposition is it isn't a isogram unless you count the camel case, then if you do I think (I will check again) it still doesn't correct the / 

By this I mean there is 3 characters for the last word if the "/" is being used for a space meaning it has to be 3 not 2 characters long

But if you look at the second to last word it doesn't divide by 3 with zero quotient

[Shootinfish]

Ok i am experimenting with base64

I have taken the first 12 characters and converted them to the base64 number value

I then converted this to binary

I am then going to concancate them back into 4 24bit blocks so it can be converted back to ascii

Using high numbers to start the block

It will be trial and error from there using 6bit blocks like binary lego ;)

First 12 characters kCmlgFi6GUJN

Base64 numbers 36,2,38,37,32,5,34,58,6,20,9,13

Binary

100100‬
000010
100110
‭100101‬
100000
‭000101
‬100010
111010
000110
010100
001001
001101

Does this make sense or am i getting this completely wrong

If this works hopefully it makes sense into a column transpose

If not anyone got any other ideas on transposition method

[certainpersonio]

2 Thoughts @Shootinfish:

1) I agree with you that this probably isn't a transposition by itself that's occurring. My rationale for this is that if you look at the stats I did on TheGiant, it has too many numbers in it (about 2x as many) as most base64 text (in my admittedly small sample size). My conclusion is that a transposition will not decrease the total numbers used, so if TheGiant is used it'll be with a substitution alone or a transposition+substitution. Sorry if that wasn't really clear in my other post; I was really tired when I wrote it.

Also, I disagree with your thought about not being able to use columnar transposition. If you are saying the / act as a word break, I don't think it makes much sense. The first part is too long to be a single word and if it's denoting different sentences then the last part is to short. I think the / is a part of the cipher alphabet, which brings the total to 192 letters, which 192/8 (TheGiant) = 24.

2)  My understanding of base64 is that when you encrypt using base64 you go from ASCII-->binary-->base64. So it seems to me you are just repeating the steps a online decoder would do (and would save you a bunch of time). However, I've tried some online decoders, and I only got gibberish. Plus I wasn't able to use "TheGiant" key. Am I missing something that you are doing?

[Shootinfish]

Sorry i was quite tired aswell when i posted this and didnt explain it very well

Firstly im actually thinking it could be base64 just transposed

I agree that the "/" is part of the encoded text

In doing this we are hoping it hasnt been transposed by row or another means
 
What im doing i dont believe you can do with an standard decoder

You may be able to do it with a perl script and libary but alas my coding skills are poor

If you just cut and paste the letters and move them around they will retain the ascii binary values

You need to convert the encoded text letters to base64 index value then to binary then reassemble in different orders

 I will use the wiki table to make myself more clear

To encode

Text content
M a n

ASCII
77 (0x4d) 97 (0x61) 110 (0x6e)

Bit pattern
0 1 0 0 1 1 0 1 0 1 1 0 0 0 0 1 0 1 1 0 1 1 1 0

Index
19 22 5 46

Base64-encoded
T W F u

To decode

Base64-encoded > Index > Bit pattern > ASCII > Text content

Now i got something wrong in the above post you need  index values 16-31 to start a word , so there is a zero and one at the start which is important  this stops getting out of range characters and jibberish

Maybe an analysis of those characters will give you a hint

As for the slightly higher frequency of numbers you have in your spreadsheet maybe because of the word length distrubution

It is really impossible to tell about the spread with out knowing decoded text

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

EDIT

I was wrong this wont work I counted the index numbers 16-31 and there are only 38 in total and my calculations make it you need at least 48 for the amount of characters

So good call on your stats @certainpersonio     6      it gave me the idea how to check it

 

[certainpersonio]

@Shootinfish I'm glad the stats are helping! Your idea about boundaries for ASCII and Base64 has given me an idea. I'm going to flush it out a bit and see if it goes anywhere. Right now I'm getting lost in different cipher layers (It's like Inception up in here!) I'll post an update later. 

[Shootinfish]

Dont think this is much help but i thought i would post anyway

This is using no zero "0" and no capital "I"

These are the conversions of the characters into base64 index numbers and frequencies

Spoiler

36,02,38,37,32,05,34,58,
06,20,09,13,32,36,13,37,
53,16,56,53,31,27,31,50,
11,40,02,05,19,02,47,37,
42,36,25,34,37,14,10,37,
00,23,00,51,15,53,20,53,
46,50,53,01,04,56,20,31,
15,01,31,41,10,38,38,11,
14,27,35,24,39,16,13,17,
01,26,15,45,10,34,21,22,
51,28,57,00,56,47,14,48,
55,49,37,30,60,05,14,33,
00,06,09,25,59,32,56,34,
39,14,48,39,29,09,49,12,
14,47,14,55,29,28,53,12,
60,54,26,45,54,19,58,61,
55,57,43,40,19,42,50,22,
03,32,45,06,03,63,33,48,
48,17,05,55,40,07,42,05,
12,57,21,28,48,53,09,45,
37,13,27,44,32,22,17,38,
56,40,56,63,42,46,04,03,
36,25,59,49,53,01,54,59,
57,27,23,55,63,05,40,53,

00 = 4
01 = 4
02 = 3
03 = 3
04 = 2
05 = 6
06 = 3
07 = 1
08 = 0
09 = 4
10 = 3
11 = 2
12 = 3
13 = 4
14 = 7
15 = 3

////////////////\\51/////////

16 =  2
17 =  3
18 =  0
19 =  3
20 =  3
21 =  2
22 =  3
23 =  2
24 =  1
25 =  3
26 =  2
27 =  4
28 =  3 
29 =  2
30 =  1
31 =  4
//////////////\38\\\
32 = 5
33 = 2
34 = 4
35 = 1
36 = 4
37 = 7
38 = 4
39 = 3
40 = 5
41 = 1
42 = 4
43 = 1
44 = 1
45 = 4
46 = 2
47 = 3
////////////////52\\\\\
48 = 5
49 = 3
50 = 3
51 = 2
52 = 0
53 = 9
54 = 3
55 = 5
56 = 6 
57 = 4
58 = 2
59 = 3
60 = 2
61 = 1
62 = 0
62 = 3
/////////////\/\51\/\/\/

 

Even though its proved it cant be just standard transposed base64 I cant seem to get away from that it seems it deciphers into base64 and then it is decoded into ASCii

My reason for this thought is that I cant get the character base of radix 64 to line up with a cipher

How the substitution is calculated is a mystery

Is it possible the columns of the base64 index table have been swapped ?

Like swapping column 1 with column 4 so w would become A and A would become w

Index number 48 swapped for 0 "zero"

Maybe I'm going to far down the rabbit hole and should work more with the key of "TheGiant"

Would be great to hear any ones input on substitution techniques :)

 

[Nieno69]

Are there other non solved ciphers in the giant?

[Shootinfish]

40 minutes ago, Nieno69 said:

Are there other non solved ciphers in the giant?

Not 100% sure but there is the dots on the clock that I haven't seen explained anywhere

I was thinking it was something to do with modulus arithmetic but that's a wild guess

[certainpersonio]

Yes there are 3 unsolved ciphers on The Giant @Nieno69

1) TheGiant cipher (duh)

2) Brick Cipher (you go into the garage and hold a X on a brick. It goes flying up into air to reveal this:

NMFU3DNILVAXTPPH9AYHRXUM3PDBVMHN/CANVGPYS+3HGQKH

3) Bridge Cipher [Through Window next to Perk Machine (Der Riese Jugger-Nog location)] :

VXFPNFSVOHBMJBOHYDPLBBRNDJWOWIWUUJJJHVYKAGZAIY

@Shootinfish Welcome to wonderland Alice. I think you will find this helpful. This is partially what I was doing yesterday. I'll be posting an update with some of my progress and tools I've made to help. It'll probably be up in a couple of hours.

EDIT: Does the bottom half of my post look weird to you guys? I don't know why but it keeps posting in a different font/color. Tried to correct it but, oh well. 

 

[Shootinfish]

@certainpersonio thanks i will read that pdf and yes the font changes colour
 

Im trying to prove that the last step is not to decode Base64 into ASCII and i have run out of ideas

Basicly for it be valid Base64 it needs to have at least 48 characters in the base64 index range 16 -31 "Q,R,S,T,U,V,W,X,Y,Z,a,b,c,d,e,f,"

It also requires that these characters are at the start of the sequence of 4 (24 bits)

So index characters in the position of the cipher string 1 5 9 13 17 21 etc will contain only these 16 characters

Q,R,S,T,U,V,W,X,Y,Z,a,b,c,d,e,f,

I dont think its going to be easy to prove

I will keep trying as its the only lead I have

[Tac]

4 hours ago, Shootinfish said:

Not 100% sure but there is the dots on the clock that I haven't seen explained anywhere

I was thinking it was something to do with modulus arithmetic but that's a wild guess

Yup, you're correct about the dots being on the clock. Someone on Reddit says that Braille translated it to "Have only a AR!" and they connected it with the KN-44 on the blueprint. Can not confirm, but that's the story at least. Here's an image:

2 hours ago, certainpersonio said:

Yes there are 3 unsolved ciphers on The Giant @Nieno69

1) TheGiant cipher (duh)

2) Brick Cipher (you go into the garage and hold a X on a brick. It goes flying up into air to reveal this:

NMFU3DNILVAXTPPH9AYHRXUM3PDBVMHN/CANVGPYS+3HGQKH

3) Bridge Cipher [Through Window next to Perk Machine (Der Riese Jugger-Nog location)] :

VXFPNFSVOHBMJBOHYDPLBBRNDJWOWIWUUJJJHVYKAGZAIY

@Shootinfish Welcome to wonderland Alice. I think you will find this helpful. This is partially what I was doing yesterday. I'll be posting an update with some of my progress and tools I've made to help. It'll probably be up in a couple of hours.

EDIT: Does the bottom half of my post look weird to you guys? I don't know why but it keeps posting in a different font/color. Tried to correct it but, oh well. 

 

You can select the text and then under the two font color options, press "automatic." If that doesn't work, copy it and then paste it right back down (then click "remove formatting" on the bottom of the post box). Hope that helps!

[Pcsolyar]

1 hour ago, Tac said:

Yup, you're correct about the dots being on the clock. Someone on Reddit says that Braille translated it to "Have only a AR!" and they connected it with the KN-44 on the blueprint. Can not confirm, but that's the story at least. Here's an image:

You can select the text and then under the two font color options, press "automatic." If that doesn't work, copy it and then paste it right back down (then click "remove formatting" on the bottom of the post box). Hope that helps!

Do we have a thread for this yet? This could use some research.

[certainpersonio]

Ok, so here comes a long post:

First, I've created some different alphabets/tools for different types of ciphers for people to play around with. I've put them in this spreadsheet and (assuming it did it right) people should be able to edit it as well. I've said this before, but I think it bears stating again. I'm approaching this cipher assuming that it's, at the very least, using the base64 alphabet. If it turns out it isn't then these are useless. From this assumption, I think there are 2 most likely explanations of what's happening: 

1. Cipher is a classic cipher that uses base64 alphabet. Think Vigenere cipher with a big alphabet.
2. Cipher is actually double encrypted: ASCII-->Base64--> "TheGiant"

Second, a discussion on my findings/thoughts about base64. Base64 converts 4 base64 characters to 3 ASCII characters via converting index values to binary and then back again. There are two consequences of this. The first is that you can effectively split the entire 192 character cipher into 48 groups of 4 (and the plaintext ASCII will be in groups of 3). The second conclusion is that we can limit the number of base64 characters that begin each of these 4 character groups. This is because if you begin a group with a letter outside of a certain base64 index range then you get gibberish. I'll provide an example but honestly I had to manually do it a few times before I actually understood.

Ex: ASCII -   A  -  65 = 0100 0001          Base64  - Q -16 = 0100 00

What this means is that if the plaintext grouping in ASCII starts with an "A", then in Base64 it will become encrypted with "Q". From this you can actually chart the that "largest" (by index size) character we could use is "z" (122) and the lowest is "(space)" (32). When converted to base64 you get a range of capital "I" (8) - "e"(30).  @Shootinfish reported that we only need values 16-31. The reason his and my ranges differ is because he starts at "A" instead of "(space)". I think that the majority of the time we will be operating with 16-30 as the range for the first character in the grouping. However, there are some characters, namely "(space)", "," , "." , or any of the numbers that will come before 16 and could happen. Like I said though, these will not happen very frequently. Here is a summary list:

• Entire possible index range: 8 - 30 (capital I - e)
• Most probable index range: 16 - 30 (Q - e)
• Capital letter range: 16 - 22 (Q - W)
• Lowercase letter range: 24 - 30 (Y - e)
• Period or comma (ASCII): 11 (L)
• (space), ! , " , # (ASCII): 8 (capital I)

But we can also do this same process for the ending of each base64 grouping! Admittedly I haven't gone through and actually calculated the ranges and stuff, but it should be possible (maybe a project for another day). In fact, we can even assign every single character in ASCII a base64 character that it will be associated with if it starts the grouping or ends the grouping. Currently I don't think we can actually assign the middle two base64 characters consistently because it depends on the combination of 2 characters, not just one. 

My hope is that this can help us more quickly identify ways that effectively transforming the cipher into proper base64!

[Shootinfish]

Sorry another long post this is a bit of  a wall of text

I have moved on to the brick cipher i will post what i have done below in a spoiler

I assume its ok to keep it in the same thread like that has been done with DE ciphers

The cipher is all uppercase except for the "/" and "+" symbols

I didnt think it is straight transposed base64 but i thought i would check as it is quite short with a string length of 48

It also has 25 unique symbols

There is no key with it

I was hoping that the frequency of index numbers would rule it out in 6 bit binary 

It seems it has and i have learned something else about Base64

Firstly i had enough in the 16 - 32 range

But it seems there is not enough 6 bit building blocks of another type

Is anyone familier with bit masking used in bit banging

Not sure if this is the correct way to format it but,

I will put an "*" in the bit i want to toggle

It ran out of a type of block that are

on the 5th bit  0000*0 (which needs to be zero)  

On the 6th bit  00000* (which needs to be one)

For example bit pattern "000001" Base64 index number 01 symbol B

You need at least the same amount as the Base64 index 16 -32 number range which is 1/4, which is 12 symbols out of 48 for the brick ciphertext

Those need

The 1st bit *00000  (which needs to be zero)

And 2nd bit 0*0000  (which needs to be one )

So i added the frequency count of both these types together and only count 22 which isnt enough assuming you need at least 24

I made a mistake so I edited it

Anyway in this spoiler is my working out of the brick cipher to show how I drew to the conclusions I have

 

Spoiler

NMFU3DNI

LVAXTPPH

9AYHRXUM

3PDBVMHN

/CANVGPY

S+3HGQKH

 

13 , 12 , 05 , 20 , 55 , 03 , 13 , 08 ,

11 , 21 , 00 , 23 , 19 , 15 , 15 , 07 ,

61 , 00 , 24 , 07 , 17 , 23 , 20 , 12 ,

55 , 15 , 03 , 01 , 21 , 12 , 07 , 13 ,

63 , 02 , 00 , 13 , 21 , 06 , 15 , 24 ,

18 , 62 , 55 , 07 , 06 , 16 , 10 , 07 ,

 

 

SYMBOL  |__FREQ ____B64INDEX_____BINARY____
+     | =  1  |      63        111111
/      | =  1  |      62        111110
3     | =  3  |      55        110111
9     | =  1  |      61        111101
A     | =  3  |      00        000000
B     | =  1  |      01        000001
C     | =  1  |      02        000010
D     | =  2  |      03        000011
F      | =  1  |      05        000101
G     | =  2  |      06        000110
H     | =  5  |      07        000111
I       | =  1  |      08        001000
K      | =  1  |      10        001010
L      | =  1  |      11        001011
M     | =  3  |      12        001100
N     | =  4  |      13        001101
P     | =  4  |      15        001110
Q     | =  1  |      16        010000
R     | =  1  |      17        010001
S     | =  1  |      18        010010
T     | =  1  |      19        010011
U     | =  2  |      20        010100
V     | =  3  |      21        010101
X     | =  2  |      23        010111
Y     | =  2  |      24        011000

Sorry the formatting has gone all wrong but it should be clear enough to read

 

[Shootinfish]

Sorry for the double post but i just wanted to clarify what i have wrote as i have edited the above post I have made a mistake in thinking we could disgard certain bit pattens easily but you cant i was wrong

I can work out what does fit and where for the first three index characters for the base64 sequence  It may give a clue to the frequencies but im trying to get my head round if this is possible

@certainpersonio i will reread your post again and think about space and punctuation

Anyway in this below spoiler is a chart im working on, 1st is 1st 6 bit block of the Base64 sequence "24 bits", blank means it could go in the last block bits 18-24

 

Spoiler

000000  00  A 
000001  01  B  3rd
000010  02  C  
000011  03  D 
000100  04  E 
000101  05  F  3rd
000110  06  G  
000111  07  H 
001000  08  I  2nd
001001  09  J  2nd 3rd 
001010  10  K  2nd
001011  11  L  2nd
001100  12  M   
001101  13  N  3rd
001110  14  O  
001111  15  P   
010000  16  Q  1st
010001  17  R  1st 3rd  
010010  18  S  1st
010011  19  T  1st 
010100  20  U  1st 
010101  21  V  1st 3rd
010110  22  W  1st
010111  23  X  1st
011000  24  Y  1st 2nd 
011001  25  Z  1st 2nd 3rd 
011010  26  a  1st 2nd
011011  27  b  1st 2nd 
011100  28  c  1st
011101  29  d  1st 3rd
011110  30  e  1st
011111  31  f  1st
100000  32  g 
100001  33  h  3rd
100010  34  i 
100011  35  j  
100100  36  k 
100101  37  l  3rd
100110  38  m 
100111  39  n  
101000  40  o  2nd
101001  41  p  2nd 3rd
101010  42  q  2nd
101011  43  r  2nd
101100  44  s  
101101  45  t  3rd
101110  46  u   
101111  47  v  
110000  48  w  
110001  49  x  3rd
110010  50  y  
110011  51  z  
110100  52  0  
110101  53  1  3rd
110110  54  2  
110111  55  3 
111000  56  4  2nd
111001  57  5  2nd 3rd
111010  58  6  2nd
111011  59  7  2nd
111100  60  8   
111101  61  9  3rd
111110  62  +  
111111  63  / 

 
 

 

EDIT////////////////////////////////////////////////////////////////////////////////////////////////////////

I am looking at what i have done so far and am think i have got some assumptions wrong i am going to take a break from it and see what anyone else has come up with i was assuming that it wouldnt use space or numbers but there is no solid proof it doesn't, maybe ive gone to far down the rabbit hole and there is a much simpler solution to TheGiant cipher , it just seems too complicated to have it deciphered into a encoded format

@certainpersonio i understand about the space and numbers and am unsure how to go about seeing if there enough valid Base64 characters to build into ASCII

 

[Tac]

Is there any way you can post those in paragraph form? Saves a lot of space when scrolling through, plus it's easier to read (to me, at least).

[WaterKH]

On 2/16/2016 at 4:23 PM, certainpersonio said:

Ok, so here comes a long post:

First, I've created some different alphabets/tools for different types of ciphers for people to play around with. I've put them in this spreadsheet and (assuming it did it right) people should be able to edit it as well. I've said this before, but I think it bears stating again. I'm approaching this cipher assuming that it's, at the very least, using the base64 alphabet. If it turns out it isn't then these are useless. From this assumption, I think there are 2 most likely explanations of what's happening: 

1. Cipher is a classic cipher that uses base64 alphabet. Think Vigenere cipher with a big alphabet.
2. Cipher is actually double encrypted: ASCII-->Base64--> "TheGiant"

Second, a discussion on my findings/thoughts about base64. Base64 converts 4 base64 characters to 3 ASCII characters via converting index values to binary and then back again. There are two consequences of this. The first is that you can effectively split the entire 192 character cipher into 48 groups of 4 (and the plaintext ASCII will be in groups of 3). The second conclusion is that we can limit the number of base64 characters that begin each of these 4 character groups. This is because if you begin a group with a letter outside of a certain base64 index range then you get gibberish. I'll provide an example but honestly I had to manually do it a few times before I actually understood.

Ex: ASCII -   A  -  65 = 0100 0001          Base64  - Q -16 = 0100 00

What this means is that if the plaintext grouping in ASCII starts with an "A", then in Base64 it will become encrypted with "Q". From this you can actually chart the that "largest" (by index size) character we could use is "z" (122) and the lowest is "(space)" (32). When converted to base64 you get a range of capital "I" (8) - "e"(30).  @Shootinfish reported that we only need values 16-31. The reason his and my ranges differ is because he starts at "A" instead of "(space)". I think that the majority of the time we will be operating with 16-30 as the range for the first character in the grouping. However, there are some characters, namely "(space)", "," , "." , or any of the numbers that will come before 16 and could happen. Like I said though, these will not happen very frequently. Here is a summary list:

• Entire possible index range: 8 - 30 (capital I - e)
• Most probable index range: 16 - 30 (Q - e)
• Capital letter range: 16 - 22 (Q - W)
• Lowercase letter range: 24 - 30 (Y - e)
• Period or comma (ASCII): 11 (L)
• (space), ! , " , # (ASCII): 8 (capital I)

But we can also do this same process for the ending of each base64 grouping! Admittedly I haven't gone through and actually calculated the ranges and stuff, but it should be possible (maybe a project for another day). In fact, we can even assign every single character in ASCII a base64 character that it will be associated with if it starts the grouping or ends the grouping. Currently I don't think we can actually assign the middle two base64 characters consistently because it depends on the combination of 2 characters, not just one. 

My hope is that this can help us more quickly identify ways that effectively transforming the cipher into proper base64!

Also, I was able to validate with someone I know that it is definitely Base64 as we converted the original text to Base32 as well as other to some other Bases. This just makes it definite that we are taking a value from Base64 and converting it to another Base. Also, I believe, and this may have been exactly stated in your post - pretty sure it was.. -, but I think what we need to do is transpose using the key "TheGiant" and then convert the new string into ASCII. I saw your spreadsheet so I think you had the same idea, just wanted to clarify! (:

[Shootinfish]

Ok theres no capital S in TheGiant ciphertext, Base64 Character "S" index number 18 using bit pattern  010010 this bit pattern is included in ASCII   H ,I ,J,K ,R , would this mean the very first letter could not be ,H, I ,J , K ,

Depending on how you interpret the "I, l, O, 0" this also means some bit patterns are excluded

Also an idea about transposing the text using the keyword TheGiant, first of all it is 8 ASCII characters so you would need to add a space at the end if you where encoding it into Base64 to avoid padding "so you didnt have a = at the end" to make it 12 Base64 characters " 

TheGiant encodes to Base64 VGhlR2lhbnQg  Base64 index numbers 21,06,33,37,17,54,37,33,27,39,16,32

 36,02,38,37,32,05,34,58,
 06,20,09,13,32,36,13,37,
 53,16,56,53,31,27,31,50,
 11,40,02,05,19,02,47,37,
 42,36,25,34,37,14,10,37,
 00,23,00,51,15,53,20,53,
 46,50,53,01,04,56,20,31,
 15,01,31,41,10,38,38,11,
 14,27,35,24,39,16,13,17,
 01,26,15,45,10,34,21,22,
 51,28,57,00,56,47,14,48,
 55,49,37,30,60,05,14,33,
 00,06,09,25,59,32,56,34,
 39,14,48,39,29,09,49,12,
 14,47,14,55,29,28,53,12,
 60,54,26,45,54,19,58,61,
 55,57,43,40,19,42,50,22,
 03,32,45,06,03,63,33,48,
 48,17,05,55,40,07,42,05,
 12,57,21,28,48,53,09,45,
 37,13,27,44,32,22,17,38,
 56,40,56,63,42,46,04,03,
 36,25,59,49,53,01,54,59,
 57,27,23,55,63,05,40,53,

Can anyone spot a pattern because i cannot so maybe we can rule that method out maybe I should try a space at the start what do think of the idea

Also what toolset are you using  ?, I'm using notepad++ with MIME plugin to encode and decode

@Tac Sorry about the messy formatting I struggle a little with it, but I hope it has improved as I have spent more time editing it , also I just realised I'm copying and pasting from notepad++ and that is messing with the formating

 

 

[certainpersonio]

@vigiliisgaming So I actually didn't think to take it to another Base and then convert it to ASCII. I do like this idea though. I was more just observing that it shouldn't be a straight transposition so it needs something else to happen. I was guessing a substitution process personally, but it's kind of heard to figure it out without any standard letter frequencies in base64 available. So maybe it's not a substation but a change of base that needs to happen though.

@Shootinfish That's a really good point about the S. Definitely something that needs to be rectified because there are some pretty frequently used letters in that group. Also I agree that I don't see a pattern in what you posted, but actually I'm a little lost as to what you did with the Base64 converted ASCII "TheGiant_". And frankly I think any idea is a good idea because what we've done so far hasn't helped us solve it.

As for toolsets I use, I'm pretty low-tech, most because of my own lack of training. I have absolutely zero coding experience/computer wizardry so I alternate between a few things: I take notes on a word doc about all the different ciphers, I've found excel is excellent for doing transpositions and a lot of other work because you move it around so much easier than in word, when I want to solve I usually do it with some online solver. Personally I'm using this one to do base64 conversions. I also like to liberally use paper to doodle out ideas.

[WaterKH]

@certainpersonio It "may" be that we need to convert it, but I don't know yet either. Specifically with Base32, I believe we are switching from 2^8 bits to 2^7 so we are losing about 256 bits of data (This may or may not be correct..). If this is correct, I think that it simply justifies it being Base64, not that we should convert it to Base32. For one thing we are losing that data which doesn't seem like it would be the right decision. However, I have not tried converting back yet, though I believe Base32 is 0-9 A-Z, where Base64 includes these as well as a-z. Thus we would be losing those smaller letters. But again, I haven't had much time to work through it. (:

Also, I find these extremely useful! This one can encode and decode most of the data types that are useful in realtime: https://conv.darkbyte.ru/  This one is a basic ROT, but it does all 26 rotations of the alphabet: http://theblob.org/rot.cgi (:

@Shootinfish That's an interesting technique converting the ASCII to Base64. Are you then transposing the Base64 with the converted ASCII? Or, what exactly are you doing? Interesting nonetheless!  

[Shootinfish]

Ok i just want to clarify what i mentioned about the S, because i didnt explain it very well. If it is straight transposed and no subsutution is used then the ASCII letters H,I,J,K cannot be used in the first 6 bit block "bit 1-6" of a 24bit Base64 sequence however these letters can be made in the other 3 blocks (not sure which or if all of them yet)

Lets check out letter H to go at position block 1 or 4 of a 3 repeated character string

The easist way i have found for bit patterns is repeating the ASCII letter three time and converting it to Base64

ASCII = HHH

Base64 string  SEhI

6 bit binary base64 string  010010 000100 100001 001000

8 bit binary ASCII  string  01001000 01001000 01001000

| block 1 | bit 1-06  | S is not included so this isnt possible 
| block 2 | bit 7-12  |
| block 3 | bit 13-18 |
| block 4 | bit 19-24 | ///// Would need capital I to be included in alphabet index meaning no lowercase l (which i have been using)

I know that three of the same letters in a row doesnt make much sense but its the bit patterns im interested in.

If it is base64 then somewhere along the line 3 bit patterns are excluded because there are only 61 unique characters. I think a lot more can be done with this but i would like to hear everyone else opinon on what im doing and if its right, if it makes sense

 

Regarding what i have done in above post. Basicly i have converted the ciphertext into base64 index numbers which is the 8 * 24 table which is untouched and in the order it is presented in the ciphertext. It is using lower case "l" and uppercase O (i dont know if this right i just picked one combination) i then just looked for patterns visually that might possibly lead to a logical transpose

[WaterKH]

Doing a little more work on this - If we use the key as a transposition key (Granted that a-z is < A-Z) we get this: https://docs.google.com/spreadsheets/d/1mzDNiQU8tusHzDp2Ft_BbDOEj-VzNEAc_FMFlAHZgO4/edit#gid=854720695 (Goodness that's a long URL...). I tried running it through and still get gobbity-goop. This is the string I get but I don't think this route will provide anything:

Spoiler

FmCgi6lkkJUgNlNGb4Qffy11CCoTvlFL0ZklKliq1AXPU1zA41yEUBuKBPpmmffnb0YQNjLKaBtiVPR4czAv05W8x3eF0lw7GAZg4Jh0nnwivxJ003Md21c8atMd56T3ro92gyqDtGWTRh/wF3wD4qHMVcFo1wsltbgWNJ/4m4quoRxkD71BZE357X/Fb21o

This is using lower case "L" (I realize it's upper, but I did that because it's hard to tell otherwise) and zero for the O. Anyone on that could chat? Might get more work done if we streamline communication.

EDIT: I created an irc.freenode.net room: #TheGiant - I'm usually always on several channels so figured I'd open one for people who want to chat specifically about the cipher. Just @waterkh on the channel if you have anything to discuss. I may post a thread about this...