Rindjael and testing failure

[Eugen Feraru]

Hello all,

I am trying to test the business logic of an application that uses Rindjael
encryption, by testing it when 'tampering' with the encrypted cipher.
The scenario assumes that the encrypted cipher has been tampered with (by
changing some of the values, but not removing them). I expected Rindjael
component STILL provide a decrypted cipher, other than the one originally
encrypted. By playing with the encrypted cipher and changing some of its
byte values, the algorithm sometimes works, and most of the times generates
this exception:

System.Security.Cryptography.Cryptographic : PKCS7 padding is invalid and
cannot be removed.
at
System.Security.Cryptography.RijndaelManagedTransf orm._DecryptData(Byte[]
inputBuffer, Int32 inputOffset, Int32 inputCount, Boolean usingPKCSPadding)
at
System.Security.Cryptography.RijndaelManagedTransf orm.TransformFinalBlock(By
te[] inputBuffer, Int32 inputOffset, Int32 inputCount)
at System.Security.Cryptography.CryptoStream.FlushFin alBlock()
at System.Security.Cryptography.CryptoStream.Close()

I have been doing some research on the topic but I have not found yet an
answer.
Any help, it would be greatly appreciated.

Thanks,
Eugen

[Hernan de Lahitte]

Eugen

There are two things here.
First, Rijndael (the alg name) does not handle any tampering issue or data
integrity. There are several alternatives to this topic (Digital signatures,
Hashing, etc.).
On the other hand, the exception that you refer to is caused by an exception
on the padding scheme (PKCS7 by default) and is generated by your changes on
the encrypted data. In this scenario, the padding functionality is behaving
like a sort of integrity check. However, the padding applied in these block
ciphers like this algorithm has another goal and by no means it should be
used to detect tampering.

--
Hernan de Lahitte
Lagash Systems S.A.
[url]http://weblogs.asp.net/hernandl[/url]


This posting is provided "AS IS" with no warranties, and confers no rights.

"Eugen Feraru" <NoSpam@Spam.com> wrote in message
news:urMka%23OPEHA.3044@TK2MSFTNGP10.phx.gbl...

> Hello all,
>
> I am trying to test the business logic of an application that uses

Rindjael

> encryption, by testing it when 'tampering' with the encrypted cipher.
> The scenario assumes that the encrypted cipher has been tampered with (by
> changing some of the values, but not removing them). I expected Rindjael
> component STILL provide a decrypted cipher, other than the one originally
> encrypted. By playing with the encrypted cipher and changing some of its
> byte values, the algorithm sometimes works, and most of the times

generates

> this exception:
>
> System.Security.Cryptography.Cryptographic : PKCS7 padding is invalid and
> cannot be removed.
> at
> System.Security.Cryptography.RijndaelManagedTransf orm._DecryptData(Byte[]
> inputBuffer, Int32 inputOffset, Int32 inputCount, Boolean

usingPKCSPadding)

> at
>

System.Security.Cryptography.RijndaelManagedTransf orm.TransformFinalBlock(By

> te[] inputBuffer, Int32 inputOffset, Int32 inputCount)
> at System.Security.Cryptography.CryptoStream.FlushFin alBlock()
> at System.Security.Cryptography.CryptoStream.Close()
>
> I have been doing some research on the topic but I have not found yet an
> answer.
> Any help, it would be greatly appreciated.
>
> Thanks,
> Eugen
>
>

[Eugen Feraru]

Hernan,
Thanks for your reply.
I am using the Rindjael algorithm to encrypt some data and then pass it over
to a recipient. Both the sender and the receiver use the same symmetric
algorithm key. Do you think that it is correct to assume that if the data is
decrypted correctly - use it, otherwise if an exception occurs is incorrect?

Thanks,
Eugen


"Hernan de Lahitte" <hernan@lagash.com> wrote in message
news:ePnh2XPPEHA.4036@TK2MSFTNGP12.phx.gbl...

> Eugen
>
> There are two things here.
> First, Rijndael (the alg name) does not handle any tampering issue or data
> integrity. There are several alternatives to this topic (Digital

signatures,

> Hashing, etc.).
> On the other hand, the exception that you refer to is caused by an

exception

> on the padding scheme (PKCS7 by default) and is generated by your changes

on

> the encrypted data. In this scenario, the padding functionality is

behaving

> like a sort of integrity check. However, the padding applied in these

block

> ciphers like this algorithm has another goal and by no means it should be
> used to detect tampering.
>
> --
> Hernan de Lahitte
> Lagash Systems S.A.
> [url]http://weblogs.asp.net/hernandl[/url]
>
>
> This posting is provided "AS IS" with no warranties, and confers no

rights.

>
> "Eugen Feraru" <NoSpam@Spam.com> wrote in message
> news:urMka%23OPEHA.3044@TK2MSFTNGP10.phx.gbl...

> > Hello all,
> >
> > I am trying to test the business logic of an application that uses

> Rindjael

> > encryption, by testing it when 'tampering' with the encrypted cipher.
> > The scenario assumes that the encrypted cipher has been tampered with

(by

> > changing some of the values, but not removing them). I expected Rindjael
> > component STILL provide a decrypted cipher, other than the one

originally

> > encrypted. By playing with the encrypted cipher and changing some of its
> > byte values, the algorithm sometimes works, and most of the times

> generates

> > this exception:
> >
> > System.Security.Cryptography.Cryptographic : PKCS7 padding is invalid

and

> > cannot be removed.
> > at
> >

System.Security.Cryptography.RijndaelManagedTransf orm._DecryptData(Byte[]

> > inputBuffer, Int32 inputOffset, Int32 inputCount, Boolean

> usingPKCSPadding)

> > at
> >

>

System.Security.Cryptography.RijndaelManagedTransf orm.TransformFinalBlock(By

> > te[] inputBuffer, Int32 inputOffset, Int32 inputCount)
> > at System.Security.Cryptography.CryptoStream.FlushFin alBlock()
> > at System.Security.Cryptography.CryptoStream.Close()
> >
> > I have been doing some research on the topic but I have not found yet an
> > answer.
> > Any help, it would be greatly appreciated.
> >
> > Thanks,
> > Eugen
> >
> >

>
>

[Hernan de Lahitte]

Well, as I told you in my last post, the padding mechanism alone will not
guarantee data integrity and should use additional measures to address the
data integrity threat. The cryptography .NET Framework API has several
classes that will help you with these issues. Check out the RSA related
classes for data signing or the keyed algs (HMACSHA1) for keyed hashing
algorithms. Alternatively, you might use the DPAPI functions that have built
in data integrity and if your scenario applies, it free you of the key
management hassle.

You can find managed code samples of all these functions here:
[url]http://weblogs.asp.net/hernandl/archive/2004/03/08/85884.aspx[/url]


--
Hernan de Lahitte
Lagash Systems S.A.
[url]http://weblogs.asp.net/hernandl[/url]


This posting is provided "AS IS" with no warranties, and confers no rights.

"Eugen Feraru" <NoSpam@Spam.com> wrote in message
news:%23olxzFQPEHA.632@TK2MSFTNGP12.phx.gbl...

> Hernan,
> Thanks for your reply.
> I am using the Rindjael algorithm to encrypt some data and then pass it

over

> to a recipient. Both the sender and the receiver use the same symmetric
> algorithm key. Do you think that it is correct to assume that if the data

is

> decrypted correctly - use it, otherwise if an exception occurs is

incorrect?

>
> Thanks,
> Eugen
>
>
> "Hernan de Lahitte" <hernan@lagash.com> wrote in message
> news:ePnh2XPPEHA.4036@TK2MSFTNGP12.phx.gbl...

> > Eugen
> >
> > There are two things here.
> > First, Rijndael (the alg name) does not handle any tampering issue or

data

> > integrity. There are several alternatives to this topic (Digital

> signatures,

> > Hashing, etc.).
> > On the other hand, the exception that you refer to is caused by an

> exception

> > on the padding scheme (PKCS7 by default) and is generated by your

changes

> on

> > the encrypted data. In this scenario, the padding functionality is

> behaving

> > like a sort of integrity check. However, the padding applied in these

> block

> > ciphers like this algorithm has another goal and by no means it should

be

> > used to detect tampering.
> >
> > --
> > Hernan de Lahitte
> > Lagash Systems S.A.
> > [url]http://weblogs.asp.net/hernandl[/url]
> >
> >
> > This posting is provided "AS IS" with no warranties, and confers no

> rights.

> >
> > "Eugen Feraru" <NoSpam@Spam.com> wrote in message
> > news:urMka%23OPEHA.3044@TK2MSFTNGP10.phx.gbl...

> > > Hello all,
> > >
> > > I am trying to test the business logic of an application that uses

> > Rindjael

> > > encryption, by testing it when 'tampering' with the encrypted cipher.
> > > The scenario assumes that the encrypted cipher has been tampered with

> (by

> > > changing some of the values, but not removing them). I expected

Rindjael

> > > component STILL provide a decrypted cipher, other than the one

> originally

> > > encrypted. By playing with the encrypted cipher and changing some of

its

> > > byte values, the algorithm sometimes works, and most of the times

> > generates

> > > this exception:
> > >
> > > System.Security.Cryptography.Cryptographic : PKCS7 padding is invalid

> and

> > > cannot be removed.
> > > at
> > >

> System.Security.Cryptography.RijndaelManagedTransf orm._DecryptData(Byte[]

> > > inputBuffer, Int32 inputOffset, Int32 inputCount, Boolean

> > usingPKCSPadding)

> > > at
> > >

> >

>

System.Security.Cryptography.RijndaelManagedTransf orm.TransformFinalBlock(By

> > > te[] inputBuffer, Int32 inputOffset, Int32 inputCount)
> > > at System.Security.Cryptography.CryptoStream.FlushFin alBlock()
> > > at System.Security.Cryptography.CryptoStream.Close()
> > >
> > > I have been doing some research on the topic but I have not found yet

an

> > > answer.
> > > Any help, it would be greatly appreciated.
> > >
> > > Thanks,
> > > Eugen
> > >
> > >

> >
> >

>
>

[Alek Davis]

Eugen,

A reasonably simple option would be to generate a hash of plain text (using
SHA-1 or MD5) and append it at the beginning of the plain text value before
encryption. After decrypting data, you can split the result into two pieces
(hash and plain text; the size of hash is always const: 16 bytes for MD5 and
20 bytes for SHA-1), recalculate hash using the decrypted value and compare
the result with the decrypted hash. If both hash values match, everything
should be fine.

Alek

"Eugen Feraru" <NoSpam@Spam.com> wrote in message
news:%23olxzFQPEHA.632@TK2MSFTNGP12.phx.gbl...

> Hernan,
> Thanks for your reply.
> I am using the Rindjael algorithm to encrypt some data and then pass it

over

> to a recipient. Both the sender and the receiver use the same symmetric
> algorithm key. Do you think that it is correct to assume that if the data

is

> decrypted correctly - use it, otherwise if an exception occurs is

incorrect?

>
> Thanks,
> Eugen
>
>
> "Hernan de Lahitte" <hernan@lagash.com> wrote in message
> news:ePnh2XPPEHA.4036@TK2MSFTNGP12.phx.gbl...

> > Eugen
> >
> > There are two things here.
> > First, Rijndael (the alg name) does not handle any tampering issue or

data

> > integrity. There are several alternatives to this topic (Digital

> signatures,

> > Hashing, etc.).
> > On the other hand, the exception that you refer to is caused by an

> exception

> > on the padding scheme (PKCS7 by default) and is generated by your

changes

> on

> > the encrypted data. In this scenario, the padding functionality is

> behaving

> > like a sort of integrity check. However, the padding applied in these

> block

> > ciphers like this algorithm has another goal and by no means it should

be

> > used to detect tampering.
> >
> > --
> > Hernan de Lahitte
> > Lagash Systems S.A.
> > [url]http://weblogs.asp.net/hernandl[/url]
> >
> >
> > This posting is provided "AS IS" with no warranties, and confers no

> rights.

> >
> > "Eugen Feraru" <NoSpam@Spam.com> wrote in message
> > news:urMka%23OPEHA.3044@TK2MSFTNGP10.phx.gbl...

> > > Hello all,
> > >
> > > I am trying to test the business logic of an application that uses

> > Rindjael

> > > encryption, by testing it when 'tampering' with the encrypted cipher.
> > > The scenario assumes that the encrypted cipher has been tampered with

> (by

> > > changing some of the values, but not removing them). I expected

Rindjael

> > > component STILL provide a decrypted cipher, other than the one

> originally

> > > encrypted. By playing with the encrypted cipher and changing some of

its

> > > byte values, the algorithm sometimes works, and most of the times

> > generates

> > > this exception:
> > >
> > > System.Security.Cryptography.Cryptographic : PKCS7 padding is invalid

> and

> > > cannot be removed.
> > > at
> > >

> System.Security.Cryptography.RijndaelManagedTransf orm._DecryptData(Byte[]

> > > inputBuffer, Int32 inputOffset, Int32 inputCount, Boolean

> > usingPKCSPadding)

> > > at
> > >

> >

>

System.Security.Cryptography.RijndaelManagedTransf orm.TransformFinalBlock(By

> > > te[] inputBuffer, Int32 inputOffset, Int32 inputCount)
> > > at System.Security.Cryptography.CryptoStream.FlushFin alBlock()
> > > at System.Security.Cryptography.CryptoStream.Close()
> > >
> > > I have been doing some research on the topic but I have not found yet

an

> > > answer.
> > > Any help, it would be greatly appreciated.
> > >
> > > Thanks,
> > > Eugen
> > >
> > >

> >
> >

>
>