MD5 Message Digest question

Hello,

I understand that the MD5 Message Digest algorithm takes as input a message
of arbitrary length and produces as output a 128-bit ``fingerprint'' or
``message digest'' of the input.

The output representation could be:
- A binary digest will be 16 bytes long.
- A hex digest will be 32 characters long.
- A base64 digest will be 22 characters long.

***I choose to use the base64 digest for some reason.***

Note: According to RFC 2045(page 24), Base64 encoding uses characters A-Z,
a-z, 0-9, +, /, and =.

But one thing I don't understand here. When I printed out the md5 encrypted
message in Base64 format, to my surprise, in addition to the Base64 char, I
also find a "." char.

For example, the md5_encrypted_base64_format = "Dp8.E4JGpg7rKxQa49BF9/"
When looking carefully, there is a "dot" in the 22 char base64 encrypted
string.

Why? Can anyone tell me why? Other than the "dot" char, do I expect more
non-Base64 char? I need this info to build my regular expression for base64
format.


Thanks,
Kian

On 2004-12-03, Kian Goh wrote:
> Hello,
>
> I understand that the MD5 Message Digest algorithm takes as input a message
> of arbitrary length and produces as output a 128-bit ``fingerprint'' or
> ``message digest'' of the input.
>
> The output representation could be:
> - A binary digest will be 16 bytes long.
> - A hex digest will be 32 characters long.
> - A base64 digest will be 22 characters long.
>
> ***I choose to use the base64 digest for some reason.***
>
> Note: According to RFC 2045(page 24), Base64 encoding uses characters A-Z,
> a-z, 0-9, +, /, and =.
>
> But one thing I don't understand here. When I printed out the md5 encrypted
> message in Base64 format, to my surprise, in addition to the Base64 char, I
> also find a "." char.
>
> For example, the md5_encrypted_base64_format = "Dp8.E4JGpg7rKxQa49BF9/"
> When looking carefully, there is a "dot" in the 22 char base64 encrypted
> string.

Oh? Really? I've just tested md5sums of many different files (> 25000)
and found none giving such result. Maybe implementation of Base64
algorithm you use is broken? Can you give the string that produces such
funny results?

> Why? Can anyone tell me why? Other than the "dot" char, do I expect more
> non-Base64 char? I need this info to build my regular expression for base64
> format.

You shouldn't expect dot in B64. You need not to rebuild regexp, you
need rebuild B64 implementation, I think.

--
Stanislaw Klekot

In article <coq6c2$hrn$1@zcars0v6.ca.nortel.com>,
"Kian Goh" <kiangoh2700544@hotmail.com> wrote:

>I understand that the MD5 Message Digest algorithm takes as input a message
>of arbitrary length and produces as output a 128-bit ``fingerprint'' or
>``message digest'' of the input.

Nobody should be using MD5 or SHA-1 for any new development. Think of
them as supported only for backward-compatibility purposes. For new
development, I'd suggest something like RIPE-MD160.

>***I choose to use the base64 digest for some reason.***
>
>Note: According to RFC 2045(page 24), Base64 encoding uses characters A-Z,
>a-z, 0-9, +, /, and =.
>
>But one thing I don't understand here. When I printed out the md5 encrypted
>message in Base64 format, to my surprise, in addition to the Base64 char, I
>also find a "." char.
>
>For example, the md5_encrypted_base64_format = "Dp8.E4JGpg7rKxQa49BF9/"
>When looking carefully, there is a "dot" in the 22 char base64 encrypted
>string.

Doesn't look right. I think you're stuffing up the Base64 encoding
somewhere. Just for fun, when I decode the above string and re-encode it
with my own Base64 tool, I get

Dp8E4JGpg7rKxQa49BF9DQ==

Kian Goh wrote:

> I understand that the MD5 Message Digest algorithm takes as input a
> message of arbitrary length and produces as output a 128-bit
> ``fingerprint'' or ``message digest'' of the input.
[snip]
> ***I choose to use the base64 digest for some reason.***
>
> Note: According to RFC 2045(page 24), Base64 encoding uses characters
> A-Z, a-z, 0-9, +, /, and =.
[snip]
> For example, the md5_encrypted_base64_format = "Dp8.E4JGpg7rKxQa49BF9/"
> When looking carefully, there is a "dot" in the 22 char base64 encrypted
> string.
>
> Why? Can anyone tell me why?
[snip]

This is not a question about MD5; it is a question about some unspecified
software that converts MD5 output into a format that you expect to conform
to RFC 2045. What software is performing that conversion?

--
Peter Pearson
To get my email address, substitute:
nowhere -> spamcop, invalid -> net

On 2004-12-04, Lawrence D¹Oliveiro wrote:
> In article <coq6c2$hrn$1@zcars0v6.ca.nortel.com>,
> "Kian Goh" <kiangoh2700544@hotmail.com> wrote:
>
>>I understand that the MD5 Message Digest algorithm takes as input a message
>>of arbitrary length and produces as output a 128-bit ``fingerprint'' or
>>``message digest'' of the input.
>
> Nobody should be using MD5 or SHA-1 for any new development. Think of
> them as supported only for backward-compatibility purposes. For new
> development, I'd suggest something like RIPE-MD160.

Why? Because of recent collisions? AFAIR for RIPE-MD160 there were
collisions found, too. And I can't recall if there were found collisions
for SHA-1, not for SHA-0. Can you give me a link? Google says nothing
about to me.

>>***I choose to use the base64 digest for some reason.***
>>
>>Note: According to RFC 2045(page 24), Base64 encoding uses characters A-Z,
>>a-z, 0-9, +, /, and =.
>>
>>But one thing I don't understand here. When I printed out the md5 encrypted
>>message in Base64 format, to my surprise, in addition to the Base64 char, I
>>also find a "." char.
>>
>>For example, the md5_encrypted_base64_format = "Dp8.E4JGpg7rKxQa49BF9/"
>>When looking carefully, there is a "dot" in the 22 char base64 encrypted
>>string.
>
> Doesn't look right. I think you're stuffing up the Base64 encoding
> somewhere. Just for fun, when I decode the above string and re-encode it
> with my own Base64 tool, I get
>
> Dp8E4JGpg7rKxQa49BF9DQ==

But what string have you obtained? Is it really the same as string used
to get "Dp8.E4JGpg7rKxQa49BF9/"?

--
Stanislaw Klekot

Hello,

Thanks for all responses.

> This is not a question about MD5; it is a question about some unspecified
> software that converts MD5 output into a format that you expect to conform
> to RFC 2045. What software is performing that conversion?

This code is part of the PAM Linux modules. There is a method crypt_md5
calls function to64 to take care of the base-64 conversion.
It ends up appending 22 characters to the encrypted string.

At first, I thought there is a bug in the code. I spend quite a bit of time
searching in Google for an example of 22 char encrypted representation. By
luck, I also found the same thing in Cisco website.

Ok. I don't know Cisco product. But here is the one line capture:

"enable secret 5 $1$feb0$a104Qd9UZ./Ak00KTggPD0 "

But, I recognize "$1$feb0$" is the salt string, and the
"a104Qd9UZ./Ak00KTggPD0" is the 22 char base64 md5 encrypted string.
When looking carefully, there is ALSO a "dot" in the 22 char base64
encrypted string.

http://www.cisco.com/en/US/products/...c.html#1026096

A bug? or a feature?

Thanks,
Kian


"Kian Goh" <kiangoh2700544@hotmail.com> wrote in message
news:coq6c2$hrn$1@zcars0v6.ca.nortel.com...
> Hello,
>
> I understand that the MD5 Message Digest algorithm takes as input a
message
> of arbitrary length and produces as output a 128-bit ``fingerprint'' or
> ``message digest'' of the input.
>
> The output representation could be:
> - A binary digest will be 16 bytes long.
> - A hex digest will be 32 characters long.
> - A base64 digest will be 22 characters long.
>
> ***I choose to use the base64 digest for some reason.***
>
> Note: According to RFC 2045(page 24), Base64 encoding uses characters
A-Z,
> a-z, 0-9, +, /, and =.
>
> But one thing I don't understand here. When I printed out the md5
encrypted
> message in Base64 format, to my surprise, in addition to the Base64 char,
I
> also find a "." char.
>
> For example, the md5_encrypted_base64_format = "Dp8.E4JGpg7rKxQa49BF9/"
> When looking carefully, there is a "dot" in the 22 char base64 encrypted
> string.
>
> Why? Can anyone tell me why? Other than the "dot" char, do I expect more
> non-Base64 char? I need this info to build my regular expression for
base64
> format.
>
>
> Thanks,
> Kian
>
>

On 2004-12-06, Kian Goh wrote:
>> This is not a question about MD5; it is a question about some unspecified
>> software that converts MD5 output into a format that you expect to conform
>> to RFC 2045. What software is performing that conversion?
>
> This code is part of the PAM Linux modules. There is a method crypt_md5
> calls function to64 to take care of the base-64 conversion.
> It ends up appending 22 characters to the encrypted string.
>
> At first, I thought there is a bug in the code. I spend quite a bit of time
> searching in Google for an example of 22 char encrypted representation. By
> luck, I also found the same thing in Cisco website.
>
> Ok. I don't know Cisco product. But here is the one line capture:
>
> "enable secret 5 $1$feb0$a104Qd9UZ./Ak00KTggPD0 "

Looks like *nix MD5 shadowed password.

> But, I recognize "$1$feb0$" is the salt string,

Actually, "feb0" is the salt. "$1$" tells that we're dealing with MD5
shadowed password.

> and the
> "a104Qd9UZ./Ak00KTggPD0" is the 22 char base64 md5 encrypted string.
> When looking carefully, there is ALSO a "dot" in the 22 char base64
> encrypted string.

I don't think that it is B64. My `man crypt' don't even mention about
B64.
http://techpubs.sgi.com/library/tpl/...tml&srch=crypt
The same shorter: http://tinyurl.com/3qmed

> http://www.cisco.com/en/US/products/...c.html#1026096
>
> A bug? or a feature?

Feature. By the way, do you see there any word about base64?

--
Stanislaw Klekot

Thank you.

I think I should use [a-zA-Z0-9./] instead of [a-zA-Z0-9/+=]

> By the way, do you see there any word about base64?
Yes, I do (from below link)
http://techpubs.sgi.com/library/tpl/....html&srch=md5

On 2004-12-06, Kian Goh wrote:
> Thank you.
>
> I think I should use [a-zA-Z0-9./] instead of [a-zA-Z0-9/+=]
>
>> By the way, do you see there any word about base64?
> Yes, I do (from below link)
> http://techpubs.sgi.com/library/tpl/....html&srch=md5

Yeah, sure. But it isn't the link pointing to Cisco's site, which you
have cited before and from which you have taken that crypt()-ed string.

Never mind.

--
Stanislaw Klekot

In article <cotr0e$4ri$2@news.dialog.net.pl>,
"Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> wrote:

>On 2004-12-04, Lawrence D”Oliveiro wrote:
>> In article <coq6c2$hrn$1@zcars0v6.ca.nortel.com>,
>> "Kian Goh" <kiangoh2700544@hotmail.com> wrote:
>>
>>>I understand that the MD5 Message Digest algorithm takes as input a message
>>>of arbitrary length and produces as output a 128-bit ``fingerprint'' or
>>>``message digest'' of the input.
>>
>> Nobody should be using MD5 or SHA-1 for any new development. Think of
>> them as supported only for backward-compatibility purposes. For new
>> development, I'd suggest something like RIPE-MD160.
>
>Why? Because of recent collisions? AFAIR for RIPE-MD160 there were
>collisions found, too. And I can't recall if there were found collisions
>for SHA-1, not for SHA-0. Can you give me a link? Google says nothing
>about to me.

<http://news.com.com/Crypto+researche...00-1002_3-5313
655.html> mentions significant weaknesses in MD5 as well as flaws in
both SHA and SHA-1.

I'm not aware of any equivalent weaknesses found in RIPE-MD160. Can you
give a reference for these?