2
$\begingroup$

I'm using this kind of technique instead of padding of cipher buffer (here goes pseudo-code):

struct {
   int size;         //size of cipher buffer
   byte[32] vector; //random IV (block size is 256 bits)
   byte[] buffer;    //encrypted buffer
}

Cipher data encrypted using block cipher with CBC chaining using IV specified as vector

I'm storing this structure "as-is" and in order to decrypt it decrypting buffer block by block then just cutting buffer to size.

Question is: is it safe/secure? Any hints/criticizm?

$\endgroup$
  • 1
    $\begingroup$ @barmaley, what is the danger of being able to modify the message? That depends on what you are using the encryption for. $\endgroup$ – otus Dec 25 '15 at 9:00
  • 1
    $\begingroup$ @barmaley, a MAC rather than a hash, but essentially. $\endgroup$ – otus Dec 25 '15 at 10:51
  • 1
    $\begingroup$ 256-bit block size, really? What cipher is this? $\endgroup$ – fgrieu Dec 25 '15 at 11:08
  • 1
    $\begingroup$ it's Rijndael cipher $\endgroup$ – barmaley Dec 25 '15 at 14:16
  • 3
    $\begingroup$ Rijndael supports several block size, AES is Rijndael with a block size of 128-bits. $\endgroup$ – zaph Dec 26 '15 at 16:13
3
$\begingroup$

Yes, this is fine.

There is a practical disadvantage in space used, if you don't otherwise need to store the size in plaintext. A size field will usually take 32 or 64 bits, whereas typical padding adds one byte on average. Also, if you use encrypt-then-MAC you need to include the length as part of the authenticated data.

$\endgroup$
  • 1
    $\begingroup$ Of course, the deciphering party should validate the size field: sign, maximum value. $\endgroup$ – fgrieu Dec 25 '15 at 15:29
1
$\begingroup$

It is generally fine EXCEPT the fact, that you should not think that one replaces another : it's the BEST practice to use both, but using one of them is better than not using anything at all. They're helping each other in terms of securing, and they are different things.

$\endgroup$
  • $\begingroup$ Too weird to understand your point, dude )) $\endgroup$ – barmaley Dec 25 '15 at 19:34
  • $\begingroup$ @barmaley The point IS that padding increases the security just by being applied, because no "zerofill trail" and another weak conditions are present in the system. Regardless of the "key length"/"block size"/"bits elaborated". And the increase of "key length"/"block size"/"bits elaborated" is increasing the cost of cracking system(=makes the system more secure), even without any padding at all. They are complementary, they are not replacing each other and not a competing techniques. That's my point. $\endgroup$ – Alexey Vesnin Dec 25 '15 at 19:52
  • $\begingroup$ Not really sure that padding increases security, in some cases it's vulnerability. See padding oracle attack $\endgroup$ – barmaley Dec 25 '15 at 20:50
  • $\begingroup$ @barmaley There are many types of padding and no strict standart for it : it's just a type of process. Design your own schema and embed into your system. $\endgroup$ – Alexey Vesnin Dec 25 '15 at 21:28
  • 1
    $\begingroup$ I don't see any advantage from using both. Padding does not add security. Also, there definitely are standards for padding, like in PKCS#5. $\endgroup$ – otus Dec 26 '15 at 7:50

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.