On Sat, 2003-11-15 at 18:11, Rickey Braddam wrote: > 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
Ok. Where can I find documentation and examples of doing a filter chain? Stephen
