Return to Answer

You are basically using gzip to convey the length of the given message. As long as your implementation of AES-CBC is secure (e.g. by using a random IV) then the given scheme should be secure against padding oracle attacks. This is easy to prove as there is nothing that removes the padding from the plaintext.

CBC padding in general does not add any security to the block cipher mode. You could just pad with zero bytes if you already know the size of the plaintext. In that sense the scheme is safe as long as no information is leaked to an attacker after decryption. Note that using gzip may influence the size of the plaintext so you need to make sure an attacker cannot learn too much from the size of the ciphertext.

Your scheme is therefore safe if the attacker only has access to the ciphertext. In that case it does provide confidentiality.

So now for the bad news...

This does not mean that the data within the ciphertext container cannot be altered. As there is no cryptographically secure authentication tag present, an attacker could very well be able to change the ciphertext in a way that cannot be detected. So the application code that processes the decrypted data could still be fooled to leak information about the plain text.

In other words, although you have now successfully protected against padding oracle attacks, you haven't protected yourself against similar, active attacks on the ciphertext. Please add some kind of secure authentication tag. It is the only known secure way to protect yourself against these kinds of active attacks.

You are basically using gzip to convey the length of the given message. As long as your implementation of AES-CBC is secure (e.g. by using a random IV) then the given scheme should be secure against padding oracle attacks. This is easy to prove as there is nothing that removes the padding from the plaintext.

CBC padding in general does not add any security to the block cipher mode. You could just pad with zero bytes if you already know the size of the plaintext. In that sense the scheme is safe as long as no information is leaked to an attacker after decryption. Note that using gzip may influence the size of the plaintext so you need to make sure an attacker cannot learn too much from the size of the ciphertext.

Your scheme is therefore safe if the attacker only has access to the ciphertext. In that case it does provide confidentiality.

So now for the bad news...

This does not mean that the data within the ciphertext container cannot be altered. As there is no cryptographically secure authentication tag present, an attacker could very well be able to change the ciphertext in a way that cannot be detected. So the application code that processes the decrypted data could still be fooled to leak information about the plain text.

In other words, although you have now successfully protected against padding oracle attacks, you haven't protected yourself against similar, active attacks on the ciphertext. Please add some kind of secure authentication tag. It is by far the best way to protect yourself against these kinds of active attacks.

You are basically using gzip to convey the length of the given message. As long as your implementation of AES-CBC is secure (e.g. by using a random IV) then the given scheme should be secure against padding oracle attacks. This is easy to prove as there is nothing that removes the padding from the plaintext.

CBC padding in general does not add any security to the block cipher mode. You could just pad with zero bytes if you already know the size of the plaintext. In that sense the scheme is safe as long as no information is leaked to an attacker after decryption. Note that using gzip may influence the size of the plaintext so you need to make sure an attacker cannot learn too much from the size of the ciphertext.

Your scheme is therefore safe if the attacker only has access to the ciphertext. In that case it does provide confidentiality.

So now for the bad news...

This does not mean that the data within the ciphertext container cannot be altered. As there is no cryptographically secure authentication tag present, an attacker could very well be able to change the ciphertext in a way that cannot be detected. So the application code that processes the decrypted data could still be fooled to leak information about the plain text.

In other words, although you have now successfully protected against padding oracle attacks, you haven't protected yourself against similar attacks on the ciphertext. Please add some kind of secure authentication tag. It is the only known secure way to protect yourself against these kinds of active attacks.

You are basically using gzip to convey the length of the given message. As long as your implementation of AES-CBC is secure (e.g. by using a random IV) then the given scheme should be secure against padding oracle attacks. This is easy to prove as there is nothing that removes the padding from the plaintext.

CBC padding in general does not add any security to the block cipher mode. You could just pad with zero bytes if you already know the size of the plaintext. In that sense the scheme is safe as long as no information is leaked to an attacker after decryption. Note that using gzip may influence the size of the plaintext so you need to make sure an attacker cannot learn too much from the size of the ciphertext.

Your scheme is therefore safe if the attacker only has access to the ciphertext. In that case it does provide confidentiality.

So now for the bad news...

This does not mean that the data within the ciphertext container cannot be altered. As there is no cryptographically secure authentication tag present, an attacker could very well be able to change the ciphertext in a way that cannot be detected. So the application code that processes the decrypted data could still be fooled to leak information about the plain text.

In other words, although you have now successfully protected against padding oracle attacks, you haven't protected yourself against similar, active attacks on the ciphertext. Please add some kind of secure authentication tag. It is the only known secure way to protect yourself against these kinds of active attacks.

You are basically using gzip to convey the length of the given message. As long as your implementation of AES-CBC is secure (e.g. by using a random IV) then the given scheme should be secure against padding oracle attacks. This is easy to prove as there is nothing that removes the padding from the plaintext.

So now for the bad news...

This does not mean that the data within the ciphertext container cannot be altered. As there is no cryptographically secure authentication tag present, an attacker could very well be able to change the ciphertext in a way that cannot be detected. So the application code that processes the decrypted data could still be fooled to leak information about the plain text.

In other words, although you have now successfully protected against padding oracle attacks, you haven't protected yourself against similar attacks on the ciphertext. Please add some kind of secure authentication tag. It is the only known secure way to protect yourself against these kinds of active attacks.

You are basically using gzip to convey the length of the given message. As long as your implementation of AES-CBC is secure (e.g. by using a random IV) then the given scheme should be secure against padding oracle attacks. This is easy to prove as there is nothing that removes the padding from the plaintext.

CBC padding in general does not add any security to the block cipher mode. You could just pad with zero bytes if you already know the size of the plaintext. In that sense the scheme is safe as long as no information is leaked to an attacker after decryption. Note that using gzip may influence the size of the plaintext so you need to make sure an attacker cannot learn too much from the size of the ciphertext.

Your scheme is therefore safe if the attacker only has access to the ciphertext. In that case it does provide confidentiality.

So now for the bad news...

This does not mean that the data within the ciphertext container cannot be altered. As there is no cryptographically secure authentication tag present, an attacker could very well be able to change the ciphertext in a way that cannot be detected. So the application code that processes the decrypted data could still be fooled to leak information about the plain text.

In other words, although you have now successfully protected against padding oracle attacks, you haven't protected yourself against similar attacks on the ciphertext. Please add some kind of secure authentication tag. It is the only known secure way to protect yourself against these kinds of active attacks.