1

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?

  • there isnt a good reason to ever use a block size of 1M. at least, I'm unaware of any block dev which blocks on 1M sectors. some are 4M, some 512 bytes. with the second variety blocking at page size or pipe buffer-size makes sense, so 256k is usually pretty good, but 1M doesnt make much sense. – mikeserv Dec 11 '15 at 3:15
  • 1
    @mikeserv But what if 1M produces the fastest transfer rate? – EmmaV Dec 11 '15 at 22:45
  • if so then I'm wrong, and it wouldn't be the first time, but, because I'm also stubborn, would you provide for me a case in which it does? I guess I can imagine a case of copying from a disk to the same disk in which it might, but it seems iffy. because 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
  • @mikeserv I cannot :-/ – EmmaV Dec 12 '15 at 0:31
2

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.

  • Thank you for your detailed answer. You correctly assumed that I meant openssl enc. So you're saying that it would be okay simply to do openssl enc -aes-256-ctr -pass pass:password -nosalt -in /dev/zero -out /dev/sdb to overwrite a hard drive, for example? – EmmaV Dec 11 '15 at 22:50
  • excellent answer, davethompson. Thanks. @EmmaV - that's the gist I get as well, but you'll need appropriate permissions, of course. – mikeserv Dec 11 '15 at 23:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.