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.
--
--
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.
