Those following this thread may be interested in checking out RFC
3548: <http://www.faqs.org/rfcs/rfc3548.html>. It appears to address
some of the concerns raised in this thread and what the recommended
practices are.

It is worth noting the RFC 2045 states that decoders *must* ignore
invalid characters when decoding. However, I believe RFC 2045 is
ambiguous about '='. If it appears in the middle of input stream,
it could imply end-of-data or an invalid character if you take the
approach that '=' is only a valid base64 character at the end of
encoded data.

The following is written in the Security Considerations of
RFC 3548:

When implementing Base encoding and decoding, care should be taken
not to introduce vulnerabilities to buffer overflow attacks, or
other attacks on the implementation. A decoder should not break
on invalid input including, e.g., embedded NUL characters (ASCII 0).

If non-alphabet characters are ignored, instead of causing rejection
of the entire encoding (as recommended), a covert channel that can
be used to "leak" information is made possible. The implications
of this should be understood in applications that do not follow
the recommended practice.

--ewh

[ reply ]