0
$\begingroup$

In case I am using CBC cipher in that case is it must that my encrypted text is in multiple of the BLOCK SIZE? Is the same true for GCM?

$\endgroup$
  • $\begingroup$ Do you know padding? $\endgroup$ – deviantfan Nov 28 '16 at 7:52
  • $\begingroup$ Yes I know padding. But I just wanted to know that padding is mandatory. The encrypted text must be in multiple of BLOCK SIZE. As I am the person who has to decrypt the text. So I just wanted to keep a first point acceptance that the message size should be in multiple of BLOCK SIZE otherwise the message is incorrect. Can I safely assume that? $\endgroup$ – Rinil Baxi Nov 28 '16 at 8:06
  • 1
    $\begingroup$ GCM does not require block alignment. It does add a tag so the ciphertext is larger than the plaintext, but not to a block boundary. The encryption part of GCM is actually a trivial modification of counter mode which allows any bitlength, but SP800-38D requires byte alignment, and most implementations are in software which usually requires byte alignment anyway (for example in C or Java) and many applications also do (e.g. rfc5288 for TLS). The authentication part (GMAC) internally pads to block but this is not exposed. $\endgroup$ – dave_thompson_085 Nov 28 '16 at 9:11
1
$\begingroup$

No, GCM does not require padding, nor does it require plaintext to be a multiple of the block size.

GCM is a mode that combines CTR, which is a stream cipher mode, with GMAC authentication, which dave has pointed out does require its inputs to be a multiple of its block size, 128-bits. However the GMAC process simply null pads the ciphertext input, then processes the length of the data as an additional input, to eliminate issues relating to that padding method.

CTR mode turns a block cipher into a stream cipher by encrypting an incrementing counter. GCM is only used with a 128-bit block cipher by design, so the stream cipher outputs are generated in 128-bit increments, and only the needed bits are used to encrypt the plaintext. If the plaintext is 136 bits, 256 bits of stream cipher output is generated, and the first 136 bits are used.

Because GCM is based on CTR, the length of the ciphertext is the same as the length of the plaintext, plus the GMAC authentication tag length, plus the length of the Nonce.

$\endgroup$
1
$\begingroup$

Yes, with most block modes,

  • the plain data length (before encrypting) has to be a multiple of the block size. For this reason, the plain data is padded before.
  • the encrypted data length too has to be a multiple of the block size, namely the same size as the padded plain data.

But there are exceptions to this rule, eg. the block mode XTS, where no extra paddign is necessary and the encrypted data has the same length as the plain data.

(Note that you shouldn't choose a block mode just because of this. Each mode has other advantages/disadvantages, XTS is by no means the best for all purposes)

$\endgroup$
  • 1
    $\begingroup$ ECB and CBC require alignment and thus in many usages padding, but CFB OFB CTR and GCM CCM EAX (all based on CTR) do not. $\endgroup$ – dave_thompson_085 Nov 28 '16 at 9:14
  • $\begingroup$ ...if CFB etc. are "block" modes is another topic. $\endgroup$ – deviantfan Nov 28 '16 at 9:18

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.