Quote from: Michael_S on July 23, 2016, 06:19:01 PM

Quote from: NyeFe on July 23, 2016, 06:04:33 PM

Quote from: Michael_S on July 23, 2016, 05: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:

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.