Halp meh, plz... I have run across a problem and I have absolutely no idea how to go about solving it...

So basically I need to decrypt a TDES encrypted Azure service bus message. Can be done in a straightforward manner in .NET Framework solution with just your regular old System.Security.Cryptography namespace methods. As per MSDN docs you'd expect it to work in a .NET Core solution as well... No, no it doesn't. Getting an exception "Padding is invalid and cannot be removed". Narrowed the cause down to just something weird and undocumented happening due to Framework <> Core....

And before someone says 'just use .NET Framework then', let me clarify that it's not a possibility. While in production it could be viable, I'm not developing on a Windows machine...

How do I go about solving this issue? Any tips and pointers?

  • 0
  • 0
    @jespersh I was hoping there could be some other way than to open an issue there and wait that someone gets around to fixing it...
  • 0
    Can't you decrypt without padding and then remove it 'manually'?
  • 0
    Can you use something like https://github.com/rbonestell/...

    I don't know a lot about encryption bit it appears this does the manual padding. Look at the transform function.
  • 0
    @sbiewald isn't that gonna f up the output? I mean I'm flying blind here, trying to learn as I go, but somehow I'd think that if it's encrypted with a certain padding mode, decrypting it with a different padding mode would not work... I might be wrong here, though
  • 0
    @demortes no luck :/
  • 0
    @100110111 Padding is applied in the following order:

    (plaintext) -> add padding -> encrypt -> (ciphertext) -> decrypt -> remove padding -> (plaintext)

    Thus decrypting without padding just gives you the plaintext with padding.

    Strictly speaking, padding is (mostly) independent from encryption, but for practicability reasons it is often included in the same place or classes.

    Try to decrypt it *without any padding at all* and look at the result.
  • 0
    Btw, solved it by switching to dotnet framework instead of core (got rid of the padding error, got a bad data error instead), and then actually acquiring the correct encryption key! There'd been a mixup and the service provider had accidentally given me a key that belonged somewhere else 🙄
  • 0
    Bad data format is usually a x64 trying to use x86 or reverse images. Or even with Any CPU.
    I'm currently dealing with this issue at work with some older code
  • 0
    @jespersh this time it was just a wrong encryption key that caused the bad data exception. Don't know if it was the cause for the invalid padding issue as well, since I got rid of that by just switching the target framework from dotnet core to dotnet 4.8
  • 1
    @100110111 That it was just the wrong key makes sense.

    Usually padding looks like this, that x bytes of value x are appended to the plaintext:

    After the decryption, it may decrypt to this:

    If the block size is 8 (as it is for DES/3DES), 9 is an invalid padding, thus an error is raised.
  • 0
    @sbiewald funny thing is that was my first instinct that maybe the key was wrong, but I was assured I had the right one. After pestering my contact for several days about it we finally double checked it - and of course I had a wrong one...
Add Comment