Salts are commonly used in two ways:

- When encrypting data using a key-based algorithm (Blowfish, TripleDES, AES, etc.) - you typically append the salt to the key/passphrase during encryption to increase the complexity of the key. This helps if the key is compromised and the salt isn't, and generally help prevent weak keys being used if the salt is complex enough.

- When generating a hash from data (MD5, SHA, etc.) - you typically append the salt to the plaintext itself. This prevents a simple rainbow attack using tables of pregenerated hash values for all lengths of plaintext.

In both cases the salt value may be static and commonly known by all both encrypter and decrypter, or may be dynamically generated per plaintext you encrypt, in which case you need some other out-of-band means to transmit the salt values to the decrypter.

Base64 is a simple transformation only - it is NOT encryption. You will often see output from encryption algorithms in Base64 format simply because the ciphertext they output is often composed of bytes that aren't printable in simply 8-bit ASCII, so a Base64 encoding is applied to the ciphertext AFTERWARDS for ease of transmission over text-based media.

When you say "salted Base64" that means one of two things to me:

a) you append the salt value to the plaintext then Base64 encode it. This is utterly trivial to decode and provides no security whatsoever.

b) you modify the Base64 encoding algorithm in some way to incorporate your "salt". The output from this would no longer be Base64 as the world knows, and even though you would modify the decoder to decode it in the same way I doubt very much that it would be in any way secure. Don't try to "roll your own" encryption algorithms - leave that to the experts in the crypto community.

Can you describe in detail exactly how you want to work with this in your transactional client-server scenario?

Regards,

Jacob