Ragnarok: About Ragnarok

Ragnarok is a program developed in Perl by Z. Bornheimer for the ANUBIS Package (yet to be released). Ragnarok was designed to create an encryption system to minimize hackers from maliciously installing/editing clients computer through the ANUBIS receptor (yet to be released).


In Ragnarok, there are a few terms we use.

  • Key
  • Code
  • Proof
We can explain Key, Code, and Proof together because that's how they work. These three things are derived from house and nuclear launch console metaphors. To prove your intentions to your house, you use your key to open the door and you then enter in a code in your alarm system. That generates proof that you are supposed to be there. With a nuclear launch console, you enter your key and punch in your code (in that order) to prove your intentions to the system. The Code is pointless without the Key. Hierarchically, the order is Key=>Code=>Proof. The Code cannot participate in generating the Key, but the Key DOES participate in generating the Code. The proof can not generate any aspect of the Key or Code, but the Key and Code are necessary to generate the Proof. For example, you wouldn't be in the house or be able to punch in your launch code if you didn't first use your key.


There are currently three forms of Ragnarok:

  • Perl Script (Object Oriented Implementation)
  • Perl Module
  • Web API
Further Documentation available on the page: Ragnarok: Documentation.

In the mean time, the Ragnarok.pm file contains POD (Plain Old Documentation), so if you run perldoc Ragnarok.pm, it will give you the documentation for the script.


Note: The following is completely hypothetical.

The average encrypted key length is 400 characters. The amount of time it would take to crack the encryption algorithm using brute force would approximately take 1.9 x 10^963 years on an average computer.

That is insane. No one will try to crack the algorithm because that would be foolish. What they can try to do is crack the key and code (also known as the username and password) using a dual bruteforce attack. A dual bruteforce attack simultaneously attacks to data fields. This means that instead of 64 character possibilities for each character you type, there are 128. This means that a 4 character password instead of having 64*64*64*64 = 16,777,216 possibilities, it has 128*128*128*128 = 268,435,456 possibilities. But, because each character is dependent on every other character, the amount possibilities may be different.

Note, this algorithm is conceptually impossible to crack. Think about this. If one were to say, "I am thinking of two numbers that add up to 5. What are they?" There are infinitely many possibilities of answers. The same concept has been applied to Ragnarok. Because the algorithm converts a number out of a certain range into that certain range by subtraction, one cannot know if the algorithm was always in that range of characters or if it took 5 iterations to get it there. Because of this lossy operation (you loose the original information), you cannot backtrack through the encryption process. This algorithm, therefore, cannot be cracked. Don't misunderstand. Although this algorithm cannot be cracked, faulty implementation can.

Something important to note, the calculation for the encryption algorithm to be cracked is based on the 2^3200 (400 characters at 8 bytes each). This is not to say that this is accurate in the slightest. It might be, but at the same time, the algorithm might not be decryptable at all because of cascading encryption or it might be more vulnerable because part of the encryption is consistent through each stage. It also might take longer because it was encrypted 13 times. The point is, this is a gross estimation and is designed to point out the only option dual bruteforce attack.

Note, this estimation is based on figures that will most-likely be obsolete in 2013 and is also inconsistent amongst computers. The time estimation is used strictly as a mechanism to describe the strength of the algorithm and nothing more.


Flaw 1: YOU

Remember, YOU are the security hazard. The strength of the encryption is weakened if you decide to use weak usernames and passwords...use strong passwords to minimize this flaw. Always use a secure password (we recommend at least 75% entropy...check at: http://www.passwordmeter.com/). As of version 0.6.1, we have implemented protection from a combination of SQL injection and a bruteforce attack. Now, the only attack we can foresee is a dual bruteforce attack (a bruteforce attack on two fields simultaneously). This attack, when using a secure password should prevent any access to the account for years on end thanks to cascading encryption.

Flaw 2: Implementation

Theoretically, this algorithm is uncrackable. It is incredibly lossy and encrypted data is simply unrecoverable. There are many moving parts and just because the algorithm is uncrackable doesn't mean that the implementation is uncrackable. If someone exploits perl, your website, your off-line application, or your operating system, they can find a way past Ragnarok. Remember the following for a summary of this concept: people don't need to break through a door if the window is wide open. Ragnarok is a led door conducting deathly electricity and laser-sighted auto-piloted guns...no one's getting in through the door, the window, on the other hand, is another story. Need help determining if your platform is vulnerable? Contact Zysys Support to set up a consultation.


Topic revision: r1 - 2014-12-14 - ZachBornheimer
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback