Thread: Bitshift Crypt

You can use any sequence of operations you like, so long as you can also find a sequence which reverses it.

I wouldn't do that at all. What for? I might encrypt a whole message, but a small password?

But most symmetric ciphers come down to XORing, in the end, preceded or followed by mixing the data up a bit.

The simplest and most common encryption using bitwise operations uses XOR.

The use of left and right shift (if you take care not to lose bits) might be possible for a simple encryption, but if you plan to use a constant shift all the way, it will just be a variant of Caesar cypher which can be effortlessly cracked by a child. If you use some sort of a key, there are still very few different shifts you can use.

None of these encryptions are particularly secure but if you have relatively unsensitive data and want to keep off casual users, XOR might be fine.

If you have very sensitive data, one-way encryption might offer more security.

What way would you prefer?

Do you know any short sample functions? How would you do?

I would use a library like Crypto++ to do the dirty work for me, since I am too lazy/incompetent to implement the functions correctly myself . Exactly what cryptographic primitive is selected depends on the protocol and other requirements. If we're talking about password storage, it seems to me that hashing the user supplied password is still good practice.

asymetric key pairs are probably the most secure and simplest to implement. Just make sure you pick a large enough key strength. 32 bit is trivial to implement, but also trivial to crack. 64 bit is a bit harder to implement but nearly impossible for anyone short of the NSA to crack.

I think your key size figures of 32 and 64 apply more to symmetric key ciphers, but even then AES uses key sizes of at least 128 bits. I note that a 512 bit RSA key (or rather, number that could have been used for RSA) was factored by a team not from the NSA in 1999. It seems to me that 1024 bits is a more common minimum key size for public key cryptography.

Then again, all this would not matter if ratte is not actually interested in using strong encryption and more interested in learning how to implement simple home-brewed encryption with bit shifts and such.

I need to store the password a user needs to have acccess to a database. so i can't do the asymetric way 'cause there's no hash to compare with.

If you can store a password, you can store a hash of the password. The "asymetric key pairs" that abachler wrote about refers to public key cryptography, not cryptographic hashes.

If I got it right a bitshift, XOR or something, with a keyword (not like caesar) would be the best for my problem.

Is this for a school project, or is this for real?

Is it professionally/commercially real or just-for-fun real?

Have you tried using Google?

Please tell us the name of this broken product so we know to avoid it's use in future.
http://www.interhack.net/people/cmcu...e-oil-faq.html

Perhaps you should describe the problem, not how to implement your solution.
Things like key exchange, shared secrets etc have already been solved. Perhaps we could suggest alternatives which reveal less information at critical times.

You're not going to implement a secure trivial crypto system which isn't going to be trivial to break. This is going to take a lot of work and careful thought, not 5 lines of code hastily grabbed from a forum.