Encryptor improvement

[GoogleCodeExporter]

Hello, i wonder why IEncrypter use teo methods encrypt and decrypt? If use only 
encrypt and then during check encrypt user pattern and compare to supported 
encrypted string? In this case it is possible to use hash algorithms which make 
almost impossible to reverse it.

Original issue reported on code.google.com by azhilt...@gmail.com on 12 Apr 2014 at 6:06

[GoogleCodeExporter]

Hi,

I think an original string can be encrypted to different strings. So it's more 
secure then just hashing. Because hashing always produces same result for a 
given string.

For example with class SimpleWeakEncryption, input is "A", password is "B", 
salt is null. Calling encrypt() 2 times, we get 2 different encrypted strings:

    -ld4lkkipae8wdf3al8uj8w0s@-6zkytz4tyktmqskesr9ha2b8y
    -5tkyqn6t8zer7ilxperpfp5ee@61wloyv04eeajd5hev3r36ab8

http://docs.android-lockpattern.googlecode.com/hg/com/haibison/android/lockpatte
rn/util/SimpleWeakEncryption.html

Original comment by haibison...@gmail.com on 12 Apr 2014 at 5:28

[GoogleCodeExporter]

Hello, yeah i get your point. But what purpose of this library? It is to check 
if user set proper pattern or wrong. So main lock is pattern and this encrypted 
string used to check is it valid pattern. Check possible variants of breaking 
lock:
1) if attacker get our saved encrypted/hash string to get proper pattern he 
should decrypt it or revers hash, it is almost equals in terms of resources.
2) if attacker randomly try differents patterns, also no difference, the same 
encrypted string will be always decrypted into same value to check pattern, 
same with hash.
3) attacker can change stored values, with hash he set his known hash instead 
of user generated then use known pattern and unlock it, hovewer same thing he 
can use with encryption, he change password and encrypted pattern to his own 
generated. 

There is always same vulnurabilities in case of user authorization.

What you write is really matter for encryption of information, but not for 
lock/unlock. May be you know some attack where encryption definitly stronger 
than hash?

In my case to make encryption strong without such problems i use pattern only 
to get user password which then will decrypt some information, and not stored 
anywhere.

Original comment by azhilt...@gmail.com on 13 Apr 2014 at 12:35

[GoogleCodeExporter]

Oh I simply think that:

- It's easy to break a plain pattern. For example if a plain pattern is: 0-1-2, 
then the pattern is the combined of first 3 cells of the first row.

- It's a little harder to break a hash of a pattern.

- It's a little harder to break an encrypted pattern.

Attackers easily make a fake hash string. The app can't determine which SHA1 is 
made by itself, or which SHA1 is made by attackers. They're all SHA1's. But to 
make a fake encrypted string, the attackers need a little more time to reverse 
engineer the app source, to get the algorithm name, cipher name...

I know everything made by human can be broken by human. But I'd like to ask the 
attackers to use more time, that's my point  :-)  So I choose the hardest 
option *which I know*, which is encrypting/decrypting.

If you search the history, you'll see that at first I stored the pattern as its 
SHA1. Then I learned a little thing about cipher, so I switched to IEncrypter. 
One day if I learn something better than cipher, I'll switch to that thing. 
Because I don't do things halfway.

Also, IEncrypter leaves the security part to project's owner. If you need 
simpler option, please go ahead and make yourself one. The library is... open 
source. And about this library, I'm sorry  :-(  To protect my users, I use 
ciphers, not hashes.

Original comment by haibison...@gmail.com on 13 Apr 2014 at 1:26

[GoogleCodeExporter]

Original comment by haibison...@gmail.com on 13 Apr 2014 at 9:01

• Changed state: WontFix