OneWay hash encryption error in different Os.
-
Hello, When i am encrypting a string (One way hashed) using SHA algorithm, the output differs from two different platforms. When done in windows, an extra CR (CR LF) character is appearing but when done in linux box only LF character is appearing in between the output encrypted value. FYI - CR (enter) LF(Space) This leading me with issues in further process of application. Kindly help for the same Gowthami
-
Hello, When i am encrypting a string (One way hashed) using SHA algorithm, the output differs from two different platforms. When done in windows, an extra CR (CR LF) character is appearing but when done in linux box only LF character is appearing in between the output encrypted value. FYI - CR (enter) LF(Space) This leading me with issues in further process of application. Kindly help for the same Gowthami
-
This has nothing to do with encryption. The
CR LFsequence is set in Windows wherever the output string of aprintf()format contains the\ncontrol. In linux (and UNIX) it is replaced with a singleLF.Use the best guess
No it is not about the last character of string. see for example if i do one way hash for '1234567890127866' have a look on the outputs Windows: +zWcE7pR4k97ysyi54WS4G6J1Qjfp/tXllE23mMLCFBrIONMlrXyMw9aF1UCFKCFjbcz0Yzge78u(THIS IS THE PLACE WHERE I M GETTING CR LF)Usye+/4Ulw== Linux: +zWcE7pR4k97ysyi54WS4G6J1Qjfp/tXllE23mMLCFBrIONMlrXyMw9aF1UCFKCFjbcz0Yzge78u(THIS IS THE PLACE WHERE I M GETTING ONLY LF)Usye+/4Ulw== which means the whole characters represents single string
Regards Gowthami
-
Hello, When i am encrypting a string (One way hashed) using SHA algorithm, the output differs from two different platforms. When done in windows, an extra CR (CR LF) character is appearing but when done in linux box only LF character is appearing in between the output encrypted value. FYI - CR (enter) LF(Space) This leading me with issues in further process of application. Kindly help for the same Gowthami
See the answer to a question on StackOverflow: http://stackoverflow.com/questions/2620975/strange-n-in-base64-encoded-string-in-ruby[^]: "... add a newline for every 60th character ..." And see also http://en.wikipedia.org/wiki/Base64[^] That means that the new lines do not contain meaning, they are used for formatting purposes only. Before comparing the strings, you remove all types of newlines, and things will work fine (some decoders for base64 may require newlines, but since you need to compare hashed values only, that does not matter).
-
No it is not about the last character of string. see for example if i do one way hash for '1234567890127866' have a look on the outputs Windows: +zWcE7pR4k97ysyi54WS4G6J1Qjfp/tXllE23mMLCFBrIONMlrXyMw9aF1UCFKCFjbcz0Yzge78u(THIS IS THE PLACE WHERE I M GETTING CR LF)Usye+/4Ulw== Linux: +zWcE7pR4k97ysyi54WS4G6J1Qjfp/tXllE23mMLCFBrIONMlrXyMw9aF1UCFKCFjbcz0Yzge78u(THIS IS THE PLACE WHERE I M GETTING ONLY LF)Usye+/4Ulw== which means the whole characters represents single string
Regards Gowthami
-
I have just tried the same test and get a completely different result (
[B@1748ba4), so I can only assume that there is some more information that you have not given us.Use the best guess
meaning?? have you tried to encrypt the string in both windows and linux??
md = MessageDigest.getInstance("SHA-512");
md.update(plaintext.getBytes("UTF-8"));byte raw\[\] = md.digest(); String hash = (new BASE64Encoder()).encode(raw); return hash;This is what I have used to encrypt
-
meaning?? have you tried to encrypt the string in both windows and linux??
md = MessageDigest.getInstance("SHA-512");
md.update(plaintext.getBytes("UTF-8"));byte raw\[\] = md.digest(); String hash = (new BASE64Encoder()).encode(raw); return hash;This is what I have used to encrypt
-
See the answer to a question on StackOverflow: http://stackoverflow.com/questions/2620975/strange-n-in-base64-encoded-string-in-ruby[^]: "... add a newline for every 60th character ..." And see also http://en.wikipedia.org/wiki/Base64[^] That means that the new lines do not contain meaning, they are used for formatting purposes only. Before comparing the strings, you remove all types of newlines, and things will work fine (some decoders for base64 may require newlines, but since you need to compare hashed values only, that does not matter).
ok but my database is in linux machine, where the strings encrypted and saved to database, while i m running the same encryption util in linux the output is not matching with the database one. Meanwhile both places the code is same to encrypt the string.
-
saigowthami wrote:
meaning??
Meaning that all you showed us was the source data and the resulting hash value, we had no idea what code you had used.
Use the best guess
Ya i have posted my code in my previous reply itself
-
Ya i have posted my code in my previous reply itself
I cannot find
BASE64Encoderso cannot try recreating your problem. However, as Bernhard explained in this response[^], these extra line terminators are added when you convert the data to a string. Keep it as abyte[]and see if you still have the problem.Use the best guess
-
ok but my database is in linux machine, where the strings encrypted and saved to database, while i m running the same encryption util in linux the output is not matching with the database one. Meanwhile both places the code is same to encrypt the string.
Look: - before you store the value in the database, remove all newlines. - before you compare a value with a value from the db, remove all newlines. That works. Of course, you have to update your databse in case that you have some entries there already.