This is new to me. I don't know how it works and how is the security protocols are made
This may sounds good but right now I have a long time to study how the encryption is done and its relation to the image.
For now I'll gonna wait for some update. But thanks for opening it up on this forum, its something new and interesting.
Topic: Release - Open source software - replacing hardware wallets with image { (Read 12607 times)
July 23, 2016, 10:54:32 PM
July 23, 2016, 10:39:04 PM
I'm actually super interested in learning more about this. Awesome stuff.
July 23, 2016, 10:11:30 PM
wow this is great project 
July 23, 2016, 07:54:20 PM
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.
July 23, 2016, 07:48:50 PM
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.
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.
July 23, 2016, 07:47:07 PM
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.
July 23, 2016, 07:33:59 PM
Thats some pretty untested software, that could mess up o make unrecoverable private keys.
:| first testing, then crazy ideas like that
:| first testing, then crazy ideas like that
July 23, 2016, 07:07:39 PM
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.
July 23, 2016, 05:42:48 PM
This is truly amazing
July 23, 2016, 04:53:45 PM
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.
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.
July 23, 2016, 04:42:32 PM
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.
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.
July 23, 2016, 04:39:42 PM
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.
At a minimum, something hoping to perform successful image steg embedding should be using wet paper codes.
July 23, 2016, 04:18:38 PM
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.
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.
July 23, 2016, 02:55:14 PM
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.
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.
July 23, 2016, 02:30:21 PM
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.
On the contrary with a classic normal QR code it's way simpler there fore easier for the device to scan it.
July 23, 2016, 02:26:50 PM
Very nice indeed. this sw should be standard since years. I am surprised it comes so late and highly welcome it!
A few questions:
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
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.
July 23, 2016, 02:19:01 PM
Very nice indeed. this sw should be standard since years. I am surprised it comes so late and highly welcome it!
A few questions:
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
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?
July 23, 2016, 02:10:19 PM
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!
July 23, 2016, 02:04:33 PM
Very nice indeed. this sw should be standard since years. I am surprised it comes so late and highly welcome it!
A few questions:
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
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
July 23, 2016, 01:41:46 PM
Very nice indeed. this sw should be standard since years. I am surprised it comes so late and highly welcome it!
A few questions:
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?
Jump to: