What's new

Rate this homemade encryption Meathod

U

UHAX

Cheap Good Quality RGH Shop
Messages
273
Reaction score
53
Hello, I am currently coding a database application and made it so that files can be encrypted if i so much want. Please rate this encryption. And also the encryption compressor.
For my encryption i coded it so that it can encrypt any letter in the English alphabet. And all symbols and numbers on a standard US keyboard. the algorithm starts with each one of the char having a 7 digit integer for example. "9353320". This could be the letter "a". Capitalized letters do not share the same integers. This was the first part. Then i thought well, People could just go back and know the letter typed and then trace it back to that string of data. So i coded 55 different possible sets for all letters and numbers (ect.). Then i wanted to make it so that i would have five different sets for the housing of the security block. "Or the decryption instructions" This uses a total different language for the program to read the file password, If it can be double encrypted, what algorithms it should use to decrypt. And also file settings. But i did not want to make it so that it was just all the same algorithm through the file. So i decided every 20 char it would change the algorithm to a whole new one so that is would be pretty scrambled. But as you can imagine one letter turning into 7 digits makes the file quite large. So i decided to add a double encryption compression system that counts the location of the algorithms and also the strings of the algorithms and shortens them to about two digits. And this is not really a issue because if you back log this into decompression you are left with the jumbled algorithms once again.
How would you rate this encryption system? Useful? Worthless? And out of over 500 tests i have not lost one byte of data from the original file. The only way to mess up decompiling is deleting a section of the encrypted file. But at that point. Whomever deleted it still wont get the data saved.
 
W

WildeThing

Enthusiast
Messages
212
Reaction score
63
Generally, the rule for 99.9% of developers is "don't roll your own crypto". The people behind encryption schemes are often very skilled mathematicians who've dedicated much of their careers to the field. The idea that an average person without their background can come in and create something that can even begin to compete is trivialising the entire field.

I'm unsure as to whether you're writing a database system that supports the storage of encrypted files (via some BLOB implementation - should be avoided, generally), or if you're writing a database system that allows tables to be encrypted, or if you're writing a general file encryption (& compression) algorithm. In the real world of databases, I imagine more work would go into data deduplication, optimised queries, caching, etc. The thing about your encryption scheme is that someone could readily reverse engineer it. The difference between that and the most common encryption algorithms today is that you can go ahead and reverse engineer them (heck, you don't have to since they're all open-source because nobody trusts things you can't peer-review); their security relies on the fact that you won't be able to feasibly guess the key used for the encryption (clever asymmetric encryption schemes have the added ability to use the public key to verify integrity of encrypted documents).

tl;dr - nice for an educational thing to write, just don't be rolling any of your own crypto algorithms in production software.
 
U

UHAX

Cheap Good Quality RGH Shop
Messages
273
Reaction score
53
Generally, the rule for 99.9% of developers is "don't roll your own crypto". The people behind encryption schemes are often very skilled mathematicians who've dedicated much of their careers to the field. The idea that an average person without their background can come in and create something that can even begin to compete is trivialising the entire field.

I'm unsure as to whether you're writing a database system that supports the storage of encrypted files (via some BLOB implementation - should be avoided, generally), or if you're writing a database system that allows tables to be encrypted, or if you're writing a general file encryption (& compression) algorithm. In the real world of databases, I imagine more work would go into data deduplication, optimised queries, caching, etc. The thing about your encryption scheme is that someone could readily reverse engineer it. The difference between that and the most common encryption algorithms today is that you can go ahead and reverse engineer them (heck, you don't have to since they're all open-source because nobody trusts things you can't peer-review); their security relies on the fact that you won't be able to feasibly guess the key used for the encryption (clever asymmetric encryption schemes have the added ability to use the public key to verify integrity of encrypted documents).

tl;dr - nice for an educational thing to write, just don't be rolling any of your own crypto algorithms in production software.
Appreciate the feedback, And this is for just saving files for a personal protocol over a ftp server. I just made a program that i can put on my devices that will grab and sort the data for easy upload download and viewing. Its something i need when i am jumping around the country. And sense it is easy to reverse engineer i as you said did go about obfuscating the source which as you said. people don't trust. I am working on something that is more common with using public and private keys. But the math involved is quite excruciating. But once again, Thank you for the feedback.
 
Top Bottom