dd, cat & openssl: block size & buffer size

Question

Here it says that when using dd through dm-crypt to overwrite a block device, only the default dd block size should be used because dm-crypt's block size is the same (512 bytes), and increasing dd's block size might prevent the final blocks from being written to.

Does this also apply to openssl (in Linux)?

Here Gilles says that openssl's default buffer size is 8kB. Is buffer size the same as block size in this context?

Given that dd's default block size is 512, if I wanted to use a block size of 1M in dd, would I also have to set -bufsize to the same number for openssl? Is -bufsize in bytes?

Similarly, is it inadvisable to use cat through openssl, given that cat's default (and not configurable) block size is 128kB?

Answer 1

TLDR it doesn't matter (if I guessed right)

First, openssl commandline does about 50 different things; only two of them take bulk input data: enc to encrypt or decrypt a "file" or encode/decode base64 as a special case that isn't really encryption, and dgst to hash and optionally sign or verify a "file". Of those only enc produces output that could be useful to "overwrite" something, so I assume you mean that; rand can also produce bulk output, but not tied to any input.

Second, the issue in the question you linked is delay due to waiting for a cipher data block or an encoding (base64) chunk over the network. If you are only concerned with getting correct output, delay doesn't matter, and if the source isn't remote, it won't be delayed anyway.

openssl enc using a block cipher and mode, particularly CBC which is the default, by default uses PKCS#5 padding (so-called; officially it's PKCS#7 based on PKCS#5, but many people including OpenSSL just say PKCS#5). This allows it to encrypt and decrypt any number of bytes of data that fits in an input and output "file" as supported by the OS and filesystem. The encrypted file (with padding added) is always an exact multiple of the blocksize of the cipher used. For password based encryption with salt, also the default, the ciphertext is up to 32 bytes longer than the plaintext, so on encryption you may need to allow for that. If you specify -nopad (for a block cipher/mode) padding is disabled and the plaintext must be an exact multiple of the cipher blocksize. If it is not, an error occurs and the output is incomplete -- although usually nonempty, which can confuse uncareful people or scripts/etc into thinking it is valid when it isn't.

If you use a stream cipher (currently only RC4) or a stream mode of a block cipher (CFB OFB CTR) no padding is needed or used and the plaintext can be any number of bytes (that fit in files). For PBE with salt, the ciphertext is still longer by 16 bytes. (Warning: some versions mistakenly list CCM and GCM modes as supported on enc; they don't actually work if you try to use them.)

-bufsize is (only) the size used to read and write data. It need not be related to the cipher blocksize if any, although by default it is a medium power of 2 and the blocksizes of all supported block ciphers are small powers of 2 so they happen to divide evenly. The cipher logic handles large data as a stream broken into chunks of any size or sizes; only the total length matters. But it is less efficient to handle lots of small chunks because it does more calls to the C library and (often) OS.

cat piped into openssl enc input is fine, although if it reads only one "file" there is no benefit over just making that file the (redirected) stdin of openssl, or the -in argument. Similarly there is neither harm nor benefit in using dd if it just copies the data; if you use any of the other functionality of dd like converting EBCDIC and/or fixed length records (typical of IBM mainframe data) obviously that is needed. And if you want the statistics about 1234+0 records in etc, you do need dd or similar.