Digest

>>Is this going to be compatible to other JVM's ?

In short yes. A digest generated in 1.5 will be the same as one generated in 1.4

No matter the JVM's ???


What have you say about the 1.3?
Is it going to work ??

Where you are able to use MessageDigest at all, the same algo should return the same digest of an identical source

Do you think that there is a problem because I save the digest as a string to the DB.

and then when I want to reconstruct it I read it as a UTF-8 and make the comparison ???

What you should probably do is save it as a String by saving the hex value of the array. Although there *should* be the same de/encoding procedures, i would not bank on it for ever, but also i don't like the idea of attempting to encode an array that may be entirely invalid as a UTF-8 String. Yet another reason to go hex is that you've got a human-readable representation of the hash value ready to hand. Obviously, make sure that 0-padding is used.

Please, give me an example.

ok One question
why do you
rawBytes[i] & 0xFF

filter the byte with & 0xFF

and what are u doing wihth the length ???
 if (s.length() == 1) {
                    // leading zero
                    sb.append('0');


Actually everything  :)
please

>>why do you  rawBytes[i] & 0xFF

Because bytes are signed in Java. You need to 'unsign' it and that's what that does.

>>and what are u doing wihth the length ???

As i mentioned, you need to 0-pad the result or you'll get varying lengths returned for a 32 bit digest, depending on the values contained in each element of the array

whats your problem exactly?

The problem objects is that the same algorithm works under the same JVM and specific under 1.3

but when you run it under other JVM (ver 1.4) then it doesn't.
I will try the CEHJ's way and I will tell you again what the result is

post the code you currently use to store and retrieve your digest.

sounds like you need to use Base 64 encoding. Lots of implementations around, even one from Sun.
Let me know if u need more info.

Base64 encoding is not a good idea. All it does is provide an encodable String from the digest. You can get the same effect by rendering the digest as a hex string *and* it's human readable without further decoding

Sorry, about my absence. ISP problems.

Problem has been solved CEHJ your code was perfect thank you.

Objects my I wanted to be difficult for somebody to read the passwprd from the DB and the Base64 is not the solution.

The algo is like this
1. take the curretn time
2. save the digest of the password  + currentime to a field
3. save current time to othe rfield as well.

Now when we want to check if the code is right we reconstruct the password in the opposite way:
1. read the timestap
2. Concatenate it with the password
3. Digest this
4. f it is the same with the one stored at the db then that's it The password is right otherwise it is wrong.\

That way there is no way to reverse the digest to see the password.
Except if somebody find a way to reverse a SHA-1 digest.

That's all my friends.

Talk u later

8-)

> Objects my I wanted to be difficult for somebody to read the passwprd from the DB and the Base64 is not the solution.

would have to disagree there
you're just reinventing the wheel really.

>>you're just reinventing the wheel really.

You're missing the point - it doesn't have to be encrypted twice and should be human readable

Sorry, that I haven't answered but I cannot see my Yahoo emails, I just think that you may have post a comment.

Now, to our subject.

--Objects--
Why am I reinveting the wheel ?
As far as I know Base64 does not use any key right ???
So everybody can read the pass + timestamp from the db right ???

Now, with the algorithm that we are talking about noboy can read the password unless he/she knows the keyword.

Only then he can make the same Digest, thus authenticated himself with the system.
Otherwise not.

Please ask me what is the point that you do not fully understand.

> As far as I know Base64 does not use any key right ???
> So everybody can read the pass + timestamp from the db right ???

No, you use Base64 to encode the digest into a string.

Ahh right. sorry objects. Now I have understoof what you mean by reinventing the wheel.

Yes you may be right although I haven't tried this.
Anyway seems that it works the way CEHJ post it to me and this is how we included it to our code.
No time for changes now.

Both ways are right and makes the job.

Thank you for the input objects.

No worries :)

u know where to find me when you have anymore questions.

Hey people could you please have a look. I think that I have posted this to the wrong category

https://www.experts-exchange.com/questions/20971967/Deploy-from-ANT.html

It is more Ant related

>>Ahh right. sorry objects. Now I have understoof what you mean by reinventing the wheel.

Then there are now two people here that have not got the point ;-) The point is, you don't generally want digests in a format that's not human-readable - it just makes things difficult. If you go to download sites that have proper implementations where they show the MD5 hash of the file, you don't get that in Base64, you get the String representation, so you can see what it is and use it and manipulate it more portably

Sounds like there just 1 who's missing the point here :D