Topic: WalletCrypt Encryption Explaination (Read 1374 times)

You don't have to worry about the script kiddies. You have to worry about the one or two competent people out there who will write a tool for the script kiddies to use.

It is so easy to do encryption right (for this type of problem), there is simply no excuse for doing it wrong. It is, in fact, more work to do it wrong then right. The bitcoin client already links with OpenSSL, which includes well-tested implementations of the most reliable encryption algorithms. The other problem is that people know that it is so easy to do this right they will assume they can rely on it.

Point made Rogue star, And yes it is exactly that "Obscurity" of the bitcoin wallet using a "key" as the sequence of encryption/decryption. You are right in same cases it could be 1000's of bitcoins in a given wallet, I just thought it would give windows user a little protection compared to giving non which is how it is at the momment. like I said before the common internet juvinial thief probably has no idea how to even start the decryption process for a basic xor encryption. But if encryption will be included with the bitcoin client soon them I guess this project is useless for public use. I will keep it for personal use, atleast I know there is some encryption on my wallet which in my eyes is better than non(I personally dont think its crackable). I will ofcause release the source anyway, then leave it upto them to compile and use if they wanted...

Thanks for the comments and insight... I dont blame the community for being paranoid, I lost a fair amount of coins myself on the mybitcoin issue. I feel its like offering the community a free 6 shooter pistol, for a small means of protection, but the community turns it down asking for a rocket launcher.....

I know it can be fun to roll your own encryption, but just don't do it. There are just so many attacks possible that regular folk like you or I just don't understand. Until the algorithm AND the implementation have been seriously vetted, it's really just security through obscurity. I'm not sure many around here could take a serious stab at vetting crypto. Do not take comfort in obscurity either as it is rarely obscure enough to be secure. If you are okay with taking risks, that's fine for personal use, but please do not distribute whatever you are planning. You would be doing a great disservice to release something you rolled out yourself, there's a reason the Bitcoin devs are taking their time with the wallet encryption that didn't make it into the last release (0.3.24)

Let me put it as simply as possible: DO NOT DO IT YOUR OWN WAY. Do it a way that has been designed and tested by experts and is known to be secure. Anyone, even experts, can design a mechanism that seems secure to them that is in fact horrifically insecure.

There are no shortage of simple ways to do this that are known to be secure. For example, using PBKDF2 to produce the key, AES-256 as the algorithm, HMAC-SHA1 to detect tampering, PKCS7 padding to handle wallets that aren't a multiple of the block size, CBC as the block chaining mode, and so on are all known to be safe. They may not be optimal, but they are safe unless misused.

I think there is some confusion, they type of encryption really has nothing to do with scrambling the wallet.dat, if the key used to scramble the file is unknown and is of decent length(reduce brute-forcing attempts) It should be near on impossible to decrypt(unscramble it to its original condition). So the encryption library used is irrelevant in this case to certain degree. the original RC4 I was using was used in such away to scramble a string not a stream. Hence even the most basic of xor encryption would be enough to scramble a file with a decent length key that it would take an extremely long time to de-scramble it back to its original condition. Even when the Decryption method is know(open source) the password still needs to be known, hence brute-forcing methods until the original hash matches the brute forced decrypted files hash. it would take a lot longer to brute force a wallet due to its size than to simply brute force a password. I might be missing something here that I haven't considered. But I am willing to post a challenge by releasing a wallet containing 5btc and has been scrambled, first one to "descramble" the file can use the wallet to claim there 5btc reward. Im pretty confident that it wont get descrambled in a reasonable amount of time. I will even supply the MD5 hash of the original file to help along the way

Are you kidding? You're really going to pass up established, reasonably secure algorithms for something you rolled yourself with known insecure algorithms? This is what Bruce Schneier calls snake oil. And this is why I thought you weren't serious.

Building an app that uses crypto securely is HARD. I urge you not to move forward with this until you actually have a reasonably secure design and some idea of what you're doing.

Thank you for the artical about RC4, it was interesting to read. It has kinda made me re-think the way this program should be done. Only issue I am having is the non coding challenge when using a library, meaning that the projects becomes uninteresting due to passing paramters to an already knowen library, No real coding skill is require to pass these parameters as the Crypto library is basicall doing all the work. Saying that, using such library would probably be better for the end user because as you stated, it has already been reviewed and tested by the pro's. If this project is to become very secure it will need to be using knowen librarys. The goal was to keep it basic to "scamble" the wallet just for that extra bit of security(incase it ever did get stolen). Really the best security is bitcoin client it self including some sort of encryption/decryption on the fly, this way the wallet isn't at risk even when its being used. I might even take a look RC6 implemetation just for basic use. and include the knowen librarys as an option with in the program(in other words have multiple options of algo's that can be used). I still will be using my Original idea of storing the decrypted hash at the begining of the encrypted wallet for integrity checking, But will look at the actual encryption of wallet some more and give people more choices in the way they encrypt there wallet. Just a thought.. if people actually use this program it would need to be very basic and simple, for we can assume the user has limited knowledge about diffrent algo's(otherwise they would have already encrypted it them selfs). Meaning that throwing out a heap of options on encryption types might create a very un-friendly application. Being windows users I would think they would want a 1 click solution to encrypt there wallet and restore there wallet....

Thanks for answering my questions.


Yes, MD5 collisions are rare and I believe MD5 is still usable for key derivation. I just feel uncomfortable depending on such a weakened hash when we have plenty of better alternatives.


I think SHA-256 would be preferred, although SHA1 is reasonable.


Improper use of RC4 made WEP Wi-Fi encryption trivial to break. RC4 has a few weaknesses you have to watch for, which I will explain further down. They are documented here:
http://aboba.drizzlehosting.com/IEEE/rc4_ksaproc.pdf
http://en.wikipedia.org/wiki/Fluhrer,_Mantin_and_Shamir_attack


As described in the paper above, the initial bytes produced in RC4's keystream can leak information about the key. The first bytes in the keystream should be dropped prior to encryption. This is just one of the little things that makes RC4 difficult to implement securely.


Implementing encryption securely is very hard. You have to worry about the weird nuances of the algorithms and various side-channel attacks. I don't really trust an implementation unless it has been widely used, tested, and reviewed by many professionals. Even prominant open-source implementations created by experts sometimes turn out to have issues. I'd recommend using a library like OpenSSL. It has been highly scrutenized and it will handle many of the little issues for you.

The one question you didn't answer is the nonce question. RC4 is a stream cipher and should never be used to encrypt two different things with the same key unless you use a unique nonce or IV which is combined with the key prior to encryption. This is yet another thing that a crypto library could help with.

I dont mind you at all asking questions

Viginere string encryption has been used since the 18th centry it is basically a caesar encryption but a lot more secure, I wrote my own implementation in the Delphi language and was featured on a large Delphi web site called about.delphi.com, The reason for "Custom" algo is to reduce the risk of cracking, Most "crackers" are very fimilar with the common knowen algo's and they them self have created tools which can crack these algo's, So to me using common everyday algo's makes it more of chance to get cracked rather than a custom algo, which mearly a combination of algo's put together. For number 2 question... It is very possiable to use multiple iterations and substitutions to streach the key length(reducing the chance of repeated key being generated),Like I stated in first post I have only just started this project for public use and at the momment relys on Vigenere encryption to prevent collisions, which in real life is not even issue considering the chances of a MD5 collision(very rare), It also has the option of SHA1 incase people are aware of the MD5 collision issues, It can also use Both to create a hash of the file which would really stretch out the hash and key length. We could also implement any variations of SHA if people wanted including the most common SHA256 thats used in the bitcoin community. I have never read anything about RC4 being difficult to use securely. After all it only encryption a string(Wallet.dat coverted to string and then encrypted) once the string is created it is then appended to the created file. The begining of that created file is like a header which will contain information like the custom hash of the decrypted wallet(original wallet.dat). for you last 2 questions I think that is explained in the above explaination, no bytes are dropped from the RC4 stream(or maybe I have mistake your question regarding this)?  Ohh and the RC$ implemetation I am using is from friend who converted it from C++ and to include the changes to encrypt as a string and not a stream. Its a very simple implementation and can be found on my blog or I can post it here if you wanted to see it.

I hope this kinda helps with your questions, this project is on going and can be changed to suit the requirements, suggestions and ideas of people interested in using it. For those who dont want to use such a program its all good, and no harm done. I just thought to share something that I use to help prevent theifs stealing my coins if the wallet ever got stolen, Using it or not is upto you guys its no big deal for me.


//Edit
Btw you do have a good point, Why use custom algo's when the source code will be fully public thus making custom algo pointless. Simple awnser is that I guess not all the theifs will have the source code to under stand that it is encrypted with WalletCrypt, and secondly being a theif as a internet trade means his reverse engineering skills if any will be limited, thus making it harder for him to debug and understand the custom algo(without the sourcecode). Saying that, this does not mean having the sourcecode will decrpyt the wallet you still need to know the password phrase. the hashing like I said is to confirm the integrity of decrypted wallet, to make sure it is in its original condition, Which also makes MD5 collision not a problem as its irrelivant for the way we are using the MD5.

I hope you don't mind me asking a few questions.

Why use untested custom crypto when more established algorithms work just fine?
If you hash the passphrase, do you use multiple iterations or some other form of key stretching?
Why use MD5 when it has known collisions? Why not use SHA2?
Why RC4, which is notoriously difficult to use securely? Why not AES?
What implementation of RC4 are you using? Did you write it yourself? Is it from a library like OpenSSL or Crypto++?
Are you using a nonce to prevent the same key from being reused? If so, how is the nonce combined with the key?
How many initial bytes do you drop from the RC4 stream?

No not yet I have only just started this project. before that I was just using simple RC4 encryption to encrypt my wallet, but now I was intending to make this public I wanted to add more options. I am very interested how winrar recovers corrupted data, It will be something to look into on how they do it, and just maybe use something similar.

Do you have a plan to recover a corrupted  wallet that has been encrypted using this method?

K so the mods locked my topic which I was intending to update and reply to the questions asked about MD5 and SHA, Let me explain how this works in more detail...

First a file is created and then MD5 or SHA1 hash is generated on the original wallet.dat the hash in plain ascii is written to the begining of the new file(32 bytes for MD5 or 40 bytes for SHA1) this is so when decrypting the wallet you can confim its not corupted and the Decrypted wallet hash should match the hash that was written to the begiining of the encrypted file. The encryption proces is simply taking the wallet.dat and making it into an array of chars which is then encrypted by RC4 with password phrase, This password phrase can be modifyed using a custom Vigenere string encryption algo I have written for extra security, and should stop bruteforcing on common english dictionary words. It then also has an option NTCompress the results before writing it to the created file(there will be a knowen byte written after the hash in the begining of the file to indicate of it has been compressed or not) with hash already written to it. So to anwser your question about the MD5/SHA it is used to verify no data corruption has accured during decryption. And as someone else stated it can also be used as "key" in RC4 encryption by hashing your password pharse, This will in effect help stop bruteforcing of common words by a dictionarary attack, also the MD5 hash is 32 chars longwhen converted to ascii, and the SHA1 is 40 chars long when converted, so bruteforcing this would be nearly impossiable.

Also please dont judge someone who hasn't even released a binarary, I was mearly creating a topic so I can add updates and release to, Also get ideas and suggestion on what other members would like to have included.


//Edit

Also note that full source code will be released with the project, You can also check my personal blog to verify that I do actually create open source projects dealing with encryption and decryption, I haven't updated it in a few years but its there never less. http://www.cheesydoodle.com