On Friday, July 8, 2016 at 1:22:10 AM UTC-4, Gavin Lambert wrote:
>
> On Friday, July 8, 2016 at 2:41:59 PM UTC+12, Jeffrey Walton wrote:
>>
>> I'm guessing the third pipeline is not quite correct:
>>
>> StringSource source3(uncompressed_data, true, snf);
>>
>> I'm guessing you need to either pump (1) uncompressed_data+hash; or (2)
>> hash+uncompressed_data. This is typically how one uses a
>> SignatureVerificationFilter:
>> http://www.cryptopp.com/wiki/SignatureVerificationFilter .
>>
>
> That's the case that works, though. To clarify, the uncompressed_data
> already includes the hash as a prefix.
>
> Eliminating the AES part, since it's irrelevant to the issue, what I'm
> saying is that this code:
>
> RSASS<PKCS1v15, SHA256>::Verifier verifier(publicKey);
> auto snf = new SignatureVerificationFilter(verifier, new StringSink(
> plaintext),
> SignatureVerificationFilter::PUT_MESSAGE | SignatureVerificationFilter
> ::SIGNATURE_AT_BEGIN);
> StringSource source2(compressed_data, true, new Gunzip(new StringSink(
> uncompressed_data)));
> StringSource source3(uncompressed_data, true, snf);
> assert(snf->GetLastResult());
>
> Given a compressed_data that is the result of signing a plaintext with the
> corresponding private key, prepending the hash to the plaintext, then Gzip
> compressing it, this results in the correct original plaintext and the
> assertion passes on both Windows and Linux.
>
> While this code:
>
> RSASS<PKCS1v15, SHA256>::Verifier verifier(publicKey);
> auto snf = new SignatureVerificationFilter(verifier, new StringSink(
> plaintext),
> SignatureVerificationFilter::PUT_MESSAGE | SignatureVerificationFilter
> ::SIGNATURE_AT_BEGIN);
> StringSource source2(compressed_data, true, new Gunzip(snf));
> assert(snf->GetLastResult());
>
> Given exactly the same input, again produces the correct plaintext on both
> Windows and Linux (at least in the first hundred bytes; I didn't check the
> whole message), *but* the assertion passes on Windows and fails on Linux
> (equivalently, if the THROW_EXCEPTION flag is also used, then it throws on
> Linux but not on Windows). As you can see, the only difference is that the
> verification filter is chained directly from Gunzip rather than going via
> an intermediate string buffer.
>
> Also, be careful of the way those primitives are combined in a public key
>> system. There's a lot to it, but see this question on the Crypto.SE:
>> https://crypto.stackexchange.com/questions/5458/should-we-sign-then-encrypt-or-encrypt-then-sign.
>>
>> Also see this paper:
>> http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html.
>>
>
> Thank you; but I saw that note in the Wiki and read those carefully before
> going down this path. Surreptitious forwarding isn't a concern in my usage
> scenario.
>
This does not quite look right, either:
auto snf = new SignatureVerificationFilter(...);
...
StringSource source2(compressed_data, true, new Gunzip(snf));
The Gunzip object deletes the attached Verifier when the Gunzip destructor
runs. 'snf' is not a valid object after that.
Usually, you want to use a Redirector to break the ownership chain:
http://www.cryptopp.com/wiki/Redirector . The Redirector takes a reference
(not a pointer), so it does not own the attached BufferedTransformation.
Maybe something like:
auto snf = SignatureVerificationFilter(...);
...
StringSource source(compressed_data, true, new Gunzip(new Redirector
(snf)));
...
assert(snf.GetLastResult())
Jeff
--
--
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.
---
You received this message because you are subscribed to the Google Groups
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
