Jump to content

TheHiddenSpectre

New Member
  • Content count

    2
  • Divinium

    100 
  • Joined

  • Last visited

  • Time Online

    42d 14h 24m 51s

Community Reputation

0

About TheHiddenSpectre

  • Rank
    Human

Profile Information

  • Gender
    Male
  • Location
    Wisconsin, USA
  • PSN
    TheHiddenSpectre
  1. Sorry for the late reply, but better late than never. Right? While I'm not saying that it isn't possible to automate the cracking of an xor key, you are probably going to run into trouble. First, base64 has 64 possibilities for each character of the key. Given an assumed max key length of 10, there are 64^10 possibilities of a key. That's 1.152 quintillion possibilities for a key. If I did my math correctly, if you assume each key check takes 10ms, it would take over 365 million years to finish the task. Secondly, an issue with xor keys is that they have a tendency to allow for any possible resulting text. For example, let's say I want to hide the word "CATS". I want to use the key "DOGS" to encrypt the message. The result after an ASCII xor would be 0x07 0x0E 0x13 0x00. If you were given such a cipher text, you could apply "CATS" as a key and you would get "DOGS" as a result. Basically, the xor operation is reversible in multiple ways, so you wouldn't know if "CATS" is the key of if "DOGS" is the key, since they both produce the other. Take that to a larger scale, and you end up with a message with "Perfect Secrecy." See: https://en.wikipedia.org/wiki/One-time_pad#Perfect_secrecy In the end, you would have a hard time sorting through the results because so many would contain potential plaintext messages.
  2. I've been trying to do some analysis on the cipher titled undercroft_paper_torn. Transcription: OkEeZHnifuMdYB1IbHyAfb0g2FJzrVmfkKcSbKrpQGvhQ0/bvu76RdnGy/WtT7T3 Obviously, this doesn't convert from base64 to ASCII. The analysis I've completed so far has assumed that this is indeed ASCII encoded as base64. What I've found is that there is no way for the current base64 characters to convert to a clean set of ASCII characters, no matter the transposition method. Therefore, there must be some sort of substitution or other method of hiding the true base64 encoding. The substitution might lead to a transposition, but as it stands, I don't believe that transposition is the first step to solving this cipher. At least it's some sort of progress. Here is the Google spreadsheet that I completed my analysis in. The main results are in the table titled "Possible ASCII." undercroft_paper_torn in Google Sheets For those interested in my analysis, I explain it below. Since I assumed that the cipher text is base64 encoding (it is still possible that it is not an encoding, but possibly a substitution cipher instead), I was only concerned with the process to convert base64 characters to ASCII characters. In this process, a base64 char (6-bits in length) is combined with multiple other base64 chars to create a sequence of ASCII chars (8-bits in length). Since the length of both encoding types differ (6 vs 8), there is a least common denominator between them. That is 6 * 8 = 24. Therefore, to wholly convert base64 chars to ASCII chars, we need 24 bits of data on each side. This means that 4 base64 chars are needed (4 * 6 = 24) and will convert into 3 ASCII chars (3 * 8 = 24). These 4 base64 chars will be nicknamed a four-tuple in my explanation. In this four-tuple, each char gives a part of itself to an ASCII char. For char #1, all six bits are used in ASCII char 1 (nicknamed A1). These six bits form the six most-significant-bits (MSb) of A1. To complete A1, the next char in the four-tuple, #2, uses its 2 MSb to complete A1. This continues on down the four-tuple until all 3 ASCII chars have been formed. The formation would look something like this: #1 #2 #3 #4 1 0 1 0 1 0 || 1 0 1 0 1 0 || 1 0 1 0 1 0 || 1 0 1 0 1 0 1 0 1 0 1 0 1 0 || 1 0 1 0 1 0 1 0 || 1 0 1 0 1 0 1 0 A1 A2 A3 The goal of this conversion to form an ASCII text that is readable in some sort of common language. This means that the ASCII characters seen on this table are valid if they are expected to be used in a message. This means that ASCII chars 0 - 31 are pretty much off limits (ASCII 10 and 13 have gotten some notoriety in Rev's other ciphers). Therefore, the valid range of ASCII values that I've used is 32-127 (the DEL char is still used since it makes the analysis easier). Now that we have a limit on the output chars, we can impose rules on the input chars. These rules are applied to the base64 value that is assigned to each char, as seen in this base64 table. The criteria for each char in a base64-to-ASCII four-tuple are as follows: #1: Bit 5 must be '0', therefore the value must be less than 32. Either bit 3 or 4 must be a '1', therefore the value must be greater than or equal to 8. #2: Bit 3 must be '0', therefore #2 modulo 16 / 8 must be less than 1. Either bit 1 or 2 must be a '1', therefore #2 modulo 4 must not be 0. #3: Bit 1 must be '0', therefore #3 modulo 4 / 2 must be less than 1. #4: Not limited by any exclusive criterion. #3 and #4: Either bit 0 of #3 or bit 5 of #4 must be a '1'. This causes some issues for determining char position in the four-tuple, but my analysis doesn't consider this possibility show that this cipher cannot be converted to ASCII. The above criteria may seem to be worded a bit strangely, since I was doing my analysis in a spreadsheet. If I were programming this analysis in something like Python, I would use bitwise operations to demonstrate the criteria. If we subject the cipher text to these rules, we can limit which chars are used in #1, #2, and #3. We cannot do the same for #4, since any base64 value will be valid in the fourth four-tuple position--validity is conditionally based upon the previous char value. Once we have determined which chars are valid for #1, #2, and #3, we have a set of chars left over. By process of elimination, these remaining chars are ONLY valid for #4. Knowing which chars can only be used in #4 is really informative for our purposes. The reason for this is that each ASCII char is 8 bits, but since bit 7 is always 0 in our standard ASCII set (not including extended ASCII set), we reduce an ASCII char to variations on 7 bits. Since #4 will always form the six least-significant-bits for A3, we now have a lot of information about A3 and we are only missing one bit, bit-6. If we look at the possibilities for A3, we can find two possible ASCII chars (bit-6 is either a '0' or '1'). Let's look at an example from the cipher. 'u' is the 10th char and through my process of the four-tuple criteria, I have determined that this char is only available in the #4 position. Looking at the base64 value for 'u', 46 = 0x2E, I can look at the ASCII table and determine that it is either '.' (46 = 0x2E -> bit-6 is '0') or 'n' (110 = 0x6E -> bit-6 is '1'). Now, '.' or 'n' is a pretty good set of possible letters for a message. The cipher text is 68 chars long which means that it can be 48 ASCII chars long after a conversion. That is a pretty short message, considering that the previous sentence I wrote was 99 ASCII chars long. In the cipher text, there are two occurences of 'u', which means that there is a good chance that both are not '.' but maybe one or both are 'n' instead. This is all fine, until you get to the char like '7' in the cipher text. I have also deduced that this char is a #4 only char. Unfortunately, the two possible ASCII chars that this char could convert into are ';' or '{'. Neither of these are remotely likely to occur in a message. Also, '7' occurs twice in the cipher text, even further reducing the likelyhood that this cipher text is just a transposition away from a base64-to-ASCII conversion. Another example is the char '/' which can convert to '?' or DEL. Seeing as there are two '/' occurences, and the fact that it would be uncommon that there are two question marks in a message further adds to the mystery. When I look at all of the evidence discovered, I find it VERY unlikely that this cipher text can be converted directly into ASCII through means of transposition (reordering chars). One thing that seems to hint at a substitution method are the last four chars in the cipher text. In many other Rev ciphers, the cipher ends with 13 10. Assuming that this is decimal, it converts into ASCII as CR LF. CR LF is a common type of line ending symbol(s) in text files. Now, T7 and T3 kind of strikes a similar appearance to 13 10, but 7 and 3 are 4 apart rather than 3. Therefore, it's not a simple subtitution like ROT13. What I find interesting is that while 13 and 10 are 3 away, the letters r and n are 4 away. Here, I am replacing CR LF with the programming version of these line endings "\r" and "\n". A programmer would use both of these to indicate a CR LF line ending in a program's code. This bears a closer resemblence to T7 T3 seen in the cipher text. While I haven't come any closer to determining a substitution used, having a crib (jargon for a cipher-to-plain text hint), albeit small, can help a long ways towards solving a cipher.
×