I like the idea of using ECB, because it means everything has to be in their neat and tidy blocks.
Onward!
I ran a bunch of different pairings and bit sizes through the ciphers mentioned by StormāRjindael, Twofish, Serpent, etc.āto no avail.
I think we need to continue to focus on Stormās last message to me:
Considering a flawed OTP (which it was, considering the ability to analyze it), when done properly should be information-theoretically secure, the next level should be either hyper-encryption using random bits (which is unlikely considering the difficulty in making that crackable and for the fact itās usually used on hardware encryption chips), or some form of Block Cipher (from which if we assume the scale of Levels goes up to 10), can be extended into simple block ciphers with small block size, which analysis seems to indicate it is not, up to triple cascaded ciphers with high block sizes, salts and perhaps even key files to add additional strength.
This last part is hugeāwe are likely dealing with multiple encryption. Pulled from this page:
[i]With the exception of the one-time pad, no cipher has been theoretically proven to be unbreakable. Furthermore, some recurring properties may be found in the ciphertexts generated by the first cipher. Since those ciphertexts are the plaintexts used by the second cipher, the second cipher may be rendered vulnerable to attacks based on known plaintext properties (see references below).
This is the case when the first layer is a program P that always adds the same string S of characters at the beginning (or end) of all ciphertexts (commonly known as a magic number). When found in a file, the string S allows an operating system to know that the program P has to be launched in order to decrypt the file. This string should be removed before adding a second layer.
To prevent this kind of attack, one can use the method provided by Bruce Schneier in the references below: generate a random pad of the same size of the plaintext, then XOR the plaintext with the pad, resulting in a first ciphertext. Encrypt the pad and the first ciphertext with a different cipher and a different key, resulting in 2 more ciphertexts. Concatenate the last 2 ciphertexts in order to build the final ciphertext. A cryptanalyst must break both ciphers to get any information. This will, however, have the drawback of making the ciphertext twice as long as the original plaintext.
Note, however, that a weak first cipher may merely make a second cipher that is vulnerable to a chosen plaintext attack also vulnerable to a known plaintext attack. However, a block cipher must not be vulnerable to a chosen plaintext attack to be considered secure. Therefore, the second cipher described above is not secure under that definition, either. Consequently, both ciphers still need to be broken. The attack illustrates why strong assumptions are made about secure block ciphers and ciphers that are even partially broken should never be used.
[/i]
Also:
[b]I ran the code through a few programs that analyze entropy via auto-correlation, the n gram results indicate a weak encryption, but one that results in highly entropic data (which I correlated against a similar data set size from a randomness extractor) when decoded via Hex, which I suspect is a secondary encode, as most encrypted data sent via communications is encoded in order to avoid corruption. This may have skewed the block size analysis done previously (resulting in 376bytes or 64bits).
Code:
Ā³+ļæ½:5ĀŗĆfW|$ĆOĆCFĆ1Ā§Ć
KĀø/Ć¾Ć "aWw?$y#Ć!ƶ,Ć.āĆĀ²gĀµEĀ«ĆĆĀÆaQ
NĆŖā”Ć3ĆĆ?q10ÅĆ(Ā“$=TĆ°DĆ¹ĆbāĆĀæĆ·9~CĀĖƦ2Ć
?ƤxĀ³Ā„O]ĆiuĆŗĆ·IāžbYZÅøcā¢ā=Ć >:Ā¬?8ÅEĆ»Āā¦Ć¾ā5AĆĆĘĖĆ²ĆĘ2ĀØ/Ćļæ½(bĆ¼ĆOƧƤj?Ć©QĆ
ĆĀ“dĆ£:Ā¹,āā .ā¹Ćā¢ĀĀø8ļæ½ĆyĀ¶?ƤĀ¢YāŗmHĆĀ¹SÅĆ®cāDĆ“aĀŗāĆ¤Ć¾u$,Ć?ĀQĆā¢QĖā”j|ĀŖĀ½{@I"A0Ā©fĆĀ³Ć9F:?~ĀÅ”7ĀŖā ?Ā²xĆ¼ā1ĆÅÅy~yā
@eFĀ²LÅ”bāŗ&Ć?Ć*KƤĀXÅ”7_Ć«sĆĀ«"\āÅĆøž)Ā²q3ā6G?Jā°(ĆĆĀTiÅ^[PgFƶvZo%ĆĀ¤Ć@Ć¾Ā¶e?E$i6ā¢Ė=Ć!Ć¦Ć»Ć¾Ć»ĀøZ)āāā¬6Ā„+][/b]
If the hex is a secondary encode, then perhaps we are focusing on the wrong data set. Perhaps this text output is what we should actually be focusing on. Most decryption methods would allot for a hex OR text input field, but perhaps this will fuel some thought.
EDIT:
Another thing:
Level 8 = OTR 4 - 128bit/256bit block cipher (AES or Rjindael or Twofish or Serpent)
Level 9 = OTR 5 - Cascaded Block Ciphers with salt (SHA 512 or Whirlpool etc)
Level 10 = OTR 6 - Cascaded Block Ciphers with salt and possible key file additions (to increase password strength)
He does not mention a salt for OTR 4āitās therefore technically possible that we could use rainbow table attacks to determine the key from bits of the code. In fact, Storm mentioned this himself:
The password will probably be hinted at, perhaps in a less than obvious way. We can assume this much as it is almost impossible to analyze a cipher text with only one message and nothing to confirm patterns. Once Iāve got a rough estimate of what mode/algorithm it uses, I can dedicate some run time to rainbow table attacks on possible key. I have a feeling this is a holding puzzle, designed to allow time to construct further aspects of the ARG or work on whatever is behind their NDA.
I seriously think that he was just bullshitting the whole way through, he probably thought that you knew who he was and decided not to help. AES rainbow tables are just too big, I donāt think they ever exist and much less be available to download.
The code in its text form is the HALOS code encoded with Microsoft-1252/ANSI. If we were to look into that code, that would mean that he padded the message with the hex bytes that have no representation in that encoding, but that would mean that he did not use a block cipher, because is impossible to control the output to not have bytes that are control characters in a certain encoding.
I had my suspicions, and I even relayed them to him at one point, yet he continued to offer helpful advice. Remember, it was his suggestion on the forum that we piece together the story of the ARGāsomething that has encouraged people to create many of the resources we now have on the Wiki page. I doubt he would have given me explicit answers, but his suggestion of a 256-bit or similar encryption methodology is probably spot-on. We simply have need of a key that is obvious enough to fit.
However, I do agree that if it is AES, a rainbow table is not appropriateāespecially 256-bit AES. Nonetheless, if it is not AES and there is no salt . . . technically possible.
Do you have an idea on what size the key should be?
Well, if itās AES, then 128, 192, or 256 bits. If weāre talking something more complicated like Blowfish or Twofish, it could be a pretty large range. Itās interesting to note that DES is based on the Lucifer algorithm, which relates to our clues (someone may have mentioned this, already). I doubt itās DES, as the key size is only 56 bits and someone has probably already tried to brute that. Itās possible that 3DES is our culprit, though.
EDIT: If it is 3DES, then we need 3 56-bit keys. They can be composed in the following manner:
Keying option 1: All three keys are independent.
Keying option 2: K1 and K2 are independent, and K3 = K1.
Keying option 3: All three keys are identical, i.e. K1 = K2 = K3.
Therefore, the key could technically be the same for all 3 applications of the algorithm. If weāre looking at 56-bit key sizes, which is 7 bytes, then itās entirely possible that our key is a 7-letter word. There could also be up to 3 individual, 7-byte keys.
Or, in this case, BENALOH, LUCIFER, so on and so forth.
This is all speculation, of course . . . .
Registered a new account because I forgot my old one, but Iāve been reading this thread recently, and just want to emphasize what this guy is saying. A few of you have noted the reoccurring use of the number 47. That number is a very very frequently reoccurring number in Star Trek in general, Iām not sure if anyone has noticed, so that makes this connection doubly strong.
Iām a big trekkie and have 47 in my common online name, as you may noticeā¦ though I actually didnāt realize until a few years laterā¦ that number really gets to you deep downā¦
21 into 1? 21 bytes?
If it was DES then the CIA could crack it really easily. 3DES with keying option 3 is DES, keying option 2 I donāt know, but I guess they canāt. Since the last bit in each byte is not used, we could have keys of 14, 16, 21 or 24 bytes for DES. For 14 and 21, we would need to turn the key to binary, and insert a bit after each seven bits. I think it was flavrans9 who proposed this long ago.
https://en.memory-alpha.org/wiki/47
quite a lot of data in that, more im portantly
Voyager - 7 Letters
Menosky - 7 Letters
the 47 Society - 7 Letters
When asked about the significance of the number, Rick Berman once joked, ā47 is 42, corrected for inflationā referring to 42 being āthe answer to the Ultimate Question of Life, the Universe, and Everythingā according to The Hitchhikerās Guide to the Galaxy by Douglas Adams.
also on the 47 Socierty Website, I went back to November 1998 ( the same month HL1 came out ) they noted in a episode of Voyager, Janeways access code which was 47 in hexadecimal code.
Okay, maybe this is stretching, or reaching, or already treadā¦ but what if 21 into 1 is telling us that we need to execute an XOR that would convert 21 into 1 before we can decipher the code.
If the ā21 into 1ā is interpreted as decimal numbers, then thatās XORing the Hex codes against the hexidecimal value 14. The resulting code is:
930B201A159AFD46775C04E16FE939266366F11187E56B980FDE23C002417757045903FC01D60CF4380EB1E3924795658BEACD8F2241712D6ECA3EA7ED13E7E7511110BCE4082E94041D3174D064D9EF42B6F99FD7195E63B0B85FC61223FA2DC4225893...Alternatively, the 21 into 1 could be interpreted as hex numbers itself, then itās simply XORing against the hex value 20. The results of this are:
A73F142E21AEC972436830D55BDD0D125752C525B3D15FAC3BEA17F436754363306D37C835E238C00C3A85D7A673A151BFDEF9BB167545195AFE0A93D927D3D365252488D03C1AA030290540E450EDDB7682CDABE32D6A57848C6BF22617CE19F0166CA7...Neither of these read as anything directly in ASCII, before anyone wastes time on that.
I was explaining how Paillier encrypted ciphertext might be divided up in blocks. Given the values of p and q we were working with, I calculated the block size to be 16 bytes.
Let me elaborate a bit on that.
This is what a DES key looks like on the bit-level:
[COLOR=āGreenā]kkkkkkk[COLOR=āRedā]p [COLOR=āGreenā]kkkkkkk[COLOR=āRedā]p [COLOR=āGreenā]kkkkkkk[COLOR=āRedā]p [COLOR=āGreenā]kkkkkkk[COLOR=āRedā]p [COLOR=āGreenā]kkkkkkk[COLOR=āRedā]p [COLOR=āGreenā]kkkkkkk[COLOR=āRedā]p [COLOR=āGreenā]kkkkkkk[COLOR=āRedā]p [COLOR=āGreenā]kkkkkkk[COLOR=āRedā]p
[COLOR=āGreenā]k = bits that make up the key material
[COLOR=āRedā]p = parity bits used for error checking (most DES implementations just ignore them)
Now, if the cipher really is DES (or 3DES in which case we have a set of two or three keys), and Storm factored in the use of the parity bits, then maybe we have to arrange the key material so that none of the bits in the key are wasted as parity bits.
There are several ways we can do this:
-
If we are starting with a 7, 14 or 21 byte key, we insert a parity bit after every 7 bits (going from left to right), which will give us an 8, 16 or 24 byte key that can be used with DES/3DES.
-
Say we have a password string, 8, 16, or 24 characters long, which is made up of ASCII characters with values < 128 (7-bit ASCII but uses all 8 bits). The leftmost bit (most significant bit) in each byte will be 0. So my idea is that we just remove this redundant bit and insert a bit in the parity bit position instead (for each byte of the key). The easiest way to do this is to bit rotate each byte of the password string one bit position to the left.
-
Same as in (2), except that instead of bit rotating, we reverse the bits, either one byte at the time, or the entire bit string of the password, so that the redundant ASCII bits land on the parity bit positions.
Maybe this is what the āSEND IN LEVEL SEVEN CASESā means: Use 7-bit ASCII as password input.
Well if the Send in Level Seven Cases means 7bit ASCII as the password, then the āIn case of emergenciesā use BENALOHPAILLIER in all caps as the password adjusting for the parity bits?
Iāve tried BENALLOHPAILLIER and congratulationsyouwonthe with the 7bit encoding and adding a bit at the end. No dice. The idea seems good though, what else do we have as possible keys with 16 or 24 characters.
maybe those extention codes that are wrote on the whiteboard?
Dr. J. D. Marcel - 1187.463
Anomalous Materials - 01433
Dr Horn (Biodome) - 186759
EDIT : Also Nobium V possibly?
From 0418_08151814ās PM to Gunsrequiem
āMacroscale Quantum Systems could relate to anything that uses quantum mechanics for a larger purpose.ā
Look at the sentence.
āMacroscale Quantum Systems could relate to anything that uses quantum mechanicsā makes total sense by itself so, why add āfor a larger purposeā to the end of it? Is that the hint that stormseeker refers to?
Is the ālarger purposeā the fact that the 24 character phrase Macroscale Quantum Systems is the key?
You might be on to something there.
If itās the key, itās not with 3DES-ecb, neither straight up, nor taking 7bits and adding the parity bit.
Edit: New theory, the HALOS code is homomorphically encrypted source code.
https://lesswrong.com/lw/3cz/cryptographic_boxes_for_unfriendly_ai/
Apparently, one of the schemes planned to interact with an AI that could be unfriendly, is to homomorphically encrypt the AI, that way, thereās no direct interaction with the exterior world.
This is a project in which they use homomorphic encryption to create secret software, in which thereās no way to look at the real source code.
Could anyone who is computer savy provided insight on this? Is it possible?
Iām not particularly sold on this being homomorphic encryption, because itās not mature. To be clear, Iām not dismissive of this as a theory, but if I were to rank it on a list of things to try, itād be close to the bottom.
Not that you have to be an expert on these things, but if you read up about this kind of encryption, youāll see the same thing in every bit of information out there: itās not mature, but itās a promising idea.
As far as Iām concerned, thinking in terms of a puzzle, homomorphic encryption breaking seems cruel. I think this might be akin to a rubikās cube; bit swapping, followed by ground-and-pound BS base128+ encoding, etc.
I think there might be a pun built into the supposed password to HALOS; benaloh paillier. The two words individually point to homomorphic encryption, but the first (benaloh) seems punny to me.
Iām posting a manual page from Linux (same for unix/mac os x) that describes what Iām talking about.
The benntoh call doesnāt actually exists. The calls are actually be16toh or be32toh.
Itās important to understand a clear technical point: x86 and x86-64 CPUās use the little-endian format.
Hereās the thing about DES and TDES (triple DES) algorithms: they expect MSB (big-endian) format. So, what if the bytes in HALOS were converted from MSB -> LSB or MSB -> PDP (middle-endian)
TL: DR; I wouldnāt rule out encryption as a theory, but our bits of data may have been jumbled intentionally which is why everything looks so screwy. We might need to convert this back to MSBā¦
Finally, keep in mind that if this is DES, you need a 64-bit key (8 bytes = 8 chars). Only 56-bits of that key are used, but the key needs to match the block size, which with DES is 64-bits. The password may be PAILLIER, or a variant of itā¦
May not be relevant, but the element number for silver is 47.