You DO need the base-64 en/decoding, because ciphertext can contain zero bytes which would cause it to be truncated if operated on by a string function. strlen, for example, scans a string for a zero byte and returns its position (minus 1?) as the string's length. Some functions in CString also do that, and some in the template string class also do. If dealing with ciphertext without using strings, it's best to allocate a BYTE (unsigned char) array and pass the length of the ciphertext with the array pointer/address.
If writing ciphertext to a file (without encoding), you'll have to make sure the file is opened in binary mode, write the length of the "string" then the string, repeat for each string. If you don't write the length, you don't know how many bytes to read in to recover it. Any value for a byte is a valid ciphertext value, so there is no character or value that can be used to signal the end of a string of ciphertext characters. base-64 encoding cures that but expands the length by 4 characters out for every 3 in.... So it would probably be best to use the base-64 en/decoding to avoid having problems with handling the ciphertext. Your sequence of events would then be: plaintext -> compressedtext compresstext -> ciphertext ciphertext + MAC -> verified ciphertext verified ciphertext -> base64 encoded text base64 encoded text -> write to file The steps to decrypt are: read from file -> base64_encoded_text base64_encoded_text -> ciphertext + MAC ciphertext + MAC -> verified ciphertext verified ciphertext -> compressedtext compressedtext -> plaintext That way you can just read each message in as a string. You can probably make up a long filter chain to do that, but personally, I've not used filter chains much. But then again, I usually do things differently, and often the hard way.... Rickey
