1 
Offline
1. Algorithm overview
2. QSE file specification
#QSEV[VERSION NUMBER] 3. ImplementationsFeel free to post your comments/ideas/hates here.
Forum
Off Topic Qrchack's Simple Encryption
Qrchack's Simple Encryption
22 replies 1. Algorithm overview 2. QSE file specification 3. ImplementationsFeel free to post your comments/ideas/hates here.
EDIT: Aah, you want to store passwords with it? Even worse. You shouldn't use two-way function for storing a password, hence why we use hashes such as MD-(2,4,5), SHA-1, SHA-2, SHA-3 ( recently announced this year! The entrant Keccak won because it's structure was very different to it's predecessors, hence cryptanalytic attacks against previous versions of SHA wouldn't be applicable ( in any f-adapted form ) to SHA-3. Pointless in my opinion, since there will be attacks against it eventually, and if anything the older structure has really held the test of time! ), etc.
I'd suggest you read Practical Cryptography by Bruce Schneier, a friend lent me his copy nearly a year ago, it's an excellent book ( I actually haven't given it back yet.
), though it is quite old. You'll need to have at least A-levels under your belt, in order to get near understanding the mathematics behind the algorithms, though. 
).The QSEv2 won't store password in the file. It'll count a checksum out of the password and the data will be encrypted with -checksum offset, so it would be harder to crack it. And because it'll also encrypt the header, we can check if the password is correct just by checking if there is #QSE header at the beginning of the decrypted file).
Thanks for the book, I'm gonna find it as an ebook somewhere and read. If I get an good idea for QSE, I'll post it here.
mafia_man: you can help me if you want as you're polish. I need someone like a "master" 
Geez has writtenThe QSEv2 won't store password in the file. It'll count a checksum out of the password and the data will be encrypted with -checksum offset, so it would be harder to crack it. And because it'll also encrypt the header, we can check if the password is correct just by checking if there is #QSE header at the beginning of the decrypted file).
Are you aware that you didn't actually specify any means for utilizing the "password" in the encryption of the text? If you did, it would actually become a cipher ( though a weak one that can be broken with a few bytes of cleartext ).
EDIT: I wouldn't reccommend using mafia_man as any kind of tutor, he once asked me to break a piece of "encrypted" data that was a base64-encoded string, with the added failure of doing it from a website. I mean, really?
DannyDeth:! By the way: created a project on Google Code for this. Check it out:
http://code.google.com/p/qses/
I'm gonna post source & binaries of what have I got now.
It's absolutely trivial to decrypt long cryptograms in such a case. You can simply count how often which char occurs and you can then estimate what this char is actually standing for (there are tables which tell you which letter occurs - statistically - how often in a text for each language).
Okay, there's still your simple permutation but it is quite useless. A human being would probably need just a few seconds to find out that you simply swapped letters in pairs of two. I mean it's really not hard to recognize once you found the ASCII offset. You don't even need to program an algorithm or anything to find out how it's done.
So a non static offset (a different offset for each char) which depends on different factors would already improve your algorithm a lot. Maybe depending on the position in the text or a password string which is used to generate offsets. It still wouldn't be very safe but already much harder to decrypt.
The lack of time is a killer.
@
DC: The dynamic offset (which kind of reminds me ASLR) will increase the difficulty but it still has some bugs such as: Offset > Plaintext Length ...@
Geez: You said the password will not be included but will exist as a checksum. So your algorithm needs another algorithm to work. Smart? No. sixpack has writtenI came up with my own hashing algorithm in 2 hours that is way more secure.
Please post.
I'd be glad to cryptanalyze it for you. sixpack has writtenRight now I have been working on a public key cryptographic system[/quote[
Unless you have a phD in Applied Mathematics, I doubt you will get very far. It's all already been thought of: integer factorization problem, birthday problem, insolvabled lattices, etc. Unfortunately there is not much left in the field to be advanced in, with lattice-based being the most innovative ( and thought to be unchallenged by quantum computing ) these days.
Unless you have a phD in Applied Mathematics, I doubt you will get very far. It's all already been thought of: integer factorization problem, birthday problem, insolvabled lattices, etc. Unfortunately there is not much left in the field to be advanced in, with lattice-based being the most innovative ( and thought to be unchallenged by quantum computing ) these days.
http://lua-users.org/wiki/CryptographyStuff
but I'm sure there're ready solutions for Pascal and ofc for C(++) too. So, why?
If you want to make it easy for everyone then wouldn't it be easier just to edit/remake somebody's work to make it more user-friendly?