[Botan-devel] RSA removes spaces from my text

Jack Lloyd lloyd at randombit.net
Fri Jan 23 19:30:06 EST 2009


On Fri, Jan 23, 2009 at 06:53:03PM -0500, Z. S. O. wrote:
> Yeah my "Hello World!" example was mistaken -- I never actually tested it
> out, I just used it to illustrate what (I thought) was happening. Thanks for
> the explanation.
> 
> I have another slightly related question. When I encrypt something in RSA or
> AES, there is always one or two equal signs trailing at the end. These don't
> appear to serve any purpose, as the string decrypts fine even when I remove
> them. Why are they there, and how can I stop them from appearing?

They are padding from the base64 algorithm. base64 encodes 6 bits of
information in every byte - that is, it encodes 3 bytes of arbitrary
information to 4 bytes of base64 encoding. So if the input length is
not a multiple of 3 bytes, some bits at the end are not used, which is
represented by the padding character ('='). See RFC 3548
(http://www.ietf.org/rfc/rfc3548.txt) or the Wikipedia entry on base64
(http://en.wikipedia.org/wiki/Base64) for more background.

The reason it happens to work without them is the base64 decoder in
botan knows the message boundaries, and so assumes if the message ends
on an uneven boundary that the remaining (unseen) bits are
padding. However there is no certainty that every implementation would
choose the same semantics - as far as I can read from RFC 3548, an
implementation does not need to consider this case and can safely
assume all inputs will represent a full quantum (24 bits / 4 base64
characters) of information, so it's quite likely that other base64
decoders can and will reject such inputs, and it's also possible that
a future change to botan would also cause this to break (for instance,
I could see it being useful to assume the strict base64 semantics in
order to optimize the decoder using SIMD operations or wider unrolled
loops).

-Jack



More information about the botan-devel mailing list