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)).
That's an interesting route OJ.
We're looking at the feasability of a non-reversable method (still making sure we don't explicitly retrieve the data to decrypt) e.g. just store a Hash to compare on a submission