bitXOR - A generic file encryption method originally designed for my bitcoin wallet

[CTNieves]

Source code is available on my site : http://www.ctnieves.com/softwareArticle.php?id=11

And here is a quote from there as well explaining how exactly it works :

"bitXOR generates specialized xor pads from a single input file and a provided passkey. Random data is generated and xor-ed with the original input file and then cyclically xor-ed with the pass key. The resulting *.x and *.y files are therefore dependant on one another for the recovery of the original file.

Each output file can then be stored in separate secure locations--which is unnecessary because the original file can not be recovered without the provided passkey.

Each xorpad can be passed through bitXOR an infinite amount of times allowing for as many separate output files as necessary. This tree is referred to as a xorTree and native support will be added at a later time."

I apologize for any mistakes, the software article and this forum post were both created on my phone.

[btchris]

Well, I've got some feedback if you'd care for any...

1. It's not obvious that "encryption" automatically deletes the just-encrypted file.
2. The deletion of the original file is not a secure delete. Because there's no way to inhibit the deletion, the just-encrypted data is guaranteed to still be present on the hard drive.
3. The deletion of the original file fails on Windows (because you don't close the file first).
4. If the "out" file already exists, "encryption" mode is assumed, and file.x and file.y are silently overwritten if they exist.
5. The "key", which additionally "encrypts" the file, is naively implemented and does not add any additional protection. Your statement that the two files can be "stored in separate secure locations--which is unnecessary" is inaccurate; the key feature leads to a false sense of security and should be removed entirely or re-implemented.

Finally, I'm not entirely clear what advantage this scheme has over creating two files using well-established cryptography, one with the ciphertext and one with a passphrase, and storing them apart from each other.

I'm sorry for being harsh, it's not my intention to be mean or discouraging. The fact that you're releasing this open source indicates a willingness for peer review, and that mentality should be applauded. However, it's almost always a bad idea to try to implement cryptography yourself unless you're a cryptographer (I'm not one, and I'd certainly hesitate to do so myself). Even just using existing well-written crypto libraries can be very hard to get right....

Best of luck!

[gmaxwell]

cyclically xor-ed with the pass key.

This sounds like dangerously crackable snake oil cryptography.  If there is plaintext with a known xor relationship then reuse of the pass key bits allows their recovery,   

Please don't make up novel cryptosystems and encourage other people to use them unless its strictly necessary. There are many existing, mature, well reviewed systems for symmetric encryption.

This also appears to be offtopic.

[CTNieves]

Well, I've got some feedback if you'd care for any...

1. It's not obvious that "encryption" automatically deletes the just-encrypted file.
2. The deletion of the original file is not a secure delete. Because there's no way to inhibit the deletion, the just-encrypted data is guaranteed to still be present on the hard drive.
3. The deletion of the original file fails on Windows (because you don't close the file first).
4. If the "out" file already exists, "encryption" mode is assumed, and file.x and file.y are silently overwritten if they exist.
5. The "key", which additionally "encrypts" the file, is naively implemented and does not add any additional protection. Your statement that the two files can be "stored in separate secure locations--which is unnecessary" is inaccurate; the key feature leads to a false sense of security and should be removed entirely or re-implemented.

Finally, I'm not entirely clear what advantage this scheme has over creating two files using well-established cryptography, one with the ciphertext and one with a passphrase, and storing them apart from each other.

I'm sorry for being harsh, it's not my intention to be mean or discouraging. The fact that you're releasing this open source indicates a willingness for peer review, and that mentality should be applauded. However, it's almost always a bad idea to try to implement cryptography yourself unless you're a cryptographer (I'm not one, and I'd certainly hesitate to do so myself). Even just using existing well-written crypto libraries can be very hard to get right....

Best of luck!

Thanks for the feedback! I didn't necessarily intend to give off the message that this should be used, however I do understand how what I wrote can be interpreted that way. Could you possibly explain how the implementation of the passphrase is naive and doesn't add any additional security?
I created this simply because I could and I don't try to claim that it is better than any other form of cryptography with similar results. However I don't see how the bitwise operation XOR isn't considered "well-established cryptography" considering it's use in large scale projects(to be fair, it is used along with AES in the applications I'm familiar with).

I apologize if any of this comes of as ignorant or "harsh", as you also stated.

[Vod]

Posted From bitcointalk.org Android App

This line is going to get every one of your posts deleted.   

Stop using that app or have the developers update it so it doesn't spam.

[CTNieves]

Quote from: CTNieves on October 13, 2014, 08:18:41 PM

cyclically xor-ed with the pass key.

This sounds like dangerously crackable snake oil cryptography.  If there is plaintext with a known xor relationship then reuse of the pass key bits allows their recovery,    

Please don't make up novel cryptosystems and encourage other people to use them unless its strictly necessary. There are many existing, mature, well reviewed systems for symmetric encryption.

This also appears to be offtopic.

I posted here as it seems to be the most appropriate place to receive feedback(just as btchris has done) on a piece of software from knowledgeable people. I apologize if my the wording in my original post advocates the use of this over any other method and I'll change the wording when I get the chance(currently on vacation).

Please don't make up novel crypto systems

I didn't make up this crypto system, I've seen a very very similar form of cryptography applied by a reasonably reputable company.

Is there a more appropriate section of the forums you would recommend I post this to?

[CTNieves]

-snip-

Thank you. Fixed.

[CTNieves]

I'll remove this project from my website and github when I get the chance. I apologize for spamming the site with an allegedly unsafe piece of software. I won't make anymore cryptography based programs.

[btchris]

Thanks for the feedback! I didn't necessarily intend to give off the message that this should be used, however I do understand how what I wrote can be interpreted that way. Could you possibly explain how the implementation of the passphrase is naive and doesn't add any additional security?

If you have both of the "xor" files, file.x and file.y, than the additional "key" is simply an XOR cipher with a static repeating key on top of that. To quote Wikipedia:

By itself, using a constant repeating key, a simple XOR cipher can trivially be broken using frequency analysis.

I didn't make up this crypto system, I've seen a very very similar form of cryptography applied by a reasonably reputable company.

Scary, but unfortunately not surprising...

I'll remove this project from my website and github when I get the chance. I apologize for spamming the site with an allegedly unsafe piece of software. I won't make anymore cryptography based programs.

That would probably be best. Remaining open to constructive criticism is always a good thing.