@OP, how does it check for spam posts exactly? Long paragraphs may not always be constructive and short sentences are sometimes the best replies. Please tell me it's not based on a word/character count (because that's super easily abused [YoBit, Bitmixer, etc])
I'd also be interested in seeing something against copy/pasting - searching through the thread for plagiarism.
Sorry that i didn't post on this thread. This project is dead & open-sourced. I didn't have time to deal with the encoding problems so dumped everything on Github. If you want to use it (its pretty much done) you'll have to finish the coding for the extension, and the java application servers. If you're looking to use this product, I really don't think I'll have any interest in restarting it & to bring the project/product to life. Not to talk about the cost of hosting the server, and time needed to finish/test every single function. |
|
|
|
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. |
|
|
|
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 PDFA.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. |
|
|
|
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 PDFA.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 |
|
|
|
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. |
|
|
|
Excellent work! I haven't tried it yet but have a question:
You can load any image and your software detects if there's stenography? Or is it based on let's say a password, then that password applies stenography techniques to pic?
What I'm getting at is can your code be modified and go through every pic on a computer and detect pics that have a wallet on them?
Great question, the software itself (or myself for that matter) don't even know how to detect which image contains steganography data. its all based on the password, if the data decryption process fails, then thats it. Its either you know the password, know it has someone in it, or you don't. I downloaded the file but is there anyway to make it a simple exe or installer? im not too sure how to install it at the moment but would like to give it a try.
Edit:- also a phone version would be nice in the future where i could just select an image within my phone and then decrypt it and put the bitcoins straight into my wallet for instance mycelium.
> I could introduce a package installer later. but it's pretty easy to install. Just download java, unzip the app & run it. > A phone version would be great at least when we've added all the features that we didn't get to. It would also make it much more easy to use "on the fly" |
|
|
|
This is fantastic. The fact that im not using paper wallets it's because they are an obvious target. If someone ever finds it it's like "hey guys, there's bitcoins here! let's pick this up". If they see some irrelevant picture of a cat or something, they will never guess there's a private key there.
The question is: Can you still add a password lip BIP38 paper wallets? There's no way im getting a paper wallet of any kind unless it requests a password to unlock it.
Great question! At the moment, the passwords are converted to SHA1, divided by 2 and encrypted in AES 128-bit 2-times (because we can). It only exports as .JSON file, which is what electrum and blockchain.info uses. An option to export it as an encrypted BIP38 might be added. I'm pretty much brain-dead from working on this project. BUT! I'm excited we've managed to produce a game-changing technology for the community! |
|
|
|
Can i ask if i send a photo that has the wallet encrypted from say my pc to my phone then through various other devices will it still decrypt fine or will the picture quality degrade slightly and become unusable? For instance if i send via whatsapp then it might resize the photo or compress it then i guess it will no longer work?
It all depends on how each software handles the images. Some websites purposefully degrade images to save disk-space. I don't think you'll have any problems. But if you do need validation, you can install apps such as HashStamp, then compare the image checksum to confirm that no changes has been made. I know 7zip allows you (on windows, with right-click) to check the "CRC SHA" checksum for files. tl;dr: make sure the checksum values are verified each time you transmit the image file. |
|
|
|
This is all in all pretty amazing. So i can now store my bitcoins in a paper picture? Or does it have to be digital only? Either way this opens up some major possibilities for stashing away those coins in hard to find places. I might have to give this a whirl with a small amount just to see how it works exactly.
It is great. The image has to be in a digital format. But please don't forget your password or the image you used! We're looking at storing bitcoin wallets in audio files next, hopefully more options for stashing away bitcoin wallets will be out there |
|
|
|
So how do I decrypt the successive image that is encrypted?
Isn't this one hell of a work to encrypt an image and decrypt it summarily?
And is there any way a user can steal the private key through the image's metadata? Or does it strip all the metadata before encryption?
The software provides facilities to encrypt & decrypt your encrypted private key from the image. The encrypted data are not store as meta data, they are converted to 1's and 0's and added to the RGB data (colour) inside each pixel in an image ( Steganography). So in short, it increases the colour intensity, or reduces it (which is a form of storage) that can be used to store data. The best thing is, the image size should be absolutely the same! |
|
|
|
Official SSI Standard Thread | SSI #1 on RedditAbout
This standards uses two cryptography techniques. The first one, AES encryption 128-bits X2, 32 character hash (which locks your data), and finally Steganography (which hides your data).
In this protocol, wallets are created offline, encrypted, and stored within the pixels of an image as RGB data. This makes it impossible to know whether there's any encrypted bitcoin wallet on your computer, since they can now be storing using colours, in images.
Project Bitcoin talkProject GitHub
Project Download[Figure 1.0] - offline wallet generation & storage  Support us: By specifying useful, researched protocols, and open-source software implementations. Example
For anyone looking for an example, you can download one here http://imgur.com/gallery/lgTwF
One contains no data, the other contains a wallet with 100 keys. The password to unlock the encrypted flower is: flowerOriginal image  flower image with a wallet, storing 100 keys  The size of the stored data is 4.22kb. The size of the original file is 1.61MB. The size of the encrypted file is 0.99MB
|
|
|
|
|
We've released the first secure bitcoin storage software, which follows this specification.
As part of the specification, the tool will generate addresses offline, create wallets, encrypt wallets, and hide these data inside pixels within any image. this makes bitcoin wallets & address untraceable on your computer (as part of the specification)
|
|
|
|
Check into https://cryptoconsortium.org/standards/CCSS, while it's more focused on security, they've done quite a bit of work on it. You might want to join their group or offer help to bring it more into the community. There are other standards communities, so it would be interesting to see where you're looking for focus like security or development? Hi cloverme, They have done quit a lot of work bringing in and establishing standards, which is wonderful. Our focus is mainly within open-source development of cross-platform, offline or networked, security software for established or new standards. Unfortunately not many cryptocurrency standard providers, provide open-source software for each standard, where its necessary. |
|
|
|
We'll be developing and releasing sets of standards for doing things within the cryptoworld. We all know how important it is to have standards. And so, it's our goal to help develop open-source cryptocurrency standards for different aspect. This is more important as more people start to adopt bitcoin as a monetary medium.Website - coming soonStandards > Cold Wallet Storage-- -- Cold Wallet Storage cold wallets should be stored using a combination of different cryptography techniques. The usage & combination of 'wireless' hardware devices, is a bonus.[Figure 1.0] - offline wallet generation & storage Software download Notes
> Addresses should be generated offline
> Wallets should be encrypted using AES
> AES result should be stored into the pixels of an Image - Steganography
> Bonus. The image should be transmitted via 'Bluetooth or Wi-Fi' into a hardware device
-- -- How are standards created? Standards are sets of functionalities or activities which have been discussed and freely tested, by the community. They can be proposed by, and created by anyone.
|
|
|
|
I guess everyone has forgotten about block 74638, when somebody following the consensus rules created 184 billion BTC. A hard fork was done in order to undo those transactions.
Everyone including you, it seems. It was a soft fork (which didn't specifically target any particular transaction, it just fixed the overflow bug). So we have a scenario where a bug is fixed & little else happened, and one (etheurem) where the bug probably still exists & a hard fork took place. Whats the value of etheruem, if security is not put first? I'm still wondering what's more important to them - Securing the protocol, or securing funds from/for potential monetary investment sources. |
|
|
|
Bitcoin would hard fork if the encryption protocol was broken tomorrow and everyone's coins ended up in one address. So no, the philosophies aren't the problem. It's the people who manage it. Whether it be 1, 2, 10 or 10 billion people.
?? BTC would not hard-fork if you mistakenly sent $100mill to the wrong address (The GOX funds). ETH is hard-forking because they sent $100mil to the wrong address (The DAO address). There is a big difference in the philosophies. No, ETH did not send 100 mill to the wrong address. That's not the case, and you know it. essentially the problem is that funds ended up in the wrong place. which caused them to hard fork. I really don't see any integrity in etheruem after this, which would never have happened on bitcoins blockchain. Lets take MtGox as an example. |
|
|
|
Does anybody have any clue on services that are stilling missing from the bitcoin ecosystem?
What services would really help you out today?
Most of the new services lately have been for altcoins. perhaps there's nothing new to develop for bitcoin? Perhaps i'm wrong.
You are not wrong mate but unlike altcoins devs that offer bounty for new ideas nobody shown up on the part of bitcoin though i agree that it has great innovations but there is still need for improvement. Thanks for the response ricku I actually didn't know that altcoin devs offered bounty for new ideas. |
|
|
|
|
Interesting. Have you sold any of these, what major features did you implement, and why should anyone use this scripts?
|
|
|
|
|
Does anybody have any clue on services that are stilling missing from the bitcoin ecosystem?
What services would really help you out today?
Most of the new services lately have been for altcoins. perhaps there's nothing new to develop for bitcoin? Perhaps i'm wrong.
|
|
|
|
|
Show Posts
