MD5 digest length 16 bytes or not?

[Albretch]

I am using mysql.

As defined by RSA DSI in RFC 1321

http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1321.html

..'The algorithm takes as input a message of arbitrary length and
produces as output a 128-bit "fingerprin t" or "message digest" of the
input.'

Why is it then that when I use a statement like:

USE testdb;

INSERT INTO people (name, pass) VALUES('joe', MD5('yojoenotyo yo'));

being the field 'pass' defined as VARCHAR(32), the whole field is
filled, even though last time I checked 128 bits are 16 bytes?

[Roedy Green]

On 17 Aug 2003 19:43:12 -0700, lb*****@hotmail .com (Albretch) wrote or
quoted :

being the field 'pass' defined as VARCHAR(32), the whole field is
filled, even though last time I checked 128 bits are 16 bytes?

What is MD5 producing, a BigInteger, a byte array? Presumably it is
getting converted to characters in some way, perhaps base64, hex, each
byte -> 1 16-bit char??
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

[Albretch]

You were absolutely right!

From:

http://www.mysql.com/doc/en/Miscella...functions.html

MD5(string)
Calculates an MD5 128 bit checksum for the string. The value is
returned as a 32 digit hex number that may, for example, be used as a
hash key:
mysql> SELECT MD5("testing");
-> 'ae2b1fca515949 e5d54fb22b8ed95 575'

What I found confusing was: If mysql can internally handle binary
data such as BLOBs and MD5 is supposed to be a one way method anyway
(and also the fact that we are talking here about security data) why
is it translated to text and stored as such?

Forcing Tomcat to keep/handle more data while tracking users?

Roedy Green <ro***@mindprod .com> wrote in message news:<sf******* *************** **********@4ax. com>...

On 17 Aug 2003 19:43:12 -0700, lb*****@hotmail .com (Albretch) wrote or
quoted :

being the field 'pass' defined as VARCHAR(32), the whole field is
filled, even though last time I checked 128 bits are 16 bytes?

What is MD5 producing, a BigInteger, a byte array? Presumably it is
getting converted to characters in some way, perhaps base64, hex, each
byte -> 1 16-bit char??

[Albretch]

You were absolutely right!

From:

http://www.mysql.com/doc/en/Miscella...functions.html

MD5(string)
Calculates an MD5 128 bit checksum for the string. The value is
returned as a 32 digit hex number that may, for example, be used as a
hash key:
mysql> SELECT MD5("testing");
-> 'ae2b1fca515949 e5d54fb22b8ed95 575'

What I found confusing was: If mysql can internally handle binary
data such as BLOBs and MD5 is supposed to be a one way method anyway
(and also the fact that we are talking here about security data) why
is it translated to text and stored as such?

Forcing Tomcat to keep/handle more data while tracking users?

Roedy Green <ro***@mindprod .com> wrote in message news:<sf******* *************** **********@4ax. com>...

On 17 Aug 2003 19:43:12 -0700, lb*****@hotmail .com (Albretch) wrote or
quoted :

being the field 'pass' defined as VARCHAR(32), the whole field is
filled, even though last time I checked 128 bits are 16 bytes?

What is MD5 producing, a BigInteger, a byte array? Presumably it is
getting converted to characters in some way, perhaps base64, hex, each
byte -> 1 16-bit char??

[Albretch]

You were absolutely right!

From:

http://www.mysql.com/doc/en/Miscella...functions.html

MD5(string)
Calculates an MD5 128 bit checksum for the string. The value is
returned as a 32 digit hex number that may, for example, be used as a
hash key:
mysql> SELECT MD5("testing");
-> 'ae2b1fca515949 e5d54fb22b8ed95 575'

What I found confusing was: If mysql can internally handle binary
data such as BLOBs and MD5 is supposed to be a one way method anyway
(and also the fact that we are talking here about security data) why
is it translated to text and stored as such?

Forcing Tomcat to keep/handle more data while tracking users?

Roedy Green <ro***@mindprod .com> wrote in message news:<sf******* *************** **********@4ax. com>...

On 17 Aug 2003 19:43:12 -0700, lb*****@hotmail .com (Albretch) wrote or
quoted :

being the field 'pass' defined as VARCHAR(32), the whole field is
filled, even though last time I checked 128 bits are 16 bytes?

What is MD5 producing, a BigInteger, a byte array? Presumably it is
getting converted to characters in some way, perhaps base64, hex, each
byte -> 1 16-bit char??

[Roedy Green]

On 18 Aug 2003 06:11:06 -0700, lb*****@hotmail .com (Albretch) wrote or
quoted :

f mysql can internally handle binary
data such as BLOBs and MD5 is supposed to be a one way method anyway
(and also the fact that we are talking here about security data) why
is it translated to text and stored as such?

The catch is SQL was originally envisioned as strings of ASCII
sentences going back and forth. This allowed platform independence in
days when computer architectures could not decide on 1 vs 2
complement, how big a BYTE was etc.

Now we are gradually trying to retrofit binary into SQL.

The ASCII limitation adds complication and overhead packing and
unpacking.

At some point we need to invent a BSQL that is designed primarily
around binary. Instead of ASCII sentences it would use arrays of
tokens for queries. Result set rows would appear as objects.
Setter methods on the objects would track changes to the fields
automatically. Thus an update could be handled with a simple .update
command, that would send back just the fields that had changed.
Alternatively, it might work by keeping and old and new version of the
row object.

For these simple row objects, there could be a more streamlined
serialisation protocol that did not need to specify the types of
fields, just the raw data. The receiver knows precisely what is
coming.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

[Roedy Green]

On 18 Aug 2003 06:11:06 -0700, lb*****@hotmail .com (Albretch) wrote or
quoted :

f mysql can internally handle binary
data such as BLOBs and MD5 is supposed to be a one way method anyway
(and also the fact that we are talking here about security data) why
is it translated to text and stored as such?

The catch is SQL was originally envisioned as strings of ASCII
sentences going back and forth. This allowed platform independence in
days when computer architectures could not decide on 1 vs 2
complement, how big a BYTE was etc.

Now we are gradually trying to retrofit binary into SQL.

The ASCII limitation adds complication and overhead packing and
unpacking.

At some point we need to invent a BSQL that is designed primarily
around binary. Instead of ASCII sentences it would use arrays of
tokens for queries. Result set rows would appear as objects.
Setter methods on the objects would track changes to the fields
automatically. Thus an update could be handled with a simple .update
command, that would send back just the fields that had changed.
Alternatively, it might work by keeping and old and new version of the
row object.

For these simple row objects, there could be a more streamlined
serialisation protocol that did not need to specify the types of
fields, just the raw data. The receiver knows precisely what is
coming.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

[Roedy Green]

On 18 Aug 2003 06:11:06 -0700, lb*****@hotmail .com (Albretch) wrote or
quoted :

f mysql can internally handle binary
data such as BLOBs and MD5 is supposed to be a one way method anyway
(and also the fact that we are talking here about security data) why
is it translated to text and stored as such?

The catch is SQL was originally envisioned as strings of ASCII
sentences going back and forth. This allowed platform independence in
days when computer architectures could not decide on 1 vs 2
complement, how big a BYTE was etc.

Now we are gradually trying to retrofit binary into SQL.

The ASCII limitation adds complication and overhead packing and
unpacking.

At some point we need to invent a BSQL that is designed primarily
around binary. Instead of ASCII sentences it would use arrays of
tokens for queries. Result set rows would appear as objects.
Setter methods on the objects would track changes to the fields
automatically. Thus an update could be handled with a simple .update
command, that would send back just the fields that had changed.
Alternatively, it might work by keeping and old and new version of the
row object.

For these simple row objects, there could be a more streamlined
serialisation protocol that did not need to specify the types of
fields, just the raw data. The receiver knows precisely what is
coming.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.