Question: We have a situation in our product where for a long time some data has been stored in the application's database as SQL string (choice of MS SQL server or sybase SQL anywhere) which was encrypted via the Windows API function [CryptEncrypt.](http://msdn.microsoft.com/en-us/library/aa379924.aspx) (direct and de-cryptable)

The problem is that CryptEncrypt can produce NULL's in the output, meaning that when it's stored in the database, the string manipulations will at some point truncate the CipherText.

Ideally we'd like to use an algo that will produce CipherText that doesn't contain NULLs as that will cause the least amount of change to the existing databases (changing a column from string to binary and code to deal with binary instead of strings) and just decrypt existing data and re-encrypt with the new algorithm at database upgrade time.

The algorithm doesn't need to be the most secure, as the database is already in a reasonably secure environment (not an open network / the inter-webs) but does need to be better than ROT13 (which I can almost decrypt in my head now!)

edit: btw, any particular reason for changing ciphertext to cyphertext? ciphertext seems more widely used...

Answer: 
Any semi-decent algorithm will end up with a strong chance of generating a NULL value somewhere in the resulting ciphertext.

Why not do something like [base-64 encode](http://en.wikipedia.org/wiki/Base64) your resulting binary blob before persisting to the DB? ([sample implementation in C++](http://synesis.com.au/software/b64.html)).
It seems that the developer handling this is going to wrap the existing encryption with [yEnc](http://www.yenc.org) to preserve the table integrity as the data needs to be retrievable, and this save all that messy mucking about with infinite-improbab.... uhhh changing column types on entrenched installations.
Cheers Guys