-3

I had this idea while in health class to try to encrypt and decrypt strings using something irreversable; Random. The problem with encrypting data is that people can usually decrypt it from the final encrypted version. In my example I believe it is not possible, because the random number that represents the encrypted version uses a seed made by the hash of the original un-encrypted string to make it. It's not possible to take a number and figure out what seed was used to get it from a random as far as I know, so that should make this 100% un-decryptable. Can you guys tell me if there are any flaws in this before I put it to use if there is? Here's the code:

public static void main(String[] args)  {
    String hey1 = encrypt("hey");
    System.out.println(decrypt(hey1,"hey"));
    System.out.println(decrypt(hey1,"this won't work"));
}

public static String encrypt(String s) {
    return new Random(s.hashCode()).nextFloat()+"";

}

public static boolean decrypt(String encrypted, String original) {
    String encryptednew = encrypt(original);
    if (encrypted.equals(encryptednew))
        return true;
    return false;
}
Luiggi Mendoza
  • 85,076
  • 16
  • 154
  • 332
gopro_2027
  • 103
  • 1
  • 9
  • 1
    If you want no one to be able to decrypt your data, just delete it. – mattm Feb 26 '15 at 21:41
  • 1
    Encryption suggests that you can unencrypt it. What you are creating, if it cannot be restored to it's original, I believe is a hash. This can be useful for checking if a password is the same. – ThePerson Feb 26 '15 at 21:41
  • It's not encryption. It's hashing(and a bad one - not reproducible on next run, because same Objects can have different hashCodes in different executions). Your code is a bit confusing. Why does it say `decrypt` when it in fact just checks the hash? – NeplatnyUdaj Feb 26 '15 at 21:42
  • 2
    Encrypting a string by passing the "orignal data" as key is pretty... pointless? – dognose Feb 26 '15 at 21:42
  • possible duplicate of [Good Hash Function for Strings](http://stackoverflow.com/questions/2624192/good-hash-function-for-strings) – Alex Shesterov Feb 26 '15 at 21:42
  • You aren't encrypting anything, you're hashing it. There is no way to go from the result of `encrypt` to anything useful. –  Feb 26 '15 at 21:42
  • The default hash has an easily readable pattern and is easy to decrypt. so.... is this a good advanced hash? – gopro_2027 Feb 26 '15 at 21:43
  • I made the function called decrypt cuz i wrote it out on paper – gopro_2027 Feb 26 '15 at 21:43
  • It would be for something like if a user created an account and it saved the encrypted password and when they log in they check the encrypted password and then the one they typed – gopro_2027 Feb 26 '15 at 21:44
  • gopro: `s.hashCode()` can(and most propobably will) yield different result when you restart your program. – NeplatnyUdaj Feb 26 '15 at 21:45
  • One could get into an argument about how "cryptographically strong" random() is. There is also SecureRandom which is supposed to be much cryptographically stronger. *I* have no idea how one would reverse engineer random(), but if it was *impossible* there would be no need for a "better" function, so one might infer that it's possible. – Michael Podrybau Feb 26 '15 at 21:47
  • Your hash is a little worse than java's "hashcode" implementation on String. Why? You are using that to seed the random. Therefore it will return the very Same value, everytime the seed is equal, since you are allways using a NEW random object. hashCode returns a 64-bit long, your random generates a float (32 bit) out of it. Thus, you would have some long-inputs leading to the same random number, so your are generating less different hash-values. – dognose Feb 26 '15 at 21:48
  • 1
    `Random` is not actually very secure, by which I mean it's not actually that difficult to reverse, so no. – Louis Wasserman Feb 26 '15 at 21:49
  • Please, before you implement anything like this in any real system, read this question and answer: http://security.stackexchange.com/questions/211/how-to-securely-hash-passwords – Gray Feb 26 '15 at 21:54
  • I want to think Louis Wasserman and dognose for actually answering my question. All the rest of you didn't help one bit but criticize the obvoius – gopro_2027 Feb 27 '15 at 00:09
  • Also btw hash code will NOT I REPEAT NOT return different results. using this code, it always works even after restarting my pc `String hey1 = encrypt("hey"); if ("0.010719538".equals(hey1)) { System.out.println("Yes!"); }` – gopro_2027 Feb 27 '15 at 00:11
  • If this is for serious use, then use a proven [cryptographic hash function](http://en.wikipedia.org/wiki/Cryptographic_hash_function) instead of trying to craft your own. – Jesper Mar 24 '15 at 11:37

1 Answers1

3

Encryption suggests that you can unencrypt it. What you are creating, if it cannot be restored to it's original, I believe is a hash. This can be useful for checking if a password is the same, but not for sending secret messages.

Equally, this is "un-decryptable":

public String encrypt(String input){

    return "Boo";

}

This is true because given the String "Boo", you cannot tell what the input was. Creating a hash however is useful for passwords, and a hash is something which can be verified. For example, if a password is sent to a server, instead of storing the raw password, a hash is stored. Next time the password is sent to the server, it can calculate the hash and see if it's the same as the stored one. For a sensible level of security, salts are also needed, and that's something I would recommend looking up.

ThePerson
  • 3,048
  • 8
  • 43
  • 69