Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 268
  • Last Modified:

How secure is this one way encryption method?

Dear All,

I want to be sure how secure this one way password encryption method is.
The user enters a password which is between 5 and 31 digits long
and the following formula is used to encrypt the password;

31 * 0 + (decimal value of 1st digit) = A
31 * A + (decimal value of 2nd digit) = B
31 * B + (decimal value of 3rd digit) = C
31 * C + (decimal value of 4rd digit) = D    etc etc

and the last result (in this case D) is stored as the password.


password = infinity
Decimal values for digits; i=105, n=110, f=102, i=105, n=110, i=105, t=116, y=121


value stored in database = 2989470411304

How secure is this? How easy can someone decrypt this password?
Is this a secure enough system for a Banking Application?

Errol Farro
Errol Farro
  • 3
  • 2
1 Solution
>Is this a secure enough system for a Banking Application?
Which bank is this for so I can make sure not to put any money through? :)

Seriously though, there are enough tested encryption methods out there, why should you want to create something new? I can understand it as an exercise, but to use in a real application would be asking for trouble :).

And looking at your system: your numbers are growing by a fast rate - it won't scale to beyond the few characters (maybe you don't need more?). Have you looked into hash-functions? There's lots of good stuff out there!
Errol FarroAuthor Commented:
Thanks for your comments John but I really need a more specific answer to this. If I give you for instance 5 encrypted passwords, how fast can you decrypt this for me?
If its to be used commercially? Its too simple! You need something a lot more complex, you should use something like MD5.
not only that, you can't let users choose there passwords(to easily broken), how secure is the DB holding the passwords, can the encrypted passwords be seen/accessed?

As a practise algorithm its cool, chaining is nice, have to be in a loop.
The Lifecycle Approach to Managing Security Policy

Managing application connectivity and security policies can be achieved more effectively when following a framework that automates repeatable processes and ensures that the right activities are performed in the right order.

Just a short note, if you store your hash in a double-word (64 bits), you'll only have enough room for 12 digits (not the 31 you want). So your maximum password length just went to 12 digits.
- The length of your password is easily determinable (+/- factor of 31)

Your general password has the form:
31**n-1 * A + 31**n-2 * B + 31**n-3 * C ...
With the factors fix (if your leave your "code" of 31), it is a simple case of multiplication + addition to try all possible combinations. At the maximum length of 12 digits you have 64**12 combinations, approx 4.7 * 10**21. This would be brute forcing it. But I imagine there are possibilities to crack it digit by digit in a much shorter time. It would be a nice exercise :). In any rate, I wouldn't qualify it as a one-way-encryption, as you can restore the original password, even if it takes some time.

Errol FarroAuthor Commented:
John, thanks for your very detailed answer. Do you have an estimate how much it would take for someone to crack it using both methods (brute forcing & digit by digit).
Its hard to say, 10**21 combinations, each combination with 12 integer mutliplications and additions would lead us to the area of 10**22 integer operations. A P4 3.8Ghz claims 3783 MIPS (http://homepage.virgin.net/roy.longbottom/mips.htm#anchorIntel2), meaning we're looking at 2.6 * 10**12 seconds (83'000 years :)). This is for brute forcing, so that would be +/- ok, even if you have a distributed network of 1000 PCs. This is assuming your keep your factor of "31"

Regarding digit by digit cracking: You'd need to check this a bit betterto see how much work is necessary. I'm guessing you could do this with a linear workload depending on the number of digits (compared to the exponential workload for brute-forcing).

2 suggestions:
- Start your hash with a seed - some pseudo-prime number, anything special. This would not allow the hacker to guess the initial length.
- Instead of just multiplying the previous number, multiply and apply a moduo operator (i.e. next = (last * 31 + new) mod  (2**64 - 1)).  This would also help hide the initial length and is much harder to reverse-engineer.

Have you looked at the normal CRC algorithm? It's very similar. :)

Featured Post

Managing Security Policy in a Changing Environment

The enterprise network environment is evolving rapidly as companies extend their physical data centers to embrace cloud computing and software-defined networking. This new reality means that the challenge of managing the security policy is much more dynamic and complex.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now