0

I am trying to pass encrypted data from a Linux system to a Windows system. On the Linux system I am programming in C and using the libmcrypt library.

I am using Rijndael-128 in CBC mode and my code is based upon the example here https://gist.github.com/bricef/2436364 I am using a 16 byte key and a 16 byte IV. I have written the program which encrypts and then decrypts 16 bytes of ASCII text. I can see that the encrypted data is 16 bytes long.

Under Windows I am using VS2010 and C#. My code is based upon the example here. (first code block) Encrypting & Decrypting a String in C# except that I have changed this to pass the key, IV and data directly as byte arrays. I use the same 16 byte key and 16 byte IV as on the Linux system. I encrypt the same 16 bytes of ASCII text.

My test Windows program successfully encrypts and decrypts the data. However the encrypted text is 32 bytes with, strangely, the first 16 bytes being the same as the 16 bytes under Linux.

How can I achieve the same output on both systems?

Community
  • 1
  • 1
IanYali
  • 1

2 Answers2

0

If you're literally using the code from the links you provided, you can see that C-code is using ASCII whereas c# code is using UTF8, which would account for size increase if any one of the original characters is represented in more than 8 bits in UTF8. (it would probably take just one due to padding).

zaitsman
  • 8,984
  • 6
  • 47
  • 79
  • Thanks Zaitsman. I was not following the code blindly - just using it as a base. So I was encrypting the same characters at each end. I was trying to encrypt a single block (16 bytes). mcrypt encrypted the block and gave me 16 encrypted bytes. The Windows implentation padded it to 32 bytes, ie added 16 x 0x10 and then encrypted it to produce 32 encrypted bytes. – IanYali Sep 22 '14 at 11:12
  • Have you tried setting the padding mode to none?: `using (RijndaelManaged symmetricKey = new RijndaelManaged()) { symmetricKey.Padding = PaddingMode.None; //.. do encryption } ` – zaitsman Sep 23 '14 at 05:30
0

mcrypt is using zero padding by default, up to the first block boundary (0..15 bytes). C# is using PKCS#7 padding by default, which pads up to the first block boundary that follows (1..16 bytes). You should implement either one of them on both sides. PKCS#7 padding should be preferred (getting you 32 bytes of plaintext).

Make sure that the correct encoding is used on both sides. Again, UTF-8 should be preferred, but ASCII could be used as well.

Note that using the aging mcrypt libraries is not a good idea, nor is transmitting ciphertext with a zero IV and without MAC. Doing so may lead to complete loss of confidentiality of the plaintext (integrity and authentication are already not provided by CBC mode encryption, and usually those are required as well).

Just grabbing code from the internet without understanding may lead to a system that "works" in the end, but if you don't understand what you are doing, it is extremely unlikely to result in a system that is actually secure.

Maarten Bodewes
  • 90,524
  • 13
  • 150
  • 263
  • If you just implement CBC and PKCS#7 padding and use it using sockets, anybody who followed Crypto I from Dan Boneh can actually crack your system in microseconds, with existing code. – Maarten Bodewes Sep 21 '14 at 14:41
  • Thanks Owlstead. The two systems are exchanging encrypted data as part of an authentication system so I guess that I do not need CBC-MAC. Can you recommend a more modern library than mcrypt? I would love to take Dan Boneh's course but it takes 6 weeks and I don't have the time right now! I am exchanging very small amounts of random text - could that really be cracked in microseconds? – IanYali Sep 22 '14 at 11:05
  • 1
    It depends on the system if random text is safe. Padding Oracles *could* still apply. You may want to use ECB mode without padding for random text. In the systems that I work with, a MAC is added as well, but that could also lead to vulnerabilities. Authentication systems must be designed well, I cannot make a blanket statement about the security of this unknown scheme. – Maarten Bodewes Sep 22 '14 at 11:57