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

x
• Status: Solved
• Priority: Medium
• Security: Public
• Views: 268

# 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.

example;

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

Formula;
31*0+105=105
31*105+110=3365
31*3365+102=104417
31*104417+105=3237032
31*3237032+110=100348102
31*100348102+105=3110791267
31*3110791267+116=96434529393
31*96434529393+121=2989470411304

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?

Thanks.
0
Errol Farro
• 3
• 2
1 Solution

Commented:
>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!
John
0

Author 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?
0

Commented:
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.
0

Commented:
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)

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.

John
0

Author 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).
0

Commented:
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. :)
John
0

## Featured Post

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