[crypto] fix crypto block rounding/padding calculation

libnss is "weird" in this respect as some block sizes are hardcoded,
others need to be determined dynamically.

For AES we need to use the values we know since GetBlockSize would
return errors, for 3des (that hopefully nobody is using) the value
returned by GetBlockSize is 8, but let's use the call into libnss
to avoid possible conflicts with distro patching or older versions.

Now, given the correct block size, the old calculation simply added
block size to the hdr_size. This is not sufficient.

We use _PAD encryption methods and we need to take that into account.

_PAD is calculated given the current input buf len and rounded up
to block size boundary, then block_size is added.

Ideally we would do that on a per packet base but current transport
infrastructure doesn't allow it yet.

So round up the hdr_size to double the block_size reported by the
cipher.

Signed-off-by: Fabio M. Di Nitto <fdinitto@redhat.com>
Reviewed-by: Christine Caulfield <ccaulfie@redhat.com>