You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Deepak Nagaraj <n....@gmail.com> on 2009/12/21 14:20:36 UTC
network byte ordering in "ContentDigest"?
Hi,
The "ContentDigest" option does not seem to convert the MD5 to network
byte order before doing base64 encoding. The RFC says:
"""
The output of the MD5 algorithm is a 128 bit digest. When viewed in
network byte order (big-endian order), this yields a sequence of 16
octets of binary data. These 16 octets are then encoded according to
the base64 algorithm in order to obtain the value that is placed in
the Content-MD5 field.
"""
I've seen server/util_md5.c. Did I miss something?
Thanks,
-deepak
Re: network byte ordering in "ContentDigest"?
Posted by Deepak Nagaraj <n....@gmail.com>.
On Tue, Dec 22, 2009 at 11:36 AM, Deepak Nagaraj <n....@gmail.com> wrote:
>>>>> But on the other hand, HTTP "Content-MD5" header RFC (1864) explicitly
>>>>> mentions network byte ordering as I originally quoted. Being a
>>>>> standards-compliant HTTP server, IMO, we should be doing whatever the
>>>>> RFC says, even if it's a nuance.
>>>>
>>>> What RFC? The MD5 one? Or the HTTP MD5 one (1864)?
>>>>
>>> The HTTP MD5 RFC (1864), since that's what Apache "ContentDigest" implements.
>>
>> So what exactly are you proposing?
>> An example of actual bytes in de MD5 in BE and LE would help.
>>
> Please review this patch to util_md5.c. It's a naive,
> platform-independent implementation of LE to BE conversion.
>
<snip>
Any conclusion on this thread? Will "ContentDigest" remain as is, or
will it be patched?
Thanks,
-deepak
Re: network byte ordering in "ContentDigest"?
Posted by Deepak Nagaraj <n....@gmail.com>.
On Mon, Dec 21, 2009 at 11:07 PM, Olaf van der Spek
<ol...@gmail.com> wrote:
>>>> But on the other hand, HTTP "Content-MD5" header RFC (1864) explicitly
>>>> mentions network byte ordering as I originally quoted. Being a
>>>> standards-compliant HTTP server, IMO, we should be doing whatever the
>>>> RFC says, even if it's a nuance.
>>>
>>> What RFC? The MD5 one? Or the HTTP MD5 one (1864)?
>>>
>> The HTTP MD5 RFC (1864), since that's what Apache "ContentDigest" implements.
>
> So what exactly are you proposing?
> An example of actual bytes in de MD5 in BE and LE would help.
>
Please review this patch to util_md5.c. It's a naive,
platform-independent implementation of LE to BE conversion.
Here is a sample run through the function:
before: 141cc61b 1d4d266a 7b0abec2 beb7a7f8
after: f8a7b7be c2be0a7b 6a264d1d 1bc61c14
Thanks,
-deepak
--- util_md5.c.orig 2009-12-22 10:37:41.000000000 +0530
+++ util_md5.c 2009-12-22 11:26:46.000000000 +0530
@@ -128,6 +128,23 @@
static char basis_64[] =
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/";
+/* convert 128-bit number from little-endian to big-endian
+ * warning: input is modified
+ */
+AP_DECLARE(void) ap_le2be_128bits_inplace(char *data)
+{
+ char tmp;
+ int i, j;
+
+ j = 15;
+ for (i=0; i<8; i++) {
+ tmp = data[i];
+ data[i] = data[j];
+ data[j] = tmp;
+ j--;
+ }
+}
+
AP_DECLARE(char *) ap_md5contextTo64(apr_pool_t *a, apr_md5_ctx_t *context)
{
unsigned char digest[18];
@@ -140,6 +157,7 @@
apr_md5_final(digest, context);
digest[sizeof(digest) - 1] = digest[sizeof(digest) - 2] = 0;
+ ap_le2be_128bits_inplace(digest);
p = encodedDigest;
for (i = 0; i < sizeof(digest); i += 3) {
*p++ = basis_64[digest[i] >> 2];
Re: network byte ordering in "ContentDigest"?
Posted by Olaf van der Spek <ol...@gmail.com>.
On Mon, Dec 21, 2009 at 6:35 PM, Deepak Nagaraj <n....@gmail.com> wrote:
> On Mon, Dec 21, 2009 at 11:02 PM, Olaf van der Spek
> <ol...@gmail.com> wrote:
>>> But on the other hand, HTTP "Content-MD5" header RFC (1864) explicitly
>>> mentions network byte ordering as I originally quoted. Being a
>>> standards-compliant HTTP server, IMO, we should be doing whatever the
>>> RFC says, even if it's a nuance.
>>
>> What RFC? The MD5 one? Or the HTTP MD5 one (1864)?
>>
> The HTTP MD5 RFC (1864), since that's what Apache "ContentDigest" implements.
So what exactly are you proposing?
An example of actual bytes in de MD5 in BE and LE would help.
Olaf
Re: network byte ordering in "ContentDigest"?
Posted by Deepak Nagaraj <n....@gmail.com>.
On Mon, Dec 21, 2009 at 11:02 PM, Olaf van der Spek
<ol...@gmail.com> wrote:
>> But on the other hand, HTTP "Content-MD5" header RFC (1864) explicitly
>> mentions network byte ordering as I originally quoted. Being a
>> standards-compliant HTTP server, IMO, we should be doing whatever the
>> RFC says, even if it's a nuance.
>
> What RFC? The MD5 one? Or the HTTP MD5 one (1864)?
>
The HTTP MD5 RFC (1864), since that's what Apache "ContentDigest" implements.
-deepak
Re: network byte ordering in "ContentDigest"?
Posted by Olaf van der Spek <ol...@gmail.com>.
On Mon, Dec 21, 2009 at 5:07 PM, Deepak Nagaraj <n....@gmail.com> wrote:
>> AFAIK that really doesn't apply. It's not an int, it's a 16-byte
>> 'array' that shouldn't be reordered.
>>
> You're right about MD5. I checked the MD5-algorithm RFC (1321). It
> specifies that the digest is generated in little-endian order.
>
> """
> The message digest produced as output is A, B, C, D. That is, we begin
> with the low-order byte of A, and end with the high-order byte of D.
> """
>
> So as long as the generator and verifier both follow the MD5 algorithm
> as per its RFC, we should be OK.
>
> But on the other hand, HTTP "Content-MD5" header RFC (1864) explicitly
> mentions network byte ordering as I originally quoted. Being a
> standards-compliant HTTP server, IMO, we should be doing whatever the
> RFC says, even if it's a nuance.
What RFC? The MD5 one? Or the HTTP MD5 one (1864)?
Olaf
Re: network byte ordering in "ContentDigest"?
Posted by Deepak Nagaraj <n....@gmail.com>.
On Mon, Dec 21, 2009 at 8:03 PM, Olaf van der Spek <ol...@gmail.com> wrote:
> On Mon, Dec 21, 2009 at 3:07 PM, Deepak Nagaraj <n....@gmail.com> wrote:
>>> It's 16 bytes, what reordering did you want to do? Byte order only
>>> applies to stuff larger than individual bytes.
>>>
>> The RFC considers it as a 128-bit "digest" (=number). It can be
>> divided into 16 bytes in either host order or network order. Because
>> the RFC says "when viewed in network order", it implies that we need
>> to do host-to-network conversion. This is the conversion I'm
>> referring to.
>
> AFAIK that really doesn't apply. It's not an int, it's a 16-byte
> 'array' that shouldn't be reordered.
>
You're right about MD5. I checked the MD5-algorithm RFC (1321). It
specifies that the digest is generated in little-endian order.
"""
The message digest produced as output is A, B, C, D. That is, we begin
with the low-order byte of A, and end with the high-order byte of D.
"""
So as long as the generator and verifier both follow the MD5 algorithm
as per its RFC, we should be OK.
But on the other hand, HTTP "Content-MD5" header RFC (1864) explicitly
mentions network byte ordering as I originally quoted. Being a
standards-compliant HTTP server, IMO, we should be doing whatever the
RFC says, even if it's a nuance.
Thanks,
-deepak
Re: network byte ordering in "ContentDigest"?
Posted by Olaf van der Spek <ol...@gmail.com>.
On Mon, Dec 21, 2009 at 3:07 PM, Deepak Nagaraj <n....@gmail.com> wrote:
>> It's 16 bytes, what reordering did you want to do? Byte order only
>> applies to stuff larger than individual bytes.
>>
> The RFC considers it as a 128-bit "digest" (=number). It can be
> divided into 16 bytes in either host order or network order. Because
> the RFC says "when viewed in network order", it implies that we need
> to do host-to-network conversion. This is the conversion I'm
> referring to.
AFAIK that really doesn't apply. It's not an int, it's a 16-byte
'array' that shouldn't be reordered.
Olaf
Re: network byte ordering in "ContentDigest"?
Posted by Deepak Nagaraj <n....@gmail.com>.
On Mon, Dec 21, 2009 at 7:02 PM, Olaf van der Spek <ol...@gmail.com> wrote:
> On Mon, Dec 21, 2009 at 2:20 PM, Deepak Nagaraj <n....@gmail.com> wrote:
>> Hi,
>>
>> The "ContentDigest" option does not seem to convert the MD5 to network
>> byte order before doing base64 encoding. The RFC says:
>
> It's 16 bytes, what reordering did you want to do? Byte order only
> applies to stuff larger than individual bytes.
>
The RFC considers it as a 128-bit "digest" (=number). It can be
divided into 16 bytes in either host order or network order. Because
the RFC says "when viewed in network order", it implies that we need
to do host-to-network conversion. This is the conversion I'm
referring to.
-deepak
Re: network byte ordering in "ContentDigest"?
Posted by Olaf van der Spek <ol...@gmail.com>.
On Mon, Dec 21, 2009 at 2:20 PM, Deepak Nagaraj <n....@gmail.com> wrote:
> Hi,
>
> The "ContentDigest" option does not seem to convert the MD5 to network
> byte order before doing base64 encoding. The RFC says:
It's 16 bytes, what reordering did you want to do? Byte order only
applies to stuff larger than individual bytes.
Olaf