I’m wondering if the capitalization style of “BenalohPaillier” is a reference to the “LEVELSEVENCASE” in the irc clue. That is, each word is 7 characters, and begin with upper case. Either way I’m still not getting anything useful from the openssl 3des.
I would like to point out that the actual solution to IRC clue 5 doesn’t contain any spaces at all. The tableau used with the running key cipher - the tabula recta - consists only of English alphabet letters (A-Z). Therefore, any other characters, like spaces and punctuation, will have to be ignored when enciphering/deciphering a message with this cipher.
The results are different because the Triple DES implementation in the PHP mcrypt library only performs three-key Triple DES and therefore expects a 24 byte key. If the key is less than 24 bytes long, it is padded with zeros. In order to perform a two-key Triple-DES encryption/decryption with mcrypt, just extend the 16 byte key with a copy of the first 8 bytes of the key, so that the first and the third DES key are the same. Example:
$key = "BENALOH PAILLIERBENALOH ";pyDes, however, will perform either two-key or three-key Triple DES depending on whether the key is 16 bytes (128 bits) or 24 bytes (192 bits).
Yes you are right. However I will need to take a break from this problem. I’ve spent too much time trying to figure this out opposed to my actual research at school. Maybe next week some time will open up.
I was trying to iterate over all openssl ciphers using variations of BenalohPaillier key and so far the only cipher that worked without any padding/block errors is: DES-EDE3-CBC (triple DES in CBC mode) with a key “benalohpaillierbealohpai” (192bit).
Though, this could be just a coincidence because the result is still a binary nonsense.
Decode result in Base64: qC+dWzDpT3CPQ7tCzH8qhMoJ+WNgXM4FLpegHA6j4QMg+ltn2aj/USelrGWF
oZjmzMT2QzvlcnOP9VRESNa9k3m8Bqv9BdmYer8IH4GwE1BHOToEm04LkaaU
kos9LTx1/aSr+IL+NrPLfsTjcT6mxy12svf8JgG/vuSUKr8Fk1+L1+f1aLHF
EYO6C2FA9VmWu874fErwsXRa8ObMHco/PhyhIACh9TpzP49/wLR9bLb8hFnq
4xQ2Rfbt44/4Ucf2j4LPK58BxW1Y4PTO/CynOuPWy6lWR+6HzV6BeYTjpX24
yELv0gKrs+aIi9B/UsXpWPHqoniMb5bkBvdE3p/UG/x1K9+WcH2DsQwsVtns
ytMicuLR2+7wr3cfPWvmMTMM1AhquFXQOdn30+vTdrVkwWouYe0Rkh3yiV5Q
gRknem2vnbV39OAFnXk6QDcrv6P9y8eytT04nXtihrzvUZyBI6ZNhm6uUoNl
r5uiLhOywGGMgDOi0+LS
And in hex: a82f9d5b30e94f708f43bb42cc7f2a84ca09f963605cce052e97a01c0ea3e10320fa5b67d9a8ff5127a5ac6585a198e6ccc4f6433be572738ff5544448d6bd9379bc06abfd05d9987abf081f81b0135047393a049b4e0b91a694928b3d2d3c75fda4abf8…
EDIT: dang, the output is 375 bytes, so that’s not a double block cipher for sure. and besides, openssl documentation says that there’s a quite high chance that some random key could pass a padding verification check.
FYI there’s a script I wrote using openSSL to test multiple ciphers:
https://forums.blackmesasource.com/showthread.php?p=522468#post522468
So, I take it the ARG is pretty much dead?
Seems that way, nobody’s been able to crack it and there’s nothing left to go on, so looks like the people working on it just gave up. Maybe the Xen release will give it some life.
Just to point out that brute forcing might be viable if it’s really necessary. Assumptions:
- DES in ECB mode (3DES won’t work)
- The key consists of 8 alphanumeric characters (or other alternatives described below), and is used directly as key input without key derivation
- The least significant bit of each byte is discarded
- DES key scheduling code is decently optimised, generating about 500,000 keys per second per modern CPU core (higher the better obviously)
- The correct plaintext consists of only printable characters (alternatively, without the most significant bit set)
The “raw” key input to DES has 8 bytes. There are only 62 alphanumeric characters. When their least significant bits are thrown away as parity bits, we’re left with 33 possible values for each byte. So the total number of keys to test is 33^8. With an octa-core CPU, each core generating 500,000 key per sec, the time to exhaust all the possible keys is 33^8 / 4,000,000 / 60 / 60 / 24 ≈ 4 days.
However if the key contains space, then there would be 34^8 keys to test, taking about 5 days. If the key contains NULL byte for padding, then we have 35^8 keys, 6 days to break. The best-case scenario is that the key contains only uppercase A-Z (14^8 possible keys). If this is true, then only 6 min is needed.
Correct me if I’m wrong.
Something I just noticed today, and I didn’t think anything of it until now; in Anomalous Materials, I heard an announcement I’ve never heard before, and didn’t write down. It was something along the lines of, “Dr. Horn: Report to Residue Processing tank 4.” I’ve searched the board and can’t find any other reference to this anywhere. Doubt if it’s signifigant, but it’s at least new. 
Has it been noted that “OTR//4.0” (see https://thepizzaisalie.wikia.com/wiki/Stormseeker%27s_Website) probably refers to the Off-the-Record protocol in version 4.0? https://www.cypherpunks.ca/otr/
Edit: Okay, yes, it has been noted. Should have used Google first (the forum-search failed, of course).
Edit 2: Just an idea, is on any of these servers an XMPP server running?
Another thing just spotted: on the Lab C sign in the Optronics lab, near the stairs, all the lab names are enclosed in [] brackets. Since we’re grasping at straws here, possible passphrase?
We’ve come very far with this. I’ve had to take some time off due to finals (again), but I’m officially done with this semester after April 26th. Once I return from a much-needed vacation to the beach, I will be back on this. If it was something very difficult, I imagine Stormseeker would have popped in and given us a hint somewhere along the line. Instead, I think we are simply missing something and for him to give us a hint would instantly lead us to the solution, which would obviously be against his best interests.
Either that, or this is the last puzzle, and whomever digs out the answer wins the gold . . . .
EDIT: Tried something different–converted the hex to binary and then converted the result to an image. Could be a fluke, but here it is: Hex to Binary Attempt
Well, it looks like a pattern all right…
Hmm… red stripes… Isn’t there a decal texture with red stripes? I’m just grasping at straws here, but maybe the .VMT for it has ‘extra’ content?
Good point–there is a texture file called “stripes_red01” in the materials folder. Don’t see anything on it, however. It is very similar to the binary image though . . . .
EDIT: There are also black and white versions of the stripes file, named accordingly. Unfortunately, it seems like a dead end, but it was definitely a solid guess.
No, it is a false pattern, just a warning before we head off too far to that dead end.
The reason you got dark strips marching across the image is the fact that you break the lines every 32 digits in your .txt file. The problem is when you’re breaking a line, for instance by tapping the Enter key, you’re actually introducing foreign characters into the data. These foreign characters are the famous “\r\n” (carriage return and linefeed characters) which are familiar to all Windows programmers.
Since you’re breaking every 32 digits, those two characters would repeat every 32 digits, hence the two dark blocks appearing consistently in the image. It is actually an introduced pattern due to not being careful in handling of data.
Ah, okay I see what you’re saying. Bugger . . . .
To be fair, it seems straws are all we have left.
Has anyone tried deCoding tHe Hex CipHer witH SHA-1? It’s a part of tHe OTR protoCol, and it takes a Hex input and a password.
(sorry about tHe random Caps, tHe C & H keys on my keyboard won’t work for some reason unless I Hold sHift)
SHA-1 is a hash function. It is not reversible.
Something I wanted to mention regarding the Benaloh / Paillier references in this ARG. It’s been mentioned before by someone on the forum that these two encryption systems are examples of homomorphic encryption. That said, I’m wondering if perhaps we have missed a step with the HALOS.txt file.
Granted, we correctly decoded the ASCII-85 text, yet were are having tons of trouble with the hexadecimal portion of the code–despite having various potential leads. One thing we’ve not considered is that the hexadecimal portion of the code may need to be shifted in some manner–for example, ROT-1 = rotate each input once. Granted, this is somewhat backwards thinking considering the input itself should be rotated, but perhaps some of the results we’ve been getting (from a one-time pad decrypter, for example) simply need to be shifted.
Anyway, just thought I’d throw it out there as some food for thought.