"Henning P. Schmiedehausen" <[EMAIL PROTECTED]> writes:
> And the last posting on this subject. :-)
>
> The results are:
>
> The commons-codec is correct. According to various base64 pages and
> the RFC, base64 strings are always multiple of four bytes long and are
> padded with "=" signs if the input is not a multiple of 24 bytes.
>
> The Digest::MD5 base64_hex is actually wrong. =:-) Look:
>
> % perl -e 'use Digest::MD5 qw(md5_base64); print md5_base64(""),"\n";'
> 1B2M2Y8AsgTpgAmY7PhCfg
>
> % perl -e 'use MIME::Base64; use Digest::MD5 qw(md5); print
>encode_base64(md5("")),"\n";'
> 1B2M2Y8AsgTpgAmY7PhCfg==
>
> (I will file a bug report with the Digest::MD5 author).
>
> Completely wrong is the old security service, because it does not pad
> the base 64 string but simply cuts off everything after a multiple of
> four bytes, which translates to a small catastrophy because you can't
> "upgrade" old database entries (the missing two bytes are gone).
>
> So I will put the "new, correct" and "old, wrong" algorithm both as
> providers into the crypto service. Deprecating the old one will be
> difficult because you can't simply upgrade.
>
> Opinions?
+1, nice work tracking this down, Henning.
Do you happen to have a URL to the bug report with the Digest::MD5
(for posterity, and because I'm curious)?
- Dan
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
