Then maybe I'm misunderstanding something. But I can guarantee that MessageDigest.digest(), which returns an array of bytes, will NOT return an array of bytes every time that can be transmitted on a URL i.e. is a printable string. That's why it has to be encoded in some form, and two hex chars/bytes is the way this gets encoded.
However, if you really do want to undo the encoding, simply reverse the logic of the encode() method in the MD5Encoder.java file. Alternatively, if you are just trying to authenticate something in your code, it may work to just run through the digest and encode steps yourself, then compare your end result with what the user sent. If they're the same, then they're authenticated, without you needing to "undo" anything. Jay -----Original Message----- From: Alessandro Colantoni [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 22, 2006 12:37 PM To: Tomcat Users List Subject: Re: return (HexUtils.convert(md.digest())) in RealmBase Thanks for answer. I'm sure that the byte representation is printable, because that's a very easy algorithm, and it is working since some year storing correct encrypted password with the other application. What i should need is an inverse operation of the HexUtils.convert. Is there such an algorithm? I 'll explain better. Lets call this inverse operation convert_inv. It should be so that HexUtils.convert (convert_inv(myAlgorithm(myClearCredential)))=myAlgorithm(myClearCredential). So including convert_inv in myAlgorithm (while the other application follow with the original one) I solve my problem. Is it possible? Thanks for help Alessandro On 3/22/06, Jay Burgess <[EMAIL PROTECTED]> wrote: > > I think this is the right answer: > > digest() returns a sequence of bytes. Depending on the values of the > individual > bytes, if you were to try and convert it to String, you can end up with > non-printable characters, etc. > > I'm assuming that HexUtils.convert() turns each 4 bits of each byte into a > hex > character, so that you end up with a proper String representation of the > digest > that can be sent as part of a URL. > > Jay > > | Jay Burgess [Vertical Technology Group] > | http://www.vtgroup.com/ > > > -----Original Message----- > From: Alessandro Colantoni [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 22, 2006 12:12 PM > To: Tomcat Users List > Subject: return (HexUtils.convert(md.digest())) in RealmBase > > Hi All! > I saw that both method Digest(..) and digest(..) in RealmBase return ( > HexUtils.convert(md.digest())) and not just > md.digest().toString. > > My problem is that user table is maintained by another application > developed > in an other technology. > My application uses this table just to authenticate. > The password of user table is encrypted with an algorithm I've been done. > I wrote a MessageDigestSpi for that algorithm, I wrote my provider, I > registered it and everything looks work fine. > Except that of course if I do: > RealmBase.Digest(myCredentials,myAlgorithm); > > I get a result different from doing > MessageDigest md = MessageDigest.getInstance(myAlgorithm); > md.update(myCredentials.getBytes()); > md.digest().toString; > > but the same result of > MessageDigest md = MessageDigest.getInstance(myAlgorithm); > md.update(myCredentials.getBytes()); > HexUtils.convert(md.digest()) > > So the problem is that the other application stores without using the > HexUtils.convert method > but when tomcat authenticates it uses it. > > One solution could be write a Realm class that extends the JDBCRealm (the > one I'm using) and overwrite these methods. > But I'm afraid that in different versions of Tomcat (i don't want link to > one) could be different signature of these methods. > There's another solution? > At least avoiding overwriting these very important methods? > > And just for curiosity, why HexUtils.convert has been utilized? > > Thanks in advance for help and have a nice springtime > Alessandro > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
