Additionally to a mode of operation, as mentioned by poncho's answer, you will probably (depending of the mode of operation) need a padding mode, i.e. a function which converts bit-strings of arbitrary length (or usually only byte-strings of arbitrary length) to strings with length which are of a multiple of the block size.
Such a padding function is easily invertible and adds normally nothing into the security of the cipher, it just appends some bytes before encrypting, and (its inverse) removes them again after decryption.
A popular padding mode is the one defined in PKCS#7 (RFC 2315, section 10.3, Note 2):
- Append enough bytes to get to full block size, at least one (i.e. at most a full block).
- Each appended byte has the same value, the number of bytes added.
- On unpadding, check the last byte and make sure that there are that many bytes before with the same value.
For your 67-bit value we would need a special padding mode for non-byte-aligned bit sequences. A possible way would be do as is to append a
1 bit, then a series of
0 bits, then the binary encoding of the whole padding size (in the last some bits of the padding). (Something similar as this is done by SHA-1, but there the length of the message, not the padding size is in the last bits.)
Anyway, you would then have to encrypt two full blocks (i.e. $2·64 = 128$ bits) of plaintext, resulting probably in $3·64 = 196$ bit of ciphertext (including the initialization vector needed for most modes of operation).
Some modes, as CTR, OFB and CFB allow encrypting also bit strings shorter than whole blocks. You would still have an initialization vector overhead, i.e. you would have $64 + 67 = 131$ bits of ciphertext.
(Note that you normally also should use authentication to avoid chosen-ciphertext attacks, so you would add the size of some authentication tag to this.)