Is it safe to use cipher block sizing instead of padding?

Question

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?

So you are zero padding to block length and storing the actual length in plain text? One consideration is that you need to authenticate the length or else an attacker can add some zeros to the end or lop some more bytes out. — otus, Dec 25 '15 at 07:45
@barmaley, what is the danger of being able to modify the message? That depends on what you are using the encryption for. — otus, Dec 25 '15 at 09:00
In my case it's not a problem. And anyway attacker can change cipher message - doesn't matter is it padded or not — Barmaley, Dec 25 '15 at 09:02
@barmaley, yes, that is why authentication is almost always a good idea, I merely pointed out that you'd need to include the size as part of authenticated data. — otus, Dec 25 '15 at 09:05
Rijndael cipher (AES) block size is 128 bits unless you are using some special implementation ?? Key size is 128 / 192 or 256 bits. — Biv, Dec 26 '15 at 09:57
Rijndael supports several block size, AES is Rijndael with a block size of 128-bits. — zaph, Dec 26 '15 at 16:13

score 3 · Accepted Answer · edited Apr 13 '17 at 12:48

3

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.

edited Apr 13 '17 at 12:48

Community

1

answered Dec 25 '15 at 10:53

otus

32,132
5
70
165

1

Of course, the deciphering party should validate the size field: sign, maximum value. – fgrieu Dec 25 '15 at 15:29

score 1 · Answer 2 · answered Dec 25 '15 at 19:30

1

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.

answered Dec 25 '15 at 19:30

Alexey Vesnin

226
5
7

Too weird to understand your point, dude )) – Barmaley Dec 25 '15 at 19:34
@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. – Alexey Vesnin Dec 25 '15 at 19:52
Not really sure that padding increases security, in some cases it's vulnerability. See padding oracle attack – Barmaley Dec 25 '15 at 20:50
@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. – Alexey Vesnin Dec 25 '15 at 21:28
1

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. – otus Dec 26 '15 at 07:50
@otus of course there are some variants of padding standardized! But there's no strict requirement of using only standardized padding. And about adding a security - some standardized padding types may not add one, but not all of them – Alexey Vesnin Dec 26 '15 at 14:01

Is it safe to use cipher block sizing instead of padding?

2 Answers2