Base64 from commons-util

[Jon Stevens <jo...@latchkey.com>]

In BaseSecurityService.encryptPassword(), it first encrypts a password using
the scheme it is told to use (in my case SHA), it then calls the
commons.Base64 class to encode the results from the SHA encoding.

Previously, we were using another Base64 class in Turbine...I'm not sure
which one...

The old result of SHA+Old Turbine Base64 returned this string for the sha
encode/base64 of the String "1"...

    NWoZK3kTsExUV00Ywo1G5jlU

Now, with the commons Base64, I get this:

    NWoZK3kTsExUV00Ywo1G5jlUKKs=

As you can see, it has a few characters tacked onto the end of it.

So, is the bug in the old Base64 implementation or in the Common's base64
implementation?

-jon

P.s. Here is a little test program...

import java.io.*;
import java.lang.*;
import java.util.*;

import java.security.MessageDigest;

import org.apache.commons.util.Base64;

public class Test
{
    public static void main(String args[])
    {
        try
        {
            String password = "1";
            
            MessageDigest md = MessageDigest.getInstance("SHA");
            // We need to use unicode here, to be independent of platform's
            // default encoding. Thanks to SGawin for spotting this.
            byte[] digest = md.digest(password.getBytes("UTF-8"));
    
            // Base64-encode the digest.
            byte[] encodedDigest = Base64.encode(digest);
            System.out.println (encodedDigest == null ? null :
                    new String(encodedDigest));
        }
        catch (Exception e)
        {
        }
    }
}


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

Re: Base64 from commons-util

[Jon Stevens <jo...@latchkey.com>]

on 8/13/01 8:05 AM, "Dave Rolin" <da...@networkapps.com> wrote:

> Jon Stevens wrote:
> 
>> The old result of SHA+Old Turbine Base64 returned this string for the sha
>> encode/base64 of the String "1"...
>> 
>>     NWoZK3kTsExUV00Ywo1G5jlU
>> 
>> Now, with the commons Base64, I get this:
>> 
>>     NWoZK3kTsExUV00Ywo1G5jlUKKs=
>> 
>> As you can see, it has a few characters tacked onto the end of it.
>> 
>> So, is the bug in the old Base64 implementation or in the Common's base64
>> implementation?
> 
> Base64 takes 3 bytes (24 bits) at a time and maps them into 4 base64 "digits".
> Thus each base64 digit represents 6 bits.  If the bytes in the original data
> isn't a multiple of 3, padding is used on the last group (= is the pad
> character).  Thus, the size of the original data is always going to be:
> 
> (base64 size * (6/8)) - pad length
> 
> In the first example, the base64 string is 24 characters, and there is no
> padding.  Therefore, the original data must be 18 bytes:
> 
> (24 * (6/8)) - 0 = 18
> 
> The second example (commons base64) is 28 characters with one pad character,
> so
> the original data must be 20 bytes:
> 
> (28 * (6/8)) - 1 = 20
> 
> Since a SHA hash is always 20 bytes in size, it looks like the commons
> implementation is getting it right, and there clearly has to be a bug in the
> original base64 encoder you were using.
> 
> Dave.

Kick ass explanation and response!

Thanks!

-jon


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

Re: Base64 from commons-util

[Dave Rolin <da...@networkapps.com>]

Jon Stevens wrote:

> The old result of SHA+Old Turbine Base64 returned this string for the sha
> encode/base64 of the String "1"...
>
>     NWoZK3kTsExUV00Ywo1G5jlU
>
> Now, with the commons Base64, I get this:
>
>     NWoZK3kTsExUV00Ywo1G5jlUKKs=
>
> As you can see, it has a few characters tacked onto the end of it.
>
> So, is the bug in the old Base64 implementation or in the Common's base64
> implementation?

Base64 takes 3 bytes (24 bits) at a time and maps them into 4 base64 "digits".
Thus each base64 digit represents 6 bits.  If the bytes in the original data
isn't a multiple of 3, padding is used on the last group (= is the pad
character).  Thus, the size of the original data is always going to be:

(base64 size * (6/8)) - pad length

In the first example, the base64 string is 24 characters, and there is no
padding.  Therefore, the original data must be 18 bytes:

(24 * (6/8)) - 0 = 18

The second example (commons base64) is 28 characters with one pad character, so
the original data must be 20 bytes:

(28 * (6/8)) - 1 = 20

Since a SHA hash is always 20 bytes in size, it looks like the commons
implementation is getting it right, and there clearly has to be a bug in the
original base64 encoder you were using.

Dave.


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org