Hiding a bitcoin private key in an image file with steganography

[Inca]

I was reading about steganography - hiding data in pictures - when i thought it would be fun to write a script which hides a bitcoin private key in a picture file.

The idea is that each pixel in common picture formats has an r, g, b value. It is possible to alter the least significant bit (the bit on the right most side) of these palette values to encode information into the picture which isn't noticeable to the naked eye.

First effort in python: https://github.com/surg0r/steg

I have managed to write an extremely simple library which encodes an image with a private key, and can extract the same private key from the altered image.

What I need to add is some creative thinking to allow encoding of a private key into a lossy image format such as a jpg - some form of redundancy with multiple checksums is probably a reasonable approach.

Once I have the above sorted I will play around with different methods of encoding the data as LSB manipulation is pretty obvious to an attacker or image processing software on the lookout for such a trick. Open to suggestions for some more exotic means of encoding the private key ..

Finally it would be fairly trivial to add two factor with something like bip38 and a passphrase to the image file.

edit: added automatic string length check and a checksum using the last 4 bytes of a sha(256) of the key

edit2: tidied up the library so that it works very simply now..

 

[theZerg]

You could also make the image BE the private key by SHA256ing it. Prepend a password to the file before SHA256 to add 2FA. Like your solution, the problem is that this cannot survive transfer and recovery from an analog medium (i.e. you can't print and then scan it).

You will have difficulty modifying an image without noticeable effect and still have the passkey survive analog transfer. However, you should be able to extract information from an unmodified image and use that + passcode as the input to SHA256 to create a private key.

The kinds of information that survives analog transfer is frequency domain stuff. How fast are the colors changing? Use the average color or intensity in an inch wide swatch along the diagonals (its easy to identify the corners) to make translation of a 2 dimensional image into a single dimension which you can then do a frequency analysis on. You may not get that many bits out though... if you want to get fancy I guess you could do a spiral to make a large strip.

 

[Inca]

Frequency analysis using diagonals sounds interesting!

I suppose I should convert the private key back to 256 bits prior to encoding.

That should get the size down to 32 bytes from 51. Plus checksum (4 bytes, two probably acceptable) and a length byte is in total 35 bytes or 280 bits to secrete. Using r,g, and b values this is just ~94 bits with each to hide. Might still be difficult!

 

[BrianM]

Similarly:

* SHA256(SHA256(your-custom-algorithm(append(your-password, picture-of-moon-near-cloud-with-foreground-branches-with-leaves-blowning-on-windy-day)))

Note the use of one-time, location-specific data, so others can Not possibly take the same picture, even if they stood in the same spot.

So you have: very-unique-picture --> masterKey,

This could be redone anytime you need your key.
* Just don't share or loose the pict, and don't share or forget your password, or any custom algorithm you may choose to include.
* Generate an N of M group of paper keys if you prefer to recover the master key years later, or allow relatives to do so.