• Please review our updated Terms and Rules here

encryption algorithm

Mike Chambers

Veteran Member
Joined
Sep 2, 2006
Messages
2,621
i'm no encryption expert here... but i devised a little encryption algorithm and programmed an encrypter and decrypter for it. i was wondering how secure you guys think it really is.

what it does, is it splits up the original data into 256-byte chunks and does seven iterations of the following on each chunk:

1. shift entire bit structure left by one bit
2. go through new bit structure two bits at a time, swapping them
3. XOR each byte of the result with the corresponding byte in the supplied passkey. (wrapping back to the beginning after it reaches the end of the key of course)

it's nothing special i know, but i just want to know if you guys think this is even halfway decent. i'm just doing this for the heck of it. bored i guess!
 
If you are trying to obscure data from casual observation, this will work fine. If you are trying to hide something from somebody who is serious (read: NSA) then this is trivial.

Check out "Applied Cryptography" by Bruce Schneier. It's an excellent reference.

Good encryption algorithms are based on difficult math. The difficult math is usually some spin on factoring a large polynomial, which can be done but takes a long amount of time. And as computers get faster, you compensate by making the polynomial that much larger. :)
 
i'm no encryption expert here... but i devised a little encryption algorithm and programmed an encrypter and decrypter for it. i was wondering how secure you guys think it really is.

what it does, is it splits up the original data into 256-byte chunks and does seven iterations of the following on each chunk:

1. shift entire bit structure left by one bit...
I think you mean the 256-byte structure is *rotated* here (the MSB of the chunk becomes the LSB of the same chunk)? Otherwise you are changing your data structure when you decrypt because you stand the possibility of losing the MSB of the chunk (if it was binary one, because usually binary zeros are shifted in during that operation) before you decrypt. Mathmatically you would be doubling the value of the chunk (see below about mathmatical operations) if the MSB is a binary zero (if the MSB is a binary one it ultimately performs another mathmatical operation that could be duplicated if they know the size of your chunk).

2. go through new bit structure two bits at a time, swapping them...
But this only technically swaps the bits if they are opposite of each other:

00 -> 00
01 -> 10
10 -> 01
11 -> 11

This is a mathmatical operation as well. Any mathmatical operation that is uniform in the coding process (not talking programming) has the potential for being nullified.

3. XOR each byte of the result with the corresponding byte in the supplied passkey. (wrapping back to the beginning after it reaches the end of the key of course)...
XOR encoding is known as Vernam's cipher, one of the strongest around as long as your key is long enough (with no repeating subsequence that would effectully make it shorter). The key is 256 bytes (2048-bit) long? That encryption alone is enough without involving the other mathmatical factors.
 
yes, it's just rotated left and puts what was previously the left-most bit on the very right. i've already done a bunch of test encrypts/decrypts with it and it always works and the file size remains the same.

i'm attaching a ZIP file with the encrypter (ENTES.EXE) and decrypter (DETES.EXE)

also included the source to each. i actually decided to take out the part where it swaps the two bits. IBMMuseum you had a good point there. didn't even think about that. and no, the key isnt necessarily 256 bytes long. it's however long you want it.

btw, TES stands for Tarded Encryption Standard. i figured that fits.
 

Attachments

  • tescrypt.zip
    59.2 KB · Views: 1
Last edited:
professional postwhoring in progress... stay clear.

professional postwhoring in progress... stay clear.

here's the encrypt source just in case you dont wanna actually bother downloading anything. works in QBasic, QuickBASIC 4.x, and QuickBASIC 7.1

easily(read: effortlessly) possible to port to visual basic. it'd be MUCH faster and support long filenames.

Code:
DECLARE FUNCTION ShiftBitsLeft$ (intext$)
CLS
PRINT "Tarded Encryption Standard (TES) file encrypter v1.0"
PRINT "Written by Mike Chambers, 10/19/06"
PRINT
LINE INPUT " Input filename: ", filein$
PRINT "        Passkey: "; : COLOR 0, 0: LINE INPUT "", passkey$: COLOR 7, 0
LINE INPUT "Output filename: ", fileout$
IF filein$ = "" OR fileout$ = "" OR passkey$ = "" THEN END
chunksize = 256

PRINT
PRINT "Encrypting " + filein$ + " => " + fileout$
PRINT
OPEN filein$ FOR BINARY AS #1
OPEN fileout$ FOR OUTPUT AS #2
DO
        text$ = SPACE$(chunksize): IF LOF(1) - LOC(1) < chunksize THEN text$ = SPACE$(LOF(1) - LOC(1)): exitprog = 1
        GET #1, , text$
        FOR iteration = 1 TO 7
                text$ = ShiftBitsLeft(text$)
                passloc = 1
                FOR XORcycle = 1 TO LEN(text$)
                        text$ = LEFT$(text$, XORcycle - 1) + CHR$(ASC(MID$(text$, XORcycle, 1)) XOR ASC(MID$(passkey$, passloc, 1))) + MID$(text$, XORcycle + 1)
                        passloc = passloc + 1
                        IF passloc > LEN(passkey$) THEN passloc = 1
                NEXT XORcycle
        NEXT iteration
        PRINT #2, text$;
        LOCATE CSRLIN - 1, 1
        PRINT "Status:" + STR$(LOC(1)) + " of" + STR$(LOF(1)) + " bytes encrypted"
LOOP UNTIL exitprog = 1 OR INKEY$ = CHR$(27)
CLOSE

FUNCTION ShiftBitsLeft$ (intext$)

bits$ = ""
FOR n = 1 TO LEN(intext$)
        nu = 128
        cc = ASC(MID$(intext$, n, 1))
        FOR num = 1 TO 8
                IF cc - nu >= 0 THEN cc = cc - nu: bits$ = bits$ + "1" ELSE bits$ = bits$ + "0"
                nu = nu / 2
                onbit = onbit + 1
        NEXT num
NEXT n
bits$ = MID$(bits$, 2) + LEFT$(bits$, 1)

outstring$ = ""
FOR n = 1 TO LEN(bits$) STEP 8
        nu = 128
        cbyte$ = MID$(bits$, n, 8)
        total = 0
        FOR num = 1 TO 8
                IF MID$(cbyte$, num, 1) = "1" THEN total = total + nu
                nu = nu / 2
        NEXT num
        outstring$ = outstring$ + CHR$(total)
NEXT n
ShiftBitsLeft$ = outstring$
END FUNCTION



okay, and here's decrypt source. it's basically the same, except shifting the bits right instead of left of course.

Code:
DECLARE FUNCTION ShiftBitsRight$ (intext$)
CLS
PRINT "Tarded Encryption Standard (TES) file decrypter v1.0"
PRINT "Written by Mike Chambers, 10/19/06"
PRINT
LINE INPUT " Input filename: ", filein$
PRINT "        Passkey: "; : COLOR 0, 0: LINE INPUT "", passkey$: COLOR 7, 0
LINE INPUT "Output filename: ", fileout$
IF filein$ = "" OR fileout$ = "" OR passkey$ = "" THEN END
chunksize = 256

PRINT
PRINT "Decrypting " + filein$ + " => " + fileout$
PRINT
OPEN filein$ FOR BINARY AS #1
OPEN fileout$ FOR OUTPUT AS #2
DO
        text$ = SPACE$(chunksize): IF LOF(1) - LOC(1) < chunksize THEN text$ = SPACE$(LOF(1) - LOC(1)): exitprog = 1
        GET #1, , text$
        FOR iteration = 1 TO 7
                passloc = 1
                FOR XORcycle = 1 TO LEN(text$)
                        text$ = LEFT$(text$, XORcycle - 1) + CHR$(ASC(MID$(text$, XORcycle, 1)) XOR ASC(MID$(passkey$, passloc, 1))) + MID$(text$, XORcycle + 1)
                        passloc = passloc + 1
                        IF passloc > LEN(passkey$) THEN passloc = 1
                NEXT XORcycle
                text$ = ShiftBitsRight(text$)
        NEXT iteration
        
        PRINT #2, text$;
        LOCATE CSRLIN - 1, 1
        PRINT "Status:" + STR$(LOC(1)) + " of" + STR$(LOF(1)) + " bytes decrypted"
LOOP UNTIL exitprog = 1 OR INKEY$ = CHR$(27)
CLOSE

FUNCTION ShiftBitsRight$ (intext$)
bits$ = ""
FOR n = 1 TO LEN(intext$)
        nu = 128
        cc = ASC(MID$(intext$, n, 1))
        FOR num = 1 TO 8
                IF cc - nu >= 0 THEN cc = cc - nu: bits$ = bits$ + "1" ELSE bits$ = bits$ + "0"
                nu = nu / 2
        NEXT num
NEXT n
bits$ = RIGHT$(bits$, 1) + LEFT$(bits$, LEN(bits$) - 1)

outstring$ = ""
FOR n = 1 TO LEN(bits$) STEP 8
        nu = 128
        cbyte$ = MID$(bits$, n, 8)
        total = 0
        FOR num = 1 TO 8
                IF MID$(cbyte$, num, 1) = "1" THEN total = total + nu
                nu = nu / 2
        NEXT num
        outstring$ = outstring$ + CHR$(total)
NEXT n
ShiftBitsRight$ = outstring$

END FUNCTION

seeing as QB has no true built-in functions for working with individual bits, i had to code that stuff manually and store the 1's and 0's and strings. slow and horribly ineffecient but it works. a 5 MB file took 5 minutes on my athlon 64 3700+ (2.4 GHz)
 
...i actually decided to take out the part where it swaps the two bits. IBMMuseum you had a good point there. didn't even think about that...

But if someone is cracking your code they would probably just blindly swap the bit pairs if they had an idea you were doing that. Be warned about doubling/halving (which is very close to what you are doing with single bit shifts) because it will be easy enough to nullify that feature (think if someone is trying keys that are doubled/halved of yours at the same length; in that case you are just effectively changing the key value to be a doubled/halved version). If your 256-byte chunk is an odd value (meaning a binary one for the LSB) after the rotation it means the MSB was a binary one before & they know not to perform that halving operation on the chunk to decode it.

Also standard ASCII encoding can give it away too. Letters are going to be a short sequence of bit patterns, being framed within your chunk evenly. It is possible they could find the start of each sentence that way, because a capital letter has the MSB of the byte value as a binary one in ASCII. They can also look for the evidence of a space after a period too.

Jeff Prosise had an example of Vernam's cypher using Assembler in his DOS x Techniques & Utilities books (x = 5 or 6). Said elsewhere within this thread the best encodings are complex mathmatics (because even the most basic processor can do bit shifts & swaps) that take too much computational power too break. And yes, my knowledge here is a small form of a current job I have. :)
 
just a note to anybody who actually tried to use the source code, it works perfectly in freebasic too... so you can compile a native windows or linux version.

the only thing you have to do is change both instances of ctext$ to curtext$

apparently "ctext" is a native freebasic keyword
 
But if someone is cracking your code they would probably just blindly swap the bit pairs if they had an idea you were doing that...

Even though I know you pulled the bit-swapping, here is further elaboration:

Say we actually talk (sounds) in binary ("0" are no sounds for a period of time, "1" are a note that can cummulate stringing them together) & our language is composed of different length binary strings to make the words. Just so happens that the word "biscuit" is spoken "1100111100000011". You run it through just the bit-swapping portion & say the result aloud: "1100111100000011". Your dog (not understanding cyphers at all) hears you & licks his chops...

Besides a long enough key, if it doesn't change too often you must make sure the data you are cyphering does. If there is enough interest I thought of a story I can write. But there has to be enough interest (Curtis, you were a CT & not responding here?)...
 
you could create a reasonably secure algorythm by programming a pseudo random bit sequence generator, rather like the one used to generate random numbers from the RND command in basic, but much bigger.

you do this by creating a "shift register" of say 64 bits length.

at various points along it, and at the end, you create "taps".
You sample the bits in those positions, EXOR them together and feed the result back into the start of the shift register.
The tap positions are critical for maximum length random sequences...

Cant find 64 bits in my copy of "Horowitz & Hill", but

8 bits is tapped at 4,5,6 & 8
16 bits is 4, 13, 15 & 16
24 bits is 17,22, 23 & 24

and more simply...

7 bits is 6 & 7
28 bits is 25 & 28
39 bits is 35 & 39

You "prime" the shift register with a passphrase, and then start shifting bits out. this generates a "one time pad" type bit sequence which you can EXOR with the text to be encripted.

It is important to either - not use the same passphrase for more than one message - or - keep a record of the number of bits shifted out, and always carry on the pseudo random sequence from where you left off, as if you use the same "one time pad" for more than one message, then it's simple maths, and microseconds to break your code.

Incidentally CRCs are generated by nearly this method. you just use another EXOR gate in the feedback loop, and feed the data stream to be CRCd into this, thus modifying the random sequence, whatever is left in the shift register at the end is the CRC. it's good because it creates wildly different output data from tests on every bit of the input data.

:confused:
 
Back
Top