[cryptopp-users] HashVerificationFilter and SIGSEVG using obviously poor data.

[John Paul Hayes II]

Hey all,

I can provide a code example, but I don't consider it immediately necessary.

I am successfully decrypting ciphertext using a HMAC HashVerificationFilter
and the THROW_EXCEPTION filter. It's awesome. If the data is manipulated at
all, an exception is thrown. This is expected behavior.

However, if I provide my decryption routine with obviously poor data such
as an empty string or a few characters, then a SIGSEGV or SIGABRT signal is
raised during the HashVerificationFilter pipeline. I am developing on
CentOS 7 and debugging using GDB and all the debuginfo I could find.

What can I check for in my decryption routine to prevent the
HashVerificationFilter from failing so? It's not that I expect it to
succeed, but either there are some internals that could check for obviously
bad data or I can check for it myself.

Alternatively, what kinda of data can I be certain will not break the
HashVerificationFilter? Strings with length > 64 and multiple of 32? Hard
for me to tell.

Any advice is welcome. Best regards,
John Paul

[John Paul Hayes II]

Update: My solution is currently to check if the incoming ciphertext has a
length > 0 and that length % 32 != 0.

This appears to solve for my cases. Feel free to provide an opinion or
solution of course.

Thanks.

Post by John Paul Hayes II
Hey all,
I can provide a code example, but I don't consider it immediately necessary.
I am successfully decrypting ciphertext using a HMAC
HashVerificationFilter and the THROW_EXCEPTION filter. It's awesome. If the
data is manipulated at all, an exception is thrown. This is expected
behavior.
However, if I provide my decryption routine with obviously poor data such
as an empty string or a few characters, then a SIGSEGV or SIGABRT signal is
raised during the HashVerificationFilter pipeline. I am developing on
CentOS 7 and debugging using GDB and all the debuginfo I could find.
What can I check for in my decryption routine to prevent the
HashVerificationFilter from failing so? It's not that I expect it to
succeed, but either there are some internals that could check for obviously
bad data or I can check for it myself.
Alternatively, what kinda of data can I be certain will not break the
HashVerificationFilter? Strings with length > 64 and multiple of 32? Hard
for me to tell.
Any advice is welcome. Best regards,
John Paul

[Jeffrey Walton]

On Mon, Aug 27, 2018 at 12:49 PM, John Paul Hayes II

...
However, if I provide my decryption routine with obviously poor data such as
an empty string or a few characters, then a SIGSEGV or SIGABRT signal is
raised during the HashVerificationFilter pipeline. I am developing on CentOS
7 and debugging using GDB and all the debuginfo I could find.

If you provide your data I can test it on an earlier version of the
library to ensure we did not change behavior or break things.

I seem to recall Wei used to avoid some checks and just let things
crash. For example, failing to key a block cipher will lead to a
SIGSEGV because there is no key. It usually shows up in
ProcessAndXorBlocks when the [missing] key is actually used. It does
not surface in UncheckedSetKey because it is not called.

Jeff