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.
dd
works read per read, you can generally get the best performance if you can buffer only enough to offset any slowdown as might come from context switching into sys calls. so basically - read only as much as a disk blocks, then write it out again as soon as you have done. – mikeserv Dec 11 '15 at 23:21