Release - Open source software - replacing hardware wallets with image {

[NyeFe]

how do i decrypt an image i suspect to contain keys?

Okay, if you suspect an image contains a wallet, place the image into the app, then enter the password to decrypt the AES data.

It uses a mixture of cryptography (encrypting) and steganography (hiding). So if you suspect something, you now have to know the password to see if you'll get anywhere.

I guess my aim is to move the target from just wallet.dat files to everything such as: pictures, audio files, movies, videos! anything could contain a private key.

[Michael_S]

Very nice indeed. this sw should be standard since years. I am surprised it comes so late and highly welcome it!

A few questions:

• Q.1: does the sw detect that the image contains a bitcoin key when entering the correct password even offline (e.g. by some header info or checksum after correct password entering), or is every image-password-combination a valid key? --> the latter would be better because:

• it would make the image even more difficult to brute-force! (you'd have to check with the blockchain each time you try a new password)
• it would provide powerful means against the "$5-wrench-attack": you can store two (or more) keys in one image via two (or more) different passwords and load different amounts on it. should you ever get attacked with a "$5-wrench", you give away your dummy key with a small amount of btc and plausibly deny existence of another key.

• Q.2: I understand that the privkey is stored in the 1 or 2 LSBs of each pixel's 8-bit RGB values, probably after XOR-ing with "sha1(password)"-bit-sequence or sth. like that. But this means that a *.png image would increase in size, compared to the original image, if the original *.png image contains sequences of pixels of identical colours, due to *.png's lossless compression (run lenght encoding). So the original image should preferably be an image that already contains some "noise" on the LSBs, do I understand correctly?
• Q.3: Does the SW support only individual keys or also HD keys with 12-to-24-word mnemonics acc to BIP32/39/44?

[NyeFe]

Very nice indeed. this sw should be standard since years. I am surprised it comes so late and highly welcome it!

A few questions:

• Q.1: does the sw detect that the image contains a bitcoin key when entering the correct password even offline (e.g. by some header info or checksum after correct password entering), or is every image-password-combination a valid key? --> the latter would be better because:

• it would make the image even more difficult to brute-force! (you'd have to check with the blockchain each time you try a new password)
• it would provide powerful means against the "$5-wrench-attack": you can store two (or more) keys in one image via two (or more) different passwords and load different amounts on it. should you ever get attacked with a "$5-wrench", you give away your dummy key with a small amount of btc and plausibly deny existence of another key.

• Q.2: I understand that the privkey is stored in the 1 or 2 LSBs of each pixel's 8-bit RGB values, probably after XOR-ing with "sha1(password)"-bit-sequence or sth. like that. But this means that a *.png image would increase in size, compared to the original image, if the original *.png image contains sequences of pixels of identical colours, due to *.png's lossless compression (run lenght encoding). So the original image should preferably be an image that already contains some "noise" on the LSBs, do I understand correctly?
• Q.3: Does the SW support only individual keys or also HD keys with 12-to-24-word mnemonics acc to BIP32/39/44?

Great questions

A.1 the software relies on decryption errors. At the moment it should break or throw an error if the AES library can't decrypt the data. It doesn't stored bitcoin keys, it stores AES encrypted data, which happens to contain bitcoin keys. you can read more about this steganography library on this PDF

A.2 The output PNG image should be less than the original. I have an original PNG image which is 14.8MB and an output which is 9.36MB

A.3 At the moment the SW only supports individual keys since this is the first-iteration / release of it. You can make request by following the below quote

You can make appeals to modify, upgrade, or add any functionality on this thread As long as you have any research which proofs your upgrade/addition is superior/adequate

[Michael_S]

In fact, *every* steganographic method can be broken with currently available stegoanalitic methods(which are typically statistical methods).  The only question is whether there is enough data, but practical amounts are sufficient (no astronomical figures like in crypto).

I think it depends how you do it.

Imagine you have your "original" image that you want to modify to include your key via steganography. If your original image satisfies certain characteristics, I am sure you couldn't tell if the post-processed image contains steganography or not.

Here is how I construct my "original" image:

* take a camera picture.

* add noise on it and save as *.png (lossless format)

The noise addition follows this algorithm: For each pixel take each original 8bit rgb value and replace the LSB (rightmost least significant bit) by a random 0/1.

And here's how I hide my 256 bit bitcoin private key (pk)  inside this image:

* calculate y = "pk" XOR "sha256(myPassword)"

where XOR is a bit-wise operation of 256 bits.

y is a 256 bit sequence that looks absolutely random, also from statistical analysis point of view.

* I replace the first 256 "noise LSBs" of the image by "y".

Done!

[Michael_S]

Very nice indeed. this sw should be standard since years. I am surprised it comes so late and highly welcome it!

A few questions:

• Q.1: does the sw detect that the image contains a bitcoin key when entering the correct password even offline (e.g. by some header info or checksum after correct password entering), or is every image-password-combination a valid key? --> the latter would be better because:

• it would make the image even more difficult to brute-force! (you'd have to check with the blockchain each time you try a new password)
• it would provide powerful means against the "$5-wrench-attack": you can store two (or more) keys in one image via two (or more) different passwords and load different amounts on it. should you ever get attacked with a "$5-wrench", you give away your dummy key with a small amount of btc and plausibly deny existence of another key.

• Q.2: I understand that the privkey is stored in the 1 or 2 LSBs of each pixel's 8-bit RGB values, probably after XOR-ing with "sha1(password)"-bit-sequence or sth. like that. But this means that a *.png image would increase in size, compared to the original image, if the original *.png image contains sequences of pixels of identical colours, due to *.png's lossless compression (run lenght encoding). So the original image should preferably be an image that already contains some "noise" on the LSBs, do I understand correctly?
• Q.3: Does the SW support only individual keys or also HD keys with 12-to-24-word mnemonics acc to BIP32/39/44?

Great questions

A.1 the software relies on decryption errors. At the moment it should break or throw an error if the AES library can't decrypt the data. It doesn't stored bitcoin keys, it stores AES encrypted data, which happens to contain bitcoin keys. you can read more about this steganography library on this PDF

A.2 The output PNG image should be less than the original. I have an original PNG image which is 14.8MB and an output which is 9.36MB

A.3 At the moment the SW only supports individual keys since this is the first-iteration / release of it. You can make request by following the below quote

You can make appeals to modify, upgrade, or add any functionality on this thread As long as you have any research which proofs your upgrade/addition is superior/adequate

So A1 reads: No, not every image-password combination is a priv key, and you can tell from wrong password that the password is wrong without checking the blockchain.

About A2: This is strange. How can it happen? And does it also happen if the original image is a computer screen shot that typically contains many successive pixels of identical colour?

[NyeFe]

Very nice indeed. this sw should be standard since years. I am surprised it comes so late and highly welcome it!

A few questions:

• Q.1: does the sw detect that the image contains a bitcoin key when entering the correct password even offline (e.g. by some header info or checksum after correct password entering), or is every image-password-combination a valid key? --> the latter would be better because:

• it would make the image even more difficult to brute-force! (you'd have to check with the blockchain each time you try a new password)
• it would provide powerful means against the "$5-wrench-attack": you can store two (or more) keys in one image via two (or more) different passwords and load different amounts on it. should you ever get attacked with a "$5-wrench", you give away your dummy key with a small amount of btc and plausibly deny existence of another key.

• Q.2: I understand that the privkey is stored in the 1 or 2 LSBs of each pixel's 8-bit RGB values, probably after XOR-ing with "sha1(password)"-bit-sequence or sth. like that. But this means that a *.png image would increase in size, compared to the original image, if the original *.png image contains sequences of pixels of identical colours, due to *.png's lossless compression (run lenght encoding). So the original image should preferably be an image that already contains some "noise" on the LSBs, do I understand correctly?
• Q.3: Does the SW support only individual keys or also HD keys with 12-to-24-word mnemonics acc to BIP32/39/44?

Great questions

A.1 the software relies on decryption errors. At the moment it should break or throw an error if the AES library can't decrypt the data. It doesn't stored bitcoin keys, it stores AES encrypted data, which happens to contain bitcoin keys. you can read more about this steganography library on this PDF

A.2 The output PNG image should be less than the original. I have an original PNG image which is 14.8MB and an output which is 9.36MB

A.3 At the moment the SW only supports individual keys since this is the first-iteration / release of it. You can make request by following the below quote

You can make appeals to modify, upgrade, or add any functionality on this thread As long as you have any research which proofs your upgrade/addition is superior/adequate

So A1 reads: No, not every image-password combination is a priv key, and you can tell from wrong password that the password is wrong without checking the blockchain.

About A2: This is strange. How can it happen? And does it also happen if the original image is a computer screen shot that typically contains many successive pixels of identical colour?

I'm still shocked myself. I truly wasn't expecting PNG output files which were less than the original. All the images I've been using have been computer screen shots, except for the flower one, which i got from google. It's output was also less than the original.

[pereira4]

I am not an expect in steganography but from common sense I am amusing that there is a way bigger risk that if you print it and save it physically like a paper wallet, it's way easier for the key to corrupt and not be able to read it back because of way too many colors and stuff on the game. Like the image can deteriorate physically (from the paper rotting over time and so on) and then the device trying to scan it will have a hard time guessing the key.

On the contrary with a classic normal QR code it's way simpler there fore easier for the device to scan it.

[Michael_S]

I am not an expect in steganography but from common sense I am amusing that there is a way bigger risk that if you print it and save it physically like a paper wallet, it's way easier for the key to corrupt and not be able to read it back because of way too many colors and stuff on the game. Like the image can deteriorate physically (from the paper rotting over time and so on) and then the device trying to scan it will have a hard time guessing the key.

On the contrary with a classic normal QR code it's way simpler there fore easier for the device to scan it.

you are not meant to print and rescan the image with the method of this thread. This won't work.

[NyeFe]

I am not an expect in steganography but from common sense I am amusing that there is a way bigger risk that if you print it and save it physically like a paper wallet, it's way easier for the key to corrupt and not be able to read it back because of way too many colors and stuff on the game. Like the image can deteriorate physically (from the paper rotting over time and so on) and then the device trying to scan it will have a hard time guessing the key.

On the contrary with a classic normal QR code it's way simpler there fore easier for the device to scan it.

you are not meant to print and rescan the image with the method of this thread. This won't work.

I'm scared that people would actually print this out and actually expect to get a private key from the scanned printout. If you print it out and delete the output copy on your computer, you're pretty much screwed. It's not mean't to be printed out, please use something like QR instead.

[gmaxwell]

This kind of steganography-- hiding data in the least significant bits of images-- is _very_ easily detected by statistical methods, and there are many papers and tools (stegdetect, for jpeg as an example) to do so.

At a minimum, something hoping to perform successful image steg embedding should be using wet paper codes.

[Kprawn]

I think the best method to combine with this is to add 10 000 images for example and only you know which 1 contains your private keys. Someone would have to work through all that images to try to

isolate which one you used to store the private keys. The general public will pick up a memory stick, and they would store images on it, and nobody would ever suspect that it contains a single image

with 1000's of bitcoins stored on a Bitcoin address hidden in one of theose images.  

[NyeFe]

This kind of steganography-- hiding data in the least significant bits of images-- is _very_ easily detected by statistical methods, and there are many papers and tools (stegdetect, for jpeg as an example) to do so.

At a minimum, something hoping to perform successful image steg embedding should be using wet paper codes.

For one thing, I'm really happy to get your input about this implementation! Perhaps I'll try out the wet paper codes within the first packaged released of this project.

[soyab0007]

This is truly amazing

[Michael_S]

This kind of steganography-- hiding data in the least significant bits of images-- is _very_ easily detected by statistical methods, and there are many papers and tools (stegdetect, for jpeg as an example) to do so.

post #25's method should be safe.

[Velkro]

Thats some pretty untested software, that could mess up o make unrecoverable private keys.
:| first testing, then crazy ideas like that

[btchip]

It'd be nice to update the title as this has nothing to do with hardware wallets - the main purpose of a hardware wallet is to run the cryptographic code on dedicated hardware so that a malware will not steal your coins.

[TippingPoint]

Many people do not realize that Romana Machado wrote a very early Steganography program (possibly the first one).  She was an Extropian associate of Nick Szabo.

from 1994:
=========================

List:       cypherpunks
Subject:    Party with the Nextropians! at Nexus-Lite!
From:       plaz () netcom ! com (Geoff Dale)
Date:       1994-02-26 21:40:48
[Download message RAW]

         MEET THE NEXTROPIANS: WE ARE HERE AND NOW AMONG YOU
__________________________________________________________________________
Romana Machado - Geoff Dale - David Gordon - Nick Szabo - Russell Whitaker

=========================

And another Extropian was Hal Finney, the first recipient of Bitcoin.

[dserrano5]

I think the best method to combine with this is to add 10 000 images for example and only you know which 1 contains your private keys.

…while the others contain random garbage steghidden. Otherwise as a couple of chaps already said, the only one hiding information will stand out.

An additional twist is N images/audios/videos containing an M-of-N secret sharing scheme.

[noobtrader]

wow this is great project   

[gadman2]

I'm actually super interested in learning more about this. Awesome stuff.