Feature request: AES ECB/NoPadding option for encryption

[GTP95]

Just like for AES decryption there's the option "ECB/NoPAdding", it could be useful to have the same option for encryption as well, to avoid confusion when the resulting ciphertext is longer than expected.
Thank you for maintaining this tool,

GTP95

[plvie]

AES encryption operates on fixed 16-byte blocks. This means that unless your plaintext is exactly a multiple of 16 bytes, you must add padding to complete the final block. While decryption can offer an option like "ECB/NoPadding" when you know the data is correctly block-aligned, for encryption, you can't avoid padding if the data doesn't naturally fill a complete block.

[GTP95]

In general, you're right. But there are specific cases where there's no padding. In my case, I was looking at the output of a hardware implementation of AES, that just implements the plain block cipher without the padding. So if you encrypt one block of plaintext, you get one block of ciphertext.

[plvie]

Oh, yes you are right. We can just check if the data fits 16 bytes. If it does, we can encrypt it directly without adding any padding.
I can work on it.

[GTP95]

Thank you for considering this use-case. However, you were correct in your first message that, for an implementation that considers padding, you need to have at least two blocks of output to avoid ambiguities. For this reason, I would suggest to have the "plain" ECB without padding as a separate feature, instead of having the same implementation adding or not adding the padding depending on the ciphertext's length. My understanding (but I could be wrong) is that this behavior wouldn't be compliant with the PKCS7 padding scheme.

[plvie]

Ah yes, I see what you mean. I may not have expressed myself clearly, this wasn’t part of the base implementation, but rather a separate mode. I’ll open a pull request so you can take a look. It’s indeed a distinct feature.