Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Password transformation for crypto app
Forum Updated to NodeBB v4.3 + New Features

Password transformation for crypto app

Scheduled Pinned Locked Moved General and Desktop
11 Posts 6 Posters 5.9k Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • M Offline
    M Offline
    Max13
    wrote on last edited by
    #1

    Hi everybody !

    I'm on a crypto app (http://qt.nokia.com/qt-in-use/ambassadors/project?id=a0F20000006MBBaEAO) using Qt.
    When you start TagPG for the first time, you're asked to create an "identity", which is a file containing some cipher information, like cipher name (aes, ...), hash name (sha1, ...), Initialization Vector used, and private key.

    The thing is, the user can input any type of password he wants (hdjs§!@58#$^%£ or ppp), and I want to transform it, in order to make it longer, and more complicated when encrypting with AES.

    Currently, I'm hashing the password with the hash name selected, and I'm using the hashed password (3 rounds) with the cipher, but for the generated RSA private key, 40 chars (Sha1) is too long for the passphrase (according to QCA, the crypto lib i'm using), so I have to take the first 20 characters.

    SO... Here is my question. Does anyone have an idea on how to correctly transform the user password, in order to get a 20 characters password/passphrase, which will also be enough cryptographic secure, either begining from a complicated typed pass, or from a simple pass like "ppp".
    Or, maybe my current method (using hashed password, and it's first 20 characters) is enough secure.

    Thank you for your help :)

    We all have started by asking questions. Then after some time, we can begin answering them.

    1 Reply Last reply
    0
    • G Offline
      G Offline
      goetz
      wrote on last edited by
      #2

      From a cryptographic view, the security chain is only as strong as the weakest link, and that is the password/passphrase typed in by the user. So, if you think that's strong and secure enought, take it. Everything else is just some additional voodoo/obfuscation, but adds no security!

      http://www.catb.org/~esr/faqs/smart-questions.html

      1 Reply Last reply
      0
      • M Offline
        M Offline
        Max13
        wrote on last edited by
        #3

        Ok thank you.
        And for the hash rounds. Is 3 or 4 enough, or do I have to increase it to 1000 or 2000 ?
        Some other crypto app does it, but I don't know if it's more secure or not... :/

        We all have started by asking questions. Then after some time, we can begin answering them.

        1 Reply Last reply
        0
        • G Offline
          G Offline
          goetz
          wrote on last edited by
          #4

          Sorry, I'm not that deep into cryptography. Just some general advice:

          I think you should read some good introduction into cryptography and security before you go on. Maybe some specialized forum or newsgroup can help you too. Cryptography is a delicate topic and, unfortunately, if you do it wrong you'll do more harm than help. So always check the advices twice before you take your decision.

          http://www.catb.org/~esr/faqs/smart-questions.html

          1 Reply Last reply
          0
          • M Offline
            M Offline
            Max13
            wrote on last edited by
            #5

            No problem.
            I not going on it without reading first ;)
            Recently I've changed my "identity" writing process, I've removed any "verification" data.

            So now, (for example) if you try to bruteforce it, you won't be able to see something readable. So the cracker can find the good one without knowing it.

            Anyway, I will also check specialized forum, thanks ;)

            We all have started by asking questions. Then after some time, we can begin answering them.

            1 Reply Last reply
            0
            • T Offline
              T Offline
              tobias.hunger
              wrote on last edited by
              #6

              You definitely should add a salt to make the passwords resistant against dictionary attacks. You need to store the salt along with the password of course:-)

              I'd also increase the number of rounds in the hashing. That does not improve the quality of the output, but it makes it more costly to brute-force the password.

              1 Reply Last reply
              0
              • M Offline
                M Offline
                Max13
                wrote on last edited by
                #7

                [quote author="Tobias Hunger" date="1312398468"]You definitely should add a salt to make the passwords resistant against dictionary attacks. You need to store the salt along with the password of course:-)

                I'd also increase the number of rounds in the hashing. That does not improve the quality of the output, but it makes it more costly to brute-force the password.[/quote]

                Hi !
                I've got an idea. Ok for the salt, this is what I do: "SaltPassPassSalt" then hash.
                And when creating an "identity" file, the user can see how much rounds can be done in 1 sec. And he will just have to choose how much he wants ^^'

                Isn't it a good idea? ;)

                We all have started by asking questions. Then after some time, we can begin answering them.

                1 Reply Last reply
                0
                • L Offline
                  L Offline
                  LinusA
                  wrote on last edited by
                  #8

                  This is all cool and well you're doing, but please keep one thing in mind: You can't make a weak password good! You can't add entropy to a password doing static transformations as you do. I think it's good, really, to obfuscate a password and maybe render existing rainbow table attacks useless. And of course, whenever you store a password's hash somewhere permanently, you need to add salt to protect it -- ok, that's well understood.

                  But by all means, don't get the impression that suddenly, because someone enters "123" as password, and you salt and hash it, the quality or security improves. This might be obvious, but I'm just saying.... If somebody is interested, they can generate rainbow tables or whatever, but the algorithm itself doesn't gain real security (all because of the initial password's low entropy!).

                  1 Reply Last reply
                  0
                  • R Offline
                    R Offline
                    raulgd
                    wrote on last edited by
                    #9

                    Also, I would recommend that you work your hash rounds like your salt, generate a random number of hash rounds and store them for each user if possible, that way each user has a different number of rounds for his hashes.

                    Raul Guerrero
                    http://jimi.mx

                    1 Reply Last reply
                    0
                    • T Offline
                      T Offline
                      tobias.hunger
                      wrote on last edited by
                      #10

                      Raul: What good is having a random number of rounds?

                      The rounds of hashing is done to make checking the password more expensive, which makes brute-forcing it harder.

                      Varying the number of rounds (which needs to be saved alongside the password/salt) will only enable an attacker to concentrate on those that are easiest to pry open.

                      1 Reply Last reply
                      0
                      • A Offline
                        A Offline
                        andre
                        wrote on last edited by
                        #11

                        Personally, I don't see the point in allowing passwords with little entropy at all. No matter how much you salt, hash, resalt and rehash these passwords, they are still insecure. I am not the first one to remark this, but I can not stress it enough. See LinusA' s answer.

                        I would simply stimulate the user to select a password that provides sufficient strength.

                        !http://imgs.xkcd.com/comics/password_strength.png(xkcd on password strength)!

                        (Image from xkcd.com)

                        1 Reply Last reply
                        0

                        • Login

                        • Login or register to search.
                        • First post
                          Last post
                        0
                        • Categories
                        • Recent
                        • Tags
                        • Popular
                        • Users
                        • Groups
                        • Search
                        • Get Qt Extensions
                        • Unsolved