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?

Improve this question
$\endgroup$
12
  • 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
    Commented Dec 25, 2015 at 9:00
  • 1
    $\begingroup$ @barmaley, a MAC rather than a hash, but essentially. $\endgroup$
    – otus
    Commented Dec 25, 2015 at 10:51
  • 1
    $\begingroup$ 256-bit block size, really? What cipher is this? $\endgroup$
    – fgrieu ♦
    Commented Dec 25, 2015 at 11:08
  • 1
    $\begingroup$ it's Rijndael cipher $\endgroup$
    – Barmaley
    Commented Dec 25, 2015 at 14:16
  • 3
    $\begingroup$ Rijndael supports several block size, AES is Rijndael with a block size of 128-bits. $\endgroup$
    – zaph
    Commented Dec 26, 2015 at 16:13

2 Answers 2

Reset to default
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.

Improve this answer
$\endgroup$
1
  • 1
    $\begingroup$ Of course, the deciphering party should validate the size field: sign, maximum value. $\endgroup$
    – fgrieu ♦
    Commented Dec 25, 2015 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.

Improve this answer
$\endgroup$
6
  • $\begingroup$ Too weird to understand your point, dude )) $\endgroup$
    – Barmaley
    Commented Dec 25, 2015 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
    Commented Dec 25, 2015 at 19:52
  • $\begingroup$ Not really sure that padding increases security, in some cases it's vulnerability. See padding oracle attack $\endgroup$
    – Barmaley
    Commented Dec 25, 2015 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
    Commented Dec 25, 2015 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
    Commented Dec 26, 2015 at 7:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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