0
$\begingroup$

I've been delving into cryptography for fun and trying to implement a visualization for AES using image encryption. So far, represented each pixel's RGB values as hexadecimal numbers, then split it into an array of 16 character strings. I know that AES is a block cipher, so I have to split them into 16 character strings, but how am I supposed to handle when the string becomes less than 16 characters? I've heard that I should just pad it and add more characters to fit it into 16 characters, but I'm not sure if that's correct, since the padded characters won't be represented in the final image, and be able to be decrypted.

$\endgroup$
2
$\begingroup$

CAUTIONARY NOTE: Beware that the vast majority of countless articles that discuss "image encryption" using computers (rather than using essentially optical means) are junk science. I don't know any article with "image encryption" and "AES" in the title (as the question does) that's worth studying (I welcome a link in comment if I missed one).

Encrypting digitized images (rather than other kinds of digital data) using AES requires no special crypto or preprocessing. As for other kinds of digital data, compression (if used) must be applied before encryption, and decompression after decryption; and then one should examine the consequences of the fact that crypto does not hide the length of what's encrypted.


There's no good reason that the plaintext (what's encrypted) go thru hexadecimal (a system of representation where 4 bits are encoded into a character): this would typically double the size compared to using the raw bytes. Hexadecimal is a way for eyes to see raw bytes, or express the ciphertext (result of encryption) as text (even though there are better encodings for that), but it should not be part of how the plaintext is transformed for encryption.

Learn about AES-CTR (or AES-OFB, even though it's not nearly as common), which let you encrypt data without bothering forming 16-byte blocks (these two modes avoid the need for padding; on the other hand that would be necessary for ECB, a mode of operation notorious for being bad, especially for highly redundant plaintext including uncompressed images).

Then learn about authenticated encryption, which is the modern way to protect data confidentiality and integrity using a symmetric key. Examples of that include AES-GCM(-SIV).

$\endgroup$
3
  • $\begingroup$ I agree that these are superior and secure forms of encryption. However, given OP's comment that they were learning for fun and wanted a visualisation for AES using image encryption and the encoding scheme used, I thought that they might be trying to demonstrate the limitations of ECB. $\endgroup$
    – Daniel S
    Mar 18 at 8:17
  • 3
    $\begingroup$ @DanielShiu: that would be fine. But google for articles on AES image encryption and you'll see that the conjunction of these three words typically is indicative of the worst. $\endgroup$
    – fgrieu
    Mar 18 at 8:22
  • $\begingroup$ Thank you for the suggestion! I will check out AES-CTR, but to clarify I was just trying to recreate how they did this filter in Lunapic. I'm not super serious about protecting data, just trying to learn encryption. $\endgroup$ Mar 20 at 14:47
0
$\begingroup$

Your padding scheme should come with a means to identify what parts of the message are padding and then remove them. One possible scheme is if the last block is 1-15 bytes long, pad out all but the last byte with zeros and then write the length into the last byte, but if the last block is 16 bytes add another block of all zeros.

Upon decrypting, put in an extra "remove padding step" that reads the last byte as a number $n\in 0,\ldots,15$ and then discard the last $16-n$ bytes.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.