I'm trying to use the AesManaged class in C#, and I have a problem (and no, I don't have the source code available, but I can explain what I'm doing).

I have it set to 128 bit blocks and 256 bit keys.

I'm using ECB mode, an all zero IV and padding my data with zeros. This may seem stupid, but I'm always encrypting only tiny pieces of data that are exactly 16 bytes/128 bits (so I initially tried it with no padding, but I got an error, so I switched to zeros), and I have other encryption too, so security is not going to be a problem in this case.

Anyway, I have it encrypting fine. I give it the data and key, and it gives me back seemingly random data. Then when I try to decrypt using the ciphertext and the same key, it gives me back a null string or array of zeros (depending on which stream reading function I use). I based my program on the MSDN example for AesManaged at the bottom of this page:

https://msdn.microsoft.com/en-us/library/system.security.cryptography.aesmanaged(v=vs.110).aspx

So it's basically like that but with a few setting slightly different. What could be wrong?

Post some code (not just the MSDN page) and we might be able to see what is wrong.

Well, Tex Murphy, the reason I don't generally post code is because it's private, but also, it's a huge pain, because the code is not on this computer; it's on an airgapped computer. I suppose I could get some of it though, but I mean really, it just follows along with what MSDN is doing, I put the same nested usings with the same objects, etc. And I told you how the settings are different.

Lactose: ditto.

$10 says you are reusing a MemoryStream in a write-then-read pattern and forgot to reset the Position before reading from it.

Thanks for the suggestion, and I'll look into that, although honestly, I have my doubts, because:

- I made one memory stream for the encryption, which worked fine

- then a different memory stream for the decryption, which doesn't crash like it hit the end, but rather just outputs 0 for all bytes

- I only call each one once

but first thing tomorrow morning, I'll try setting the position to index 0 before I call the read, just in case that's the problem.

Well, Tex Murphy, the reason I don't generally post code is because it's private, but also, it's a huge pain, because the code is not on this computer; it's on an airgapped computer.

Psychic debugging generally doesn't work well. I'm guessing it is line 472, but my crystal ball is hazy.

I mean really, it just follows along with what MSDN is doing, I put the same nested usings with the same objects, etc ... it's basically like that but with a few setting slightly different..

You are doing something different that breaks it, or the MSDN example is broken, or perhaps both. But since there are no comments about that on the page, probably it is just your error.

However, we can only guess what that is using our psychic debuggers unless you actually paste the broken code for review.

Also, note that real security researchers publish their code. The analogy is that with true security you can give your opponent a locked box which they cannot open. You can provide the plans, hundreds of implementations of the box to play with, and all the time and tools in the world to open it, and they still will be unable to open your box except by brute force. Hundreds of experts review it and look for flaws before it enters production.

You might have told us how the settings are different. You might also have told us how you incorrectly think the settings are different.

I know how my settings are, thank you very much.

You don't want to post code partly because it's a pain. Something else that's a pain is debugging via guesswork. But that's pain you're ok with, because it's not your pain? If you actually want help, do your part.

Touche. But in the case of a very simple program, where you have code from a page that I basically just copied, and made a few specific changes that I informed you about, I thought that something obvious might jump out, and someone would know the error (or at least a likely culprit), without having to resort to posting code. Is that so wrong? Then if none of your suggestions worked, I'd go get the code. But I'll have to try them first.

The second post shows something interesting: If you set the key first, and then the key size second, it sounds like it erases the key. Perhaps something similar is afoot with your "settings slightly different" you mention.

Yeah, it seems like it would do that. But I didn't set my code that way. I just initialized the key and block sizes, then set the data for them.

Without the code in question, we cannot magically debug the problem. Feel free to make another topic when you have the actual code causing you trouble in hand and available to post.