You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by "Henning P. Schmiedehausen" <hp...@intermeta.de> on 2002/07/03 00:06:29 UTC
Bug with MD5 encryption in Fulcrum (Who wrote this code?)
Hi,
while integrating the crypto service with security service in Fulcrum,
I noticed the following thing:
In Turbine 2 (and in all Code that I've seen and in the Crypto
Service), this is used to do Message Digest encryption:
--- cut ---
MessageDigest md = MessageDigest.getInstance(<encoding algorithm name>);
byte[] digest = md.digest(password.getBytes("UTF-8"));
ByteArrayOutputStream bas = new ByteArrayOutputStream(digest.length + digest.length / 3 + 1);
OutputStream encodedStream = MimeUtility.encode(bas, "base64");
encodedStream.write(digest);
return bas.toString();
--- cut ---
In Fulcrum this code is changed to:
--- cut ---
MessageDigest md = MessageDigest.getInstance(<encoding algorithm name>);
byte[] digest = md.digest(password.getBytes("UTF-8"));
byte[] encodedDigest = Base64.encode(digest);
return (encodedDigest == null ? null : new String(encodedDigest));
--- cut ---
Which is cool because it uses Commons but unfortunately delivers
different results! There is no information in CVS where this code
change comes from. :-(
In my test case, the first algorithm gives you:
MD5(Oeltanks) = XSop0mncK19Ii2r2CUe2
the second returns:
MD5(Oeltanks) = XSop0mncK19Ii2r2CUe29w==
Note that this is the same but "9w==" is attached. The problem must be
in the base64 encoding; if it were in MD5, the sums would be totally
different; not just some digits attached.
Unfortunately it is possible that both results are wrong: using perl
gives me:
% perl -e 'use Digest::MD5 qw(md5_base64); print md5_base64("Oeltanks");'
XSop0mncK19Ii2r2CUe29w
So I get the "9w" but not the "==".
Any Commons hackers around? It would be great to get the same result
as in perl...
I'm now a little reluctant to change the Cryptoservice over to the
Commons algorithm though I like it more than the Stream juggling in
the old one.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Bug with MD5 encryption in Fulcrum (Who wrote this code?)
Posted by Martin van den Bemt <ml...@mvdb.net>.
It seems like a padding issue. But who is wrong or right, I don't have
clue yet ;).. I can try to see how much I can find out tomorrow night.
(I must add my math isn't that good). If you cannot wait :
check out rfc1321, rfc2045 and rfc2046 to get a complete "overview" of
what is happening ;)
Mvgr,
Martin
On Wed, 2002-07-03 at 00:06, Henning P. Schmiedehausen wrote:
> Hi,
>
> while integrating the crypto service with security service in Fulcrum,
> I noticed the following thing:
>
> In Turbine 2 (and in all Code that I've seen and in the Crypto
> Service), this is used to do Message Digest encryption:
>
> --- cut ---
> MessageDigest md = MessageDigest.getInstance(<encoding algorithm name>);
> byte[] digest = md.digest(password.getBytes("UTF-8"));
> ByteArrayOutputStream bas = new ByteArrayOutputStream(digest.length + digest.length / 3 + 1);
> OutputStream encodedStream = MimeUtility.encode(bas, "base64");
> encodedStream.write(digest);
> return bas.toString();
> --- cut ---
>
> In Fulcrum this code is changed to:
>
> --- cut ---
> MessageDigest md = MessageDigest.getInstance(<encoding algorithm name>);
> byte[] digest = md.digest(password.getBytes("UTF-8"));
>
> byte[] encodedDigest = Base64.encode(digest);
> return (encodedDigest == null ? null : new String(encodedDigest));
> --- cut ---
>
> Which is cool because it uses Commons but unfortunately delivers
> different results! There is no information in CVS where this code
> change comes from. :-(
>
> In my test case, the first algorithm gives you:
>
> MD5(Oeltanks) = XSop0mncK19Ii2r2CUe2
>
> the second returns:
>
> MD5(Oeltanks) = XSop0mncK19Ii2r2CUe29w==
>
> Note that this is the same but "9w==" is attached. The problem must be
> in the base64 encoding; if it were in MD5, the sums would be totally
> different; not just some digits attached.
>
> Unfortunately it is possible that both results are wrong: using perl
> gives me:
>
> % perl -e 'use Digest::MD5 qw(md5_base64); print md5_base64("Oeltanks");'
> XSop0mncK19Ii2r2CUe29w
>
> So I get the "9w" but not the "==".
>
> Any Commons hackers around? It would be great to get the same result
> as in perl...
>
> I'm now a little reluctant to change the Cryptoservice over to the
> Commons algorithm though I like it more than the Stream juggling in
> the old one.
>
> Regards
> Henning
>
>
>
>
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
> INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
>
> Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
> D-91054 Buckenhof Fax.: 09131 / 50654-20
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>