> This seems like a bug to me, should I > report it as such? I'd recommend researching it a bit. There's some details some folks don't readily observe: a filter is slightly different from a buffered transformation. See the note on Attachable at http://www.cryptopp.com/wiki/Filter#Attachable. I think it means the the filter (ie, Base64Encoder/Nase64Decoder) cannot be a Source or a Sink - it must be an intermediate object - ie, a filter. Examples:
StringSource(Base64Encoder(StringSink)) - OK Base64Encoder(StringSink) - No When you want to use it as a source, you have to use it as follows (Or put a StringSource in front of it): Base64Encoder encoder(StringSink()) encoder.Put() encoder.MessageEnd() - OK Since you were fiddling with keys and persistence, the following might also be useful for you: http://www.cryptopp.com/wiki/Key_Format. Jeff On Oct 11, 8:54 pm, Ben Botto <[email protected]> wrote: > Thanks for the response, Jeff. This seems like a bug to me, should I > report it as such? Shouldn't I come up with the same base64 encoded > string in both cases in the code above? I can use all other filters > that I've tested fine to save and load keys, but when using the > base64encoder I have to apply a "workaround" and save the key to a > string, then base64 encode it, which seems like incorrect behavior to > me. > > [b] -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com.
