2

We have a scenario like that we need to encrypt 100 bits of plain text using encryption algorithm like DES (algorithm takes 64bits plain text block and generate 64 bits of cypher text block, key using for encryption is 56bits) and want 100bits of cypher text.

My question by using this scenario: Is the encryption algorithm only encrypt 1st 64bits of plain text and left rest 36bits unencrypted ? If no, then what is the process in this scenario?

or:

In simple I want to encrypt 100 bits of plain text and want result in 100 bits of cypher text, using algo DES (algo takes 64bits plain text block and generate 64 bits of cypher text block, key using for encryption is 56bits) what is the process?

2
  • 1
    Have you read FIPS 46-3? BTW, DES is not recommended for use any more. Commented Jul 28, 2015 at 11:27
  • 1
    I think we need SE.Homework for new users
    – Ulkoma
    Commented Jul 28, 2015 at 11:43

1 Answer 1

7

DES is a block cipher, which means that it processes blocks of a fixed size. When you want to encrypt a message, i.e. a sequence of bits whose length is not necessarily that of a single block, you need to apply a mode of operation that applies the block cipher "properly" to encrypt and decrypt a message.

The Wikipedia page has nice schematics. Each mode of operation has its own requirements on the input length; for instance, the CBC mode requires that the input length is an exact multiple of the block size. Thus, CBC requires some padding and invariably results in a ciphertext that is larger than the plaintext. Some other modes can do an exact bit-to-bit encryption (encrypt k bits into exactly k bits, for all k), notably OFB, CFB and CTR. CBC can also be made padding-less with CTS ("ciphertext stealing") as long as the input size is at least as long as a block.

Note, though, that almost all modes of operations need an Initialization Vector, which must be chosen by who encrypts and conveyed to who decrypts; if the IV cannot be inferred from the context, then it must be transmitted, which increases the network requirements. IV selection is crucial for security; some modes need a fully random, unpredictable IV, while some others can achieve security with a non-repeating IV, but a fixed, hardcoded IV will usually be no good at all.

An IV-less mode that turns 100 bits of plaintext into 100 bits of ciphertext would need to be deterministic (this is a mathematical necessity); thus, such a mode would necessarily reveal if two encrypted messages are identical. This may or may not be a problem, depending on usage context. A secure IV-less mode is an IV-less mode that leaks exactly that information but no more. To my knowledge, there is no standard for a secure IV-less mode, but there are some known academic constructions (this one can be made practical; that one is theoretically "better" but a lot less practical).


There are still some remarks to be made. First and foremost, DES is obsolete and weak, precisely because of its key length: the 56-bit key is within reach of an exhaustive search (substantial effort, but achievable, even by amateurs with a moderate budget). 3DES is much stronger, but also three times slower (while DES was already quite slow in "normal" software). Both DES and 3DES use 64-bit blocks, which are a bit too narrow (this can raise security issues when encrypting lots of data with a single key). 3DES is also deprecated; modern protocols should use AES, whose blocks are larger (128 bits), avoiding these security issues. AES is also substantially faster than 3DES.

Also, encryption need to be applied in contexts where there is a need for confidentiality against eavesdroppers. In most such contexts, the attackers can also be active, i.e. alter data in transit. Alterations can be reliably detected through the use of a MAC, but this necessarily increases the message size (again because of the pigeons). Combining encryption and MAC is not easy at all, and successive messages must be somehow "linked" together to defeat replay attacks and other alterations at the packet level. All of this is supposed to be handled by defining a secure protocol: a protocol is an assembly of elementary cryptographic algorithms (e.g. AES) to provide some well-defined security properties. An example of a protocol is TLS. Designing a secure protocol is even harder than designing a secure algorithm; even implementing an already defined protocol is hard to do properly (i.e. without leaking secret information).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .