How secure is this one way encryption method?

Posted on 2005-05-04
Last Modified: 2010-04-11
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?

Question by:Errol Farro
    LVL 13

    Expert Comment

    >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!

    Author Comment

    by:Errol Farro
    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?

    Expert Comment

    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.
    LVL 13

    Expert Comment

    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.


    Author Comment

    by:Errol Farro
    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).
    LVL 13

    Accepted Solution

    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 (, 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

    IT, Stop Being Called Into Every Meeting

    Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

    Join & Write a Comment

    Phishing is at the top of most security top 10 efforts you should be pursuing in 2016 and beyond. If you don't have phishing incorporated into your Security Awareness Program yet, now is the time. Phishers, and the scams they use, are only going to …
    If you're not part of the solution, you're part of the problem.   Tips on how to secure IoT devices, even the dumbest ones, so they can't be used as part of a DDoS botnet.  Use PRTG Network Monitor as one of the building blocks, to detect unusual…
    Sending a Secure fax is easy with eFax Corporate ( First, Just open a new email message.  In the To field, type your recipient's fax number You can even send a secure international fax — just include t…
    In this seventh video of the Xpdf series, we discuss and demonstrate the PDFfonts utility, which lists all the fonts used in a PDF file. It does this via a command line interface, making it suitable for use in programs, scripts, batch files — any pl…

    733 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    19 Experts available now in Live!

    Get 1:1 Help Now