Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote -3 down vote favorite

I have encrypted an image using pixel encryption method. I just used a bmp image for that. What I did is, I retrieved each pixel value from the image and obtained the value of red, green and blue value individually and XOR-ed it with a pseudo random value. For pseudo random number generation I used the SecureRandom with the SHA1PRNG algorithm. The seed value set for generating the random numbers is obtained from the password that we give.

Detailed description of the code and the ouput is available in zone4java

My question is how long will it take to any utility, if available, to decrypt the image without knowing the password? Is this kind of encryption methods secure?

Note: If my question is being downvoted, please comment the reason.

share|improve this question
1  
Regardless of how good you think your homemade scheme is, don't roll your own crypto. Why are you encrypting each pixel individually rather than encrypting the entire image as a byte stream? Do you have a good reason for doing so? – Terry Chia Mar 17 at 7:09
@TerryChia If i encrypt the file, the image viewing application may not be able to read it as image file. And also as futher part i can create shares of this image and it goes. – Maximin Mar 17 at 7:19
3  
Why would you go out of your way to allow image viewers to be able to display it? – Stephen Touset Mar 17 at 7:21
Very tempted to close as not a real question. This isn't about whether you encrypt per pixel or using more common methods. From a security perspective it is about the algorithm, and the choice of password. The rest here is irrelevant. – Rory Alsop♦ Mar 17 at 7:33
@StephenTouset I wanted the output of my encryption a image file itself. So that i can work on that, like making image shares and hiding data etc. – Maximin Mar 17 at 7:50
show 2 more comments

2 Answers

up vote 1 down vote accepted

Encrypting the pixels in a bitmap by xor-ing with the output of a stream cipher is okay in principle, but there are a number of caveats:

  1. You don't encrypt the size of the image, or any meta-data.

  2. Like with all stream-ciphers you must never reuse a key (or key-nonce pair). In your case this means you must never reuse a seed.

    Else you get a many-time-pad, which sucks. So you need some way to include a nonce.

  3. SHA1PRNG isn't the best choice for a stream cipher. The biggest problem is that the implementation might change between different versions. I believe this happened on android, breaking some applications.

    You should use an designated stream cipher, like AES in CTR mode, not a PRNG.

  4. Since you're using password based encryption, you need a proper password based KDF, such as PBKDF2 with sufficient iterations and a salt. I recommend using a random 16 byte salt.

    Using a unique salts here leads to unique keys for the cipher, so you don't need the nonce I mentioned in step 2 anymore. Effectively the salt is the nonce.

share|improve this answer
up vote 3 down vote

The first image is of Tux, the Linux mascot. The second image is of Tux, encrypted in ECB mode (more or less what you're attempting). The third is of Tux, encrypted in CBC mode. The problem with the second approach as well as your own is that identical pixel values encrypt to the same value in ciphertext. So even though the color of each pixel is protected, the underlying pattern is easily visible.

Do yourself a favor, and don't roll your own crypto. Use something well-established like AES in CBC mode, or (ideally) GCM mode. And encrypt the entire byte stream in one go, rather than trying to be clever and encrypt pixel by pixel.

share|improve this answer
I have provided a link in the question where you can see the code and output for the asked method of encryption. When i encrypt the image, I will get the encrypted image similar to that of the third image. Sorry, please go through every detail. Thank you – Maximin Mar 17 at 6:55
1  
From your code, you're using a simple password to encrypt. This is going to be orders of magnitude easier to brute-force than a proper key. There is no initialization vector, so any re-use of a password will create an identical keystream. Encrypting each color value separately is pointless and just triples the already-poor running time for the algorithm. Again: don't roll your own crypto. Use something well-established that's been peer-reviewed. There is zero reason to believe that any algorithm, particularly a homegrown one, is secure until it has been analyzed by professional cryptographers. – Stephen Touset Mar 17 at 7:11
3  
openssl enc -aes-128-gcm -in /path/to/image -out /path/to/encrypted_image is shorter, simpler, faster, more secure, uses a strong KDF to prevent brute-forcing the password, doesn't replay to an identical ciphertext, and works for any image format (and any other type of file for that matter). The wheel need not be reinvented, poorly. – Stephen Touset Mar 17 at 7:19
Ofcourse the password will create the identical stream, that is used to decrypt the image. I am not saying this method is the best. All I want to know is how far is this secure. In openssl enc how it is going to decypt the image? – Maximin Mar 17 at 7:28
@Maximin A- Not secure. B- You can decrypt simply by doing openssl enc -d -aes-128-gcm -in /path/to/encrypted_image – Adnan Mar 17 at 8:50
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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