Good point. However, Maybe that’s a clue that the hex is scrambled with Lorem Ipsum.
I found a calculator for lorem ipsum hashes online here. However, I’m not quite sure how to use the tool. Again, it could be something - it could mean nothing. But it’s worth checking.
I can’t believe we didn’t think of this earlier. I took the first (or last) 8 bytes of the code as the initialization vector in my deciphering program. It didn’t work, but it was definitely worth a try.
Anyway, it got me thinking. Belanoh, Paillier and RSA cryptosystems desperately need some prime parameters. I noticed that both B32B003A and 35BADD66 (the beginning of the HALOS code) are one less than a prime (in the big endian notation). The numbers p-1 and q-1 are used in all three cryptosystems, so it is reasonable they could be there. Specifically, p=3005939771 and q=901438823.
Additionally, the number B32B003A35BADD66 taken as a little endian integer is 7412285299490827187, which is a prime. But the next such number isn’t, so I’m not sure what could this mean.
Surely, one of these cases is just a coincidence. I think it’s the latter, as the probability of a hex number of the form XXXXXXXXXXXXXXXX being a prime is about 2.3%, but the probability of two of the form XXXXXXXX being a prime is just 0.22% (you can use the prime number theorem to see this).
Unfortunately, all three cryptosystems require at least one additional parameter, it could be the next number in the code, it could be from outside.
And I’m not even sure this is the right direction since I have absolutely no idea how to reasonably divide the rest of the code into blocks in order to even apply these kinds of cryptosystems. So I probably won’t pursue this further.
That p and q don’t work with Paillier, they must be breaking one of the prerrequisites because the decrypter throws a tantrum about them.
About the others, I have not idea.
@AngelSG ??? It doesn’t even make sense to use that javascript decoder on a message more than twice the lenght of the “public key” field because it treats everything as a single block.
See https://en.wikipedia.org/wiki/Paillier_cryptosystem#Algorithm how it works. In the javascript decoder, “public key” corresponds to “n” and the implementation actually hardcodes the free parameter “g” to “n+1”, so it won’t ever decode anything where the “g” parameter is different. The “lambda” is the same.
In our case assuming it’s Paillier, “n = pq = 2709670809179129533” and “lambda = lcm(p-1,q-1) = 1354835402635875470” and “g” is unknown. It’s also unknown how to divide the message into blocks to even use the decoder as this can decode only messages which are (as a number) less than n^2.
I used the implementation in cryptools 2.0. What I meant by it’s not valid, is that they probably not comply with
gcd(pq, (p-1)(q-1))=1
I did not calculate the gcd, but the condition is only guaranteed to be complied with if the two numbers are of the same length.
@AngelSG My mistake, I thought you were using the javascript implementation posted here some time ago. But the points stand. The p,q I posted satisfy the conditions, you can check it on WolframAlpha (actually it’s an easy exercise that gcd(pq, (p-1)(q-1)) != 1 if and only if p | q-1 or q | p-1).
Also, the length you quoted is probably meant in bits. Take any prime ‘p’ such that ‘2p+1’ is a prime too (most likely same decimal length), then ‘gcd(p(2p+1), (p-1)(2p)) = p != 1’. There are many examples of such primes. But thats doesn’t change anything because ‘guaranteed’ doesn’t mean it fails when the length is different.
Then I do not know why the decoder failed :S
I’ll check again
@AngelSG I don’t know how your decoder works, but p,q are not sufficient for Pallier encryption or decryption. Doesn’t your decoder need more parameters?
The only parameters that it asks for are two primes, p and q, there are no other fields. And now I know why it threw a tantrum, I was using p and q in hexadecimal, they needed to be decimal. It decodes now, but the output is significantly shorter than the input, so I guess that only part of the ciphertext is being decoded, still, it’s just gibberish
8B 94 1D D2 B5 FA F3 2D 29 83 D4 52 90 C3 83 BF C6 61 64 36 1B 00 6A 54 C4 BA E9 0C 9B 70 14 0A EC FF B3 90 98 78 5C 61 6B 43 D3 9F FA 0B 2E 86 DC 30 3A E0 9D 57 E0 AB 5C AC 5A D0 E9 20 3F EA FA 08 DB E7 77 2F BD 81 CF D8 85 33 4F 21 97 D2 96 19 EB 40 E1 68 38 6D F1 3B 23 2F 85 BB 85 2B 8D 5B 01 B0 4F 39 2F 5B 6D EC 91 52 60 CE 29 12 E2 12 22 E8 0A 3A 5D D8 8F 1A A7 98 E4 B7 68 04 94 D7 7C F6 CB 11 5B 7A 89 92 D5 01 B6 CC 81 F4 D2 25 6E 2C C4 F5 6F 00 DC 0F 95 86 26 50 AC 89 3FIsn’t that hex?
Yes, it is hex. But it does not decode to anything legible in UTF-8, it’s just seemingly random bytes.
i lost you here, hex or nbase64 are just different readable ways to display bytes
if its base64 or hex its still the same bytes right? so how could you all of a sudden find an image 
maybe just do a +1 on all values?
If we assume a simple encoding scheme was used, where the ciphertext is divided into blocks of a size determined by n^2, and each block is a base 256 representation of a large integer, then all we need to do is to determine how many bytes are needed to represent a number as large as n^2.
Using the numbers you provided, the block size of the ciphertext will be: ceiling(log256(n^2)) = 16 bytes, which happens to be an exact fit with the data after removing the first 8 bytes that were used to obtain p and q.
We don’t know the byte order, but it seems logical to assume big-endian order, as that’s the order used when obtaining p and q.
However, if we calculate the minimum bit length needed for each block, we get ceiling(log2(n^2)) = 123 bits. This means that the 5 most significant bits in each block will always be 0, which we should be able to see in the data. Looking quickly at the data, this doesn’t appear to be the case.
I’ve looked into how the Paillier components in CrypTool 2.0 work. In the example template (which I assume you’ve been using) there is a Paillier key generator which has an option where you can manually enter the prime numbers p and q. The key generator then generates all the parameters (n, g and lambda) needed for the Paillier encryption/decryption component. The key generator seems to be using the simpler variant of the key generation procedure (described on the wikipedia page) where you only need p and q.
Assuming p = 3005939771 and q = 901438823, the other parameters will be as follows:
n = pq = 2709670809179129533
g = n + 1 = 2709670809179129534
lambda = (p-1)(q-1) = 2709670805271750940
mu = inverse of lambda modulo n = 2007412617561027517
Note that you can still use your own values for g and lambda by deleting the Paillier key generator component, and add number inputs for n, g and lambda and connect them to the Paillier component.
The ciphertext produced by the encrypter is encoded the same way I described earlier (using a block size equal to ceiling(log256(n^2))), except that the byte order is little-endian. Unfortunately, there’s no way to change the byte order.
Could we not just convert the Hex / Binary input from big-endian to little-endian and then use that as input? from what I understand, that would just require swapping every two hex pairs. Or maybe I’m oversimplifying this.
EDIT: Here’s the entire hex 16-bit byte swapped (I couldn’t recall how many bytes were used to come up with the key info):
2BB33A00BA3566DD7C57C124C94F0619464331D1C5A7B84BFE2FE003612277577924DC23F621D42C2E18C39167B245B5CAABAFED61020D51EA4E871E33CDC7C731719C3028C4B40E3D24541144F0CFF99662BFD939F7437E9890E67F03320DDA02E4B378...Doesn’t work either
F6 57 98 AB FF 49 02 F7 B7 29 17 7D C9 EC 22 3E 9E F4 49 5B 14 19 57 F6 7B 4B 2F 52 A2 58 0C 19 DB ED DA 16 22 45 4A 5D 1B 1B C7 B5 F8 DE 67 03 40 E6 96 52 DC B5 71 66 0F C4 26 73 F7 B3 D3 23 84 A7 BE 2B 5B B4 02 72 82 A1 C5 E6 F2 BA 0B B3 09 29 00 6F F9 6B 3D 2B AE 29 A7 80 B8 85 8A 99 56 E2 B0 0B 0B 69 95 D4 20 28 E5 09 C2 6D BD 13 83 7C E8 67 07 E9 EE F5 1F B6 7E 97 0A D0 16 E5 E6 B6 C2 49 B9 BA 33 B2 51 58 9E 0C DA 75 09 44 DD 13 3E B6 89 0C 95 A8 BB D4 9D 86 3F 83 33 B0 48Either the implementation of Paillier is faulty, it’s not Paillier or this is not the password.
Well, for the case we’ve been discussing, p and q used 4 bytes each, leaving 368 bytes for the encrypted data. The block size was 16 bytes. Changing the endianness in this case means reversing the entire string of bytes in each 16-byte block.
In the first block (offset 8 in the raw HALOS code) we have:
57 7C 24 C1 4F C9 19 06 43 46 D1 31 A7 C5 4B B8After reversing the byte order, it should be:
B8 4B C5 A7 31 D1 46 43 06 19 C9 4F C1 24 7C 57BUT, as I mentioned earlier in my previous post, the actual number of bits needed to store the large integers that hold the Paillier encrypted data, using the parameters mentioned in previous posts, are 123, which is rounded up to the nearest byte boundary, resulting in 128 bits. These extra bits will always be 0, which would have showed up as a pattern in the data.
Just to illustrate, I’ve encrypted IRC clue 1 with Paillier in CrypTool using the same parameters. Here are the first 8 blocks of the encrypted data:
7A 31 9F A8 F1 1E 5D 51 43 1B 27 86 9A C3 12 00
89 6A 7A C5 7D 40 02 69 02 7C C2 6F F4 C1 6D 04
5C 56 0D EB A6 79 E4 5F DC E0 94 A3 87 1E B0 02
86 B4 59 40 B5 88 C0 64 AC 96 0F BF 43 66 9F 00
68 85 4A 82 FB C4 70 09 17 D0 97 85 9A 6D 33 01
BC 4F 64 1E 38 AB 9D 2C 20 4F E8 74 28 23 5B 00
10 88 7E AF 87 F6 87 6E B7 1C F4 1F 55 0F EE 02
11 F1 32 D4 B7 2D DB 6D 6B 35 9C 0C 10 C7 F0 02
If we look at the rightmost hex pairs (the most significant byte), they are all noticeably small. We don’t see this pattern in the HALOS code. So either the parameters are wrong (resulting in a different block size and/or alignment), or Paillier is not the right direction.
But we should probably check the code thoroughly and see if there is a pattern of consecutive bits of 0s appearing at regular intervals, which might indicate that a cryptosystem like Paillier was used, encoded the way I described earlier, but encrypted with different parameters resulting in a different block size.
It’s obvious that we’re not progressing, maybe we should go back and try to make sense of the whole story and Niobium V? I mean, it’s weird that we did not managed to make a solid connection between all the clues in relation to the HALOS code. I’ve been looking into niobium more, has ever been brought up from where the name of Niobium came from? It comes from Niobe, a greek mythological figure, daughter of tantalus. Since the element was identified from a mineral that was mostly made of the element Tantalum, they scientist that discovered it decided to name it Niobium.
The Niobium is central to this, there’s plenty of things that point to Niobium directly or inderectly, some whiteboards, the tempus omnia revelant clue, the IRC clues, any mention of Dr. Marcel… If we assume Halos is similar to cyberax, Dr. Horn developed an AI, and to house it and control it, he obtained Niobium that he used to create the hardware in lab X01 and X02, that only he and some few other people have acces at, and was under construction (are we to assume that X01 and X02 is stormseeker.com/thepizzaisalie/ website since it is under construction?)
At some point, Welsh stole some of the lies (pizzas), and the lies played a part in the construction of the AI apparently, so we are to assume that in fact, the pizzas were used not only to cover the cost of the project, but to smuggle the Niobium as it was suspected. Then he says, they can’t hide there, (where is there?) because apparently he has something that is the key to all things (masterkey?).
Then he goes on to talk about hidding it on the secure site, but he wants revenge. How all this ties with the HALOS code? Is the HALOS code been secured through encryption, and whatever is inside the HALOS code is what allows Dr. Horn to control the AI? More importantly, does this give us any idea about how to decrypt it or ties to the 21 into 1 clue?
Agreed.
I’ve been messing around with the HALOS file and the 21 into 1 clue recently. Here’s what I’ve got on 21 into 1.
If you divide 21 by 1, you get this: 0.04761904761
It may not seem like much, but a little Googling brought me across this tweet from @EthanDChung
This quote seems to tie into another interesting clue that was noted with 21 into 1:
The date 12/21/12 coincides with a fun date about the (supposed) end of the world.
Bringing that back around to HALOS, the start of the end is a base point for something. Perhaps a key, salt or IV. That brought me around to building a aes-256-cbc brute-force program in Go, starting with the key “BENALOHPAILLIER” and the IV 0.0476… converted into UNIX epoch. The reason for using epoch is that it’s a 32-bit integer. The key has to be padded so that it consumes the same bit space as the epoch.
I did try multiple combinations of the key, upper, lower case, putting a space in-between, and multiple permutations of that formula. I had this with very, very, very little success only gaining 1 char of ASCII output. Please note, I ran this in a loop incrementing the IV by 1 over the effective period of 2 years.
In addition, I did try using the BENALOH key as the IV and the epoch as the key, but again with the same outcome as before.
It’s also important to note I did try converting the epoch between Big & Little Endian before stopping my attack.
The reason I did not start with aes-128 is that it’s theoretically breakable and it was noted by Storm that this couldn’t be broken by anyone of importance. That doesn’t mean it isn’t worth trying, it’s just that I haven’t done it yet.
I plan on giving my Go brute-forcer another pass, because I’m not settled that everything was converted into bytes correctly. I’m a pretty skilled software dev, but this was my first time with Go and I think I could do better.
Thoughts? Also, to the community, if there is interest I will post my code on GitHub and allow PRs to improve the quality of our attacks. Just let me know…
There’s also hexadecimal notation, 50D3A680, though this is for 21/12/12 (12/21/12 for americans) 00:00:00 AM (UTC), maybe it should be in PST? Nevertheless, this ties up with time, with the beginning of the end which was the name given to that date and with 21 goes into 1, the three of the four clues we were given, seems the way to go.
I don’t think the CIA could bruteforce AES 128, not sure if they can now, but we have to keep in mind that it’s been two years since storm said that. Even 3DES would not be outside the realm of possibility, using the keying option with the highest security, it has a key lenght of 192 bits, which translate to 168 bits of practical keylength; and 3DES ties to all the mentions of satan, the divine comedy etc. since it’s DES applied three times, and DES comes from Lucifer. About using IVs, I don’t know, the theory about [ABORTIVE.] in the place of [TERMINAL.] standing for ABORT Initialization VEctor, and therefore use electronic-code-book mode, sounds slick.
Founded in 2004, Leakfree.org became one of the first online communities dedicated to Valve’s Source engine development. It is more famously known for the formation of Black Mesa: Source under the 'Leakfree Modification Team' handle in September 2004.