Recently while working to integrate the Cross Site Authentication framework, I developed in my current project, with a Hosted Service used by the client; I ran into an unexpected issue whereby the assertion generated by our system could not be decrypted by the hosted service. This was inspite of us using a proper standard encryption algorithm like TripleDES.
It took me some effort to actually dig deeper into the system when I finally understood the root cause of the issue. This blog article is to explain the issue and to document the solution so that it can act as a ready reference for me and for others too.
TripleDES is a block cipher, which means a block of data (64 bits) gets encrypted at a time. The data that we need to encrypt may not always be an exact multiple of 64 bits, hence we need data padding. Moreover to make the algorithm more secure we can use the encrypted out of the first block of 64 bits while encrypting the second block of 64 bit and so on. This is called as feedback mode.
The list of various feedback modes and padding options availabe for TripleDES and other similar block ciphers is available in the Cipher section of JCE documentation.
In my implementation I was using ECB feedback mode (which means no feedback) and PKCS5Padding.
The cause of the issue seems to be the way .NET implements TripleDES ECB mode. As per the RFC ECB mode should not use any feedback, however it seems that the .NET implementation for ECB mode does use the Initialization Vector for decryption. Moreover if it is not set, it uses a random value for IV and starts decryption L. This will definitely cause the decryption to fail.
So the solution is to set the Initialization Vector to 00 00 00 00 00 00 00 00 (64 bits 0). This has the effect that now when the IV is XORed with the first 64 bits of the raw data to be decrypted, it does not cause any data change, hence eliminating feedback and resulting in proper decryption.
It took me some effort to actually dig deeper into the system when I finally understood the root cause of the issue. This blog article is to explain the issue and to document the solution so that it can act as a ready reference for me and for others too.
TripleDES is a block cipher, which means a block of data (64 bits) gets encrypted at a time. The data that we need to encrypt may not always be an exact multiple of 64 bits, hence we need data padding. Moreover to make the algorithm more secure we can use the encrypted out of the first block of 64 bits while encrypting the second block of 64 bit and so on. This is called as feedback mode.
The list of various feedback modes and padding options availabe for TripleDES and other similar block ciphers is available in the Cipher section of JCE documentation.
In my implementation I was using ECB feedback mode (which means no feedback) and PKCS5Padding.
The cause of the issue seems to be the way .NET implements TripleDES ECB mode. As per the RFC ECB mode should not use any feedback, however it seems that the .NET implementation for ECB mode does use the Initialization Vector for decryption. Moreover if it is not set, it uses a random value for IV and starts decryption L. This will definitely cause the decryption to fail.
So the solution is to set the Initialization Vector to 00 00 00 00 00 00 00 00 (64 bits 0). This has the effect that now when the IV is XORed with the first 64 bits of the raw data to be decrypted, it does not cause any data change, hence eliminating feedback and resulting in proper decryption.
No comments:
Post a Comment