Crypt a QByteArray without external dipendences [Solved]
-
-
"how about that ":http://developer.qt.nokia.com/wiki/Simple_encryption
-
"qcryptographichash":http://doc.qt.nokia.com/4.7/qcryptographichash.html
I have read an explanation here in the forum, but cannot find it anymore. -
[quote author="koahnig" date="1306667191"]"qcryptographichash":http://doc.qt.nokia.com/4.7/qcryptographichash.html
I have read an explanation here in the forum, but cannot find it anymore. [/quote]For what I've read it isn't usable to crypt and decrypt text.
-
Yes, if you like to decrypt that will not work.
In case you want to decrypt and use with another application, you need to go with the simple encryption.
BTW: "here is the original thread ":http://developer.qt.nokia.com/forums/viewthread/4565/ -
[quote author="Luca" date="1306664168"]Hi all,
I need a very easy way to crypt a password in a text file and get it back when needed.The application should works in various Linux and Windows PC so I'd like to avoid the use of some external library for cryptographic function.
Some ideas? [/quote]
Yes: don't do that and use a password storage mechanism.
-
[quote author="peppe" date="1306745967"]
[quote author="Luca" date="1306664168"]Hi all,
I need a very easy way to crypt a password in a text file and get it back when needed.The application should works in various Linux and Windows PC so I'd like to avoid the use of some external library for cryptographic function.
Some ideas? [/quote]
Yes: don't do that and use a password storage mechanism.[/quote]
Does Qt supply a platform independent way to do that? Does it even exist on Windows? No, I didn't think so. By all means, if you are on KDE, use KWallet. But AFAIK, there is no cross platform solution for this (yet).
In the meantime, I think encrypting the login data, even if it is by using a weak encryption like my SimpleCrypt class provides, is a better solution than no solution at all.
[quote author="koahnig" date="1306667191"]"qcryptographichash":http://doc.qt.nokia.com/4.7/qcryptographichash.html
I have read an explanation here in the forum, but cannot find it anymore. [/quote]
A (cryptographic) hash is a one-way function for calculating a fingerprint of a piece of data. The whole purpose of the algorithm is to create a short code that can not be used to re-calculate the data it was calculated for, yet be as unique to that text as possible. It should be hard to construct two pieces of data that result in the same hash, even if those obviously exist.This function is not an encryption algorithm, though it can be used as a component in one. In SimpleCrypt, it is optionally used to validate if you are using the right key for decryption.
-
Luca - do you really need to store the password itself, or do you just want to be able to check if a password entered by the user is correct?
To be able to check if an entered password is correct you can use QCryptographicHash to create a hash from the original password, store the hash, and then compare the stored hash with a hash created from the password entered by the user. -
[quote author="ludde" date="1306750046"]Luca - do you really need to store the password itself, or do you just want to be able to check if a password entered by the user is correct?
To be able to check if an entered password is correct you can use QCryptographicHash to create a hash from the original password, store the hash, and then compare the stored hash with a hash created from the password entered by the user.[/quote]As I said in my first post:
[quote author="Luca" date="1306664168"]
I need a very easy way to crypt a password in a text file and get it back when needed.
[/quote] -
[quote author="Andre" date="1306747520"][quote author="peppe" date="1306745967"]
Yes: don't do that and use a password storage mechanism.[/quote]Does Qt supply a platform independent way to do that? Does it even exist on Windows? No, I didn't think so. By all means, if you are on KDE, use KWallet. But AFAIK, there is no cross platform solution for this (yet). [/quote]
What's the point in having the user inputting a password for decoding one, another, specific password?
-
Who said that that may be the chosen implementation? The application may choose to hard-code the key, or determine key in another way*. And, what is more, your question equally applies to services like KWallet. The point is that the user does not need to remember a load of different passwords for different services. That will make it easier for the user to use different, complex passwords for different services, thus strengthening the users security in the long run (one compromised service does not compromise the users credentials with other services).
*) And no, I am not claiming that using a hard coded key is very save practise. But then again, I also did not claim that SimpleCrypt provides strong cryptography.
-
[quote]Who said that that may be the chosen implementation? The application may choose to hard-code the key, or determine key in another way*. And, what is more, your question equally applies to services like KWallet[/quote]
My point doesn't apply to a wallet. The purpose of a password wallet is to store a whole set of passwords, not only one, using strong cryptography, proper memory locking, etc.
Encrypting only one password with another one using a simply cryptography scheme is simply nonsense (why don't you just ask it? And if the first one is a valuable password, then you should not use a simple encryption mechanism, so we go back to "use a proper wallet").
And it's even more nonsense if the second one is hardcoded or saved somewhere along the encrypted password (WHY using encryption at all then? You're giving away the cyphertext, the key and the algorithm).
-
[quote author="peppe" date="1306781108"][quote]Who said that that may be the chosen implementation? The application may choose to hard-code the key, or determine key in another way*. And, what is more, your question equally applies to services like KWallet[/quote]
My point doesn't apply to a wallet. The purpose of a password wallet is to store a whole set of passwords, not only one, using strong cryptography, proper memory locking, etc.
Encrypting only one password with another one using a simply cryptography scheme is simply nonsense (why don't you just ask it? And if the first one is a valuable password, then you should not use a simple encryption mechanism, so we go back to "use a proper wallet").
And it's even more nonsense if the second one is hardcoded or saved somewhere along the encrypted password (WHY using encryption at all then? You're giving away the cyphertext, the key and the algorithm).[/quote]
Peppe, suppose you have an application that need to connect to a DB (using username and password).
You have 2 possibilities:- ask the password to the final user
- keep the password in an external file and allow the application to get it
In the case 1 the user know the DB username and password so he also can use some db client (such as ACCESS) and do some direct operation to the DB table.
To solve (partially) this problem you can put the DB password in an external file and let the application to get it to connect to the DB.
But what if the user open this file? He has the DB password again to use ACCESS.
An intermediate solution is to crypt the password saved in the external file and hardcode the decrypt key in your application. -
... which is fine as long as you never fall for the illusion of security.
That approach is not secure and will only stop a very easy to frustrate attacker. That is fine, for as long as your database does not contain any data that makes it worthwhile to spend a couple of minutes with a debugger:-) That is independent of which encryption scheme you use: As long as you ship the key as part of your application the key is easy to retrieve for an attacker.
-
[quote author="Tobias Hunger" date="1306782974"]... which is fine as long as you never fall for the illusion of security.
That approach is not secure and will only stop a very easy to frustrate attacker. That is fine, for as long as your database does not contain any data that makes it worthwhile to spend a couple of minutes with a debugger:-) That is independent of which encryption scheme you use: As long as you ship the key as part of your application the key is easy to retrieve far an attacker.[/quote]
What solution do you suggest for a simple application?
-
There is no simple solution to security:-( It is always a compromise between "easy" and "secure". I am not saying that there are no scenarios where your suggestion does make sense (inhouse applications etc. where people are expected to behave -- they are bound by a contract anyway, etc.).
If you need to protect against the the user misbehaving then you are out of luck without hardware support.