how do most encryption algos work???
I ask this because I made my own, and its a flop. I could eye ball the changes in the encrypted text and decipher the letters. took me 5 mins to break my own encryption. lol, I typed some thing clicked convert then clear so I didn't see what typed. well im looking to develop my own encryption algo with a key(password of any length) and i dont know how to go about it. any ways if any one could point me in the right direction??
Posted on 2002-07-30 17:20:14 by Qages
Rather than designing your own, you should stick to something
written and properly tested by cryptanalysts. There are many
good papers on known algorithms, including weaknesses, strengths,
cryptanalytic attacks, performance --- you name it. Some keywords
to search for would be RC6, Rijndael, AES (another name for Rijndael,
but also the contest of finding a replacement for DES), and Twofish.
I suggest reading materials from a lot of places - obviously RSA would
be "somewhat biased" when talking about RC6, as it's their creation.

A lot of ciphers use S-BOXes or other precomputed tables, making
them rather large (ok, so many of these tables can be generated,
but that still requires an amount of setup code). Rijndael and
Twofish are no exceptions. A typical Rijndael implementation uses
shift, XOR, AND, table lookups. People seem to agree that it's a
rather strong cipher, while still being fast (probably why it won
the AES contest, unless you believe in conspiracy theories ;)).

I personally prefer RC6, mostly because of it's simplicity. There's
no lookup tables involved. The algorithm was based on RC5, which
had already undergone a bunch of cryptanalysis. The algorithm also
seems to be the fastest of the AES contestants.

Unless size/speed are extremely important, don't consider algorithms
like TEA.
Posted on 2002-07-30 18:12:05 by f0dder
I am looking something that's balanced in speed and strength, yes I probly could find a lib to those you said. but I would like to develop my own some how, the only encryption ways I can think of are substitute one letter for a 2 different letters, perhaps like 'a 'would be 'gh'. and xor, xor is easy to crack, only 255 different possibilities, all any cracker would do if xor 255 different times on the message and look at the unencrypted text and he would surly see the message...
Posted on 2002-07-30 18:24:13 by Qages
Well, if you really want to design your own... just realize it
will not be secure :). Something simple, which would be hard
for the not-so-skilled to handle:

first, rather than XORing bytes, XOR DWORDs. This makes your
key longer - there will still be repeating patterns though,
and if there's large blocks of identical data (like 0padding
at end of PE sections), deriving the key could be easy. Next
enhancement would be using Chain-Block-Cipher mode: when encrypting,
first XOR your plaintext block with the previous ciphertext
block, then encrypt the plaintext as usual. To make this work,
you obviously need an "Initialization Vector", or IV (since there
will be no 'previous ciphertext block' when encrypting the first
block). When decrypting, start by normally decrypting the ciphertext,
and XOR the resultant block with the previous ciphertext block
(again using an IV - and of course the same IV you used for encryption).

This is a start - but even though output might look rather garbled,
even for large blocks of identical data, the algorithm still isn't
secure. I can't explain why as I'm no cryptanalyst - but I still
wouldn't trust such a cipher. There is not enough dependency on
key bits and ciphertext bits (ideally you'd want one changed key bit
to produce radically differently ciphertext). Block size should probably
be larger, too.

If you want more ideas, I would recommend you study the following
ciphers, as they are simple enough in structure that you should be
able to learn something from them:

RC4 - stream cipher. Has some known weaknesses, but is cute nevertheless.
Key setup isn't too expensive, and once that is done, the cipher function
itself is rather fast. Just remember that for stream ciphers, you must
never use the same key for two different messages.

TEA - because it's simple, and has had flaws that have been discussed
and ameliorated. Provides reasonable security considering it's simplicity
and small size.

RC6 - a real cipher, which is still reasonably simple (no S-BOX
magic you have to dig into, it's all a matter of rotates, 32bit multiplication,
XORs and additions).
Posted on 2002-07-30 18:50:26 by f0dder
Would this be useful: ?

For example, the word HELLO.

In hex it would be 48 45 4C 4C 4F.

And then mirror it: 4F 4C 4C 45 48, put it together 4F4C4C4548 and do some maths with this number? Obtaining, after "xors", "ands", etc something such as 3E2C4D2E48? Then separate this such as 3E 2C 4D 2E 48 and show the respective values? And then it is possible to decrypt fast too. Would this be easily crackeable if you use a complex way of using your maths?

Just a thought...
Posted on 2002-07-30 18:52:40 by CodeLover
If you want complex usage of math, go RSA (not too bad) or Eliptic Curve Cryptography (eek) :)
Posted on 2002-07-30 18:57:33 by f0dder
If your happy to use keys equal to or bigger then the data to be encrypted, then unbreakable encryption is possible.

For example if you and a friend both have an identical picture, ideally scanned not computer generate, then by XORing or similar the data bytes with the picture pixel data bytes the message can only be deciphered by the same process. If someone doesn't have the picture they can't decipher the data.

This is only practical in certain situations though. :)
Posted on 2002-07-30 19:35:43 by Eóin
Even with source-length keys, I'd still do a bit more than just XORing
the individual characters - just to be a bit more paranoid.

Anyway, here's a super-simplistic sample cipher, using 32bit key
and 32bit blocks. Intended to be run through a debugger.
Posted on 2002-07-30 19:43:25 by f0dder
There are two(2) test program on the net. They will test your incripted data for you.
Posted on 2002-07-30 19:43:59 by Roy Cline
Updated the sample cipher a bit. Output looks cute, but don't be deceived :).
Posted on 2002-07-30 20:17:28 by f0dder

Updated the sample cipher a bit. Output looks cute, but don't be deceived :).


wow it looks nice. :)
Posted on 2002-07-30 20:41:04 by Qages
What's wrong with TEA?
Also, f0dder, why do your posts always look improperly wrapped?
Posted on 2002-07-30 22:57:55 by comrade

....or Eliptic Curve Cryptography (eek) :)


Hehe, Eliptic Curve is a real headache. I tried to implement it a few months ago bad failed :)



What's wrong with TEA?


TEA is nice, small and fast but not so secure as others :)



Also, f0dder, why do your posts always look improperly wrapped?


Maybe he writes on a terminal with a textbrowser?
Serious, I always wrap my postings to make it easier to read ;)

f0dder,
do you have a ASM implemention of RC6? I only have RC1 and RC4 here :/ (RC4 converted by myself =) )
Posted on 2002-07-31 01:29:25 by bazik

do you have a ASM implemention of RC6? I only have RC1 and RC4 here :/ (RC4 converted by myself =) )

i implemented it about a month ago (tasm :grin:, not optimized), pretty fast algo (not as fast as aes, though).
Posted on 2002-07-31 03:52:22 by Tola
Thanks, Tola!

Hehe, this kind of code reminds me on Svin ot bitRAKE:



sub ecx,[esi+2*RC6_ROUNDS*4+3*4]


:grin:
Posted on 2002-07-31 04:18:18 by bazik

What's wrong with TEA?

Read the various PDFs that's available :). Double keys, iirc also attacks faster than full brute-force, and so on. Much of this has been fixed in later revisions of TEA, but I'd still use something stronger where security is needed.

My posts look "improperly wrapped" because I write them in notepad, and have the habit of inserting linebreaks myself. "Paragraph-style" writing looks fine with automatic linebreaks, but if you only have a little text, I prefer manual breaks... especially since I run a high resolution with a large browser so auto-wrapping tends to give rather long lines that are annoying to read.

Tola, you say RC6 is slower than Rijndael? It's supposed to be a bit faster if both are implemented properly. Hm, I guess it's timing-time :).
Posted on 2002-07-31 08:10:02 by f0dder
Funny enough, I sneaked in the technology of one shot pads in the MASM32 library with a couple of rotating key algos. Bigger the key and unique keys are hard to beat, as long as you keep the key unique. Security is supposed to degrade with repeated use of the same key so you need a mechanism to keep changing the key.

In most instances anything will do the job but if you are really serious, block cyphers are broken in the same way they are designed and thats why I avoid them.

The things to watch out for with one shot pads is dependency on random sequence generators as it is a weakness when used.

Regards,

hutch@movsd.com
Posted on 2002-07-31 11:03:18 by hutch--
I'm not into encryption thingy but I've heard they also use compression algorithms together with encryption.

Just my 2 cents since there wasn't anyone that mentioned compression. :)
Posted on 2002-07-31 13:46:47 by stryker
how does that rc6 thing work? i am unable to get a decripyted text
Posted on 2002-07-31 14:56:12 by Qages

Tola, you say RC6 is slower than Rijndael? It's supposed to be a bit faster if both are implemented properly. Hm, I guess it's timing-time :).

just did some testing, on an old pc of mine i use for debugging (pentium 200) rijndael is almost twice as fast as rc6. on my main machine (athlon 900) rc6 is about 20 percent faster than rijndael.
Posted on 2002-07-31 16:09:29 by Tola