Re: MD5 checksum? Why? And why is there stuff to switch little endien?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, June 20, 2014 06:10, L. A. Walsh wrote:
> [...]
> I'd never seen byte order switching w/an MD5 algorithm before, and
> checked against wikipedia.  The one there doesn't seem to do any
> endian switching -- AND of more concern, the constants, (the same
> ones in the font-config code), the input and the output are all described
> as being little endian.  So why is there code to switch endianness?:

All code that casts the same buffer to char and int interchangeably needs
to be aware of endianness.

>From RFC1321:

"
   The implementation is portable and should work on many different
   plaforms. However, it is not difficult to optimize the implementation
   on particular platforms, an exercise left to the reader. For example,
   on "little-endian" platforms where the lowest-addressed byte in a 32-
   bit word is the least significant and there are no alignment
   restrictions, the call to Decode in MD5Transform can be replaced with
   a typecast.
"

This means MD5 assumes the input data can be regarded as series of
little-endian int's. On platforms where it can't, a conversion step is
necessary. To avoid that, the implementation in the RFC reads the input
bytewise and shifts it into int's.

Colin Plumb's implementation, which fontconfig uses, seems to cast a char
buffer to an int one, mandating an endianness check.

Raimund


-- 
Worringer Str 31 Duesseldorf 40211 DE  home: <rs@xxxxxxxx>
+49-179-2981632 icq 16845346           work: <rs@xxxxxxxxxxxxxxx>

_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/fontconfig




[Index of Archives]     [Fedora Fonts]     [Fedora Users]     [Fedora Cloud]     [Kernel]     [Fedora Packaging]     [Fedora Desktop]     [PAM]     [Gimp Graphics Editor]     [Yosemite News]

  Powered by Linux