Hi !
I'm lost. Sorry.
I don't understand when you say
>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.
I will try to explain better what I have done
I have an algorithm called manolo (from the name of the manager of the other
application that passed it to me).
I wrote a class
public class ManoloMessageDigestSpi extends MessageDigestSpi implements
Cloneable
I have in this class the field
private byte[] digest = null;
I implemented the method engineDigest:
protected byte[] engineDigest(){
byte[] completedDigest=this.digest;
engineReset();
return completedDigest;
}
in the engineUpdate(byte input) I just set the field digest with the
encrypted value of input using the manolo algorithm.
I wrote a Provider called ManoloProvider
public final class ManoloProvider extends Provider{
public ManoloProvider() {
super("manolo", 1.0, "algoritmo pasado por Manolo el 21-03-2006");
put ("MessageDigest.manolo","
com.steria.tc.security.ManoloMessageDigestSpi");
}
}
Then in a servlet that load on startup I do something like that
Security.addProvider(new ManoloProvider)
In the context.xml of my application I put
<Realm className = "org.apache.catalina.realm.JDBCRealm"
digest="manolo"
.....
....
/>
When The other application(developed in power builder) store a password
use the manolo algorithm to encrypt it. So what it stores is the same value
of
MessageDigest.update(cleartext);
MessageDigest.digest().toString().
So let's call:
cleartext : password in cleartext
digested : password encrypted
converted: digested converted with HexUtils.convert
At the end, when Tomcat authenticates it will compare converted with
digested and always fail.
Everything work fine if was my application to store password, storing
RealmBase.Digest(cleartext,manolo)
Thanks for attention
Alessandro
On 3/22/06, Jay Burgess <[EMAIL PROTECTED]> wrote:
>
> 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]
>
>
