Qbasicnews.com

QbasicNews.Com => Challenges => Topic started by: ca336458 on May 26, 2004, 12:38:49 AM

 Title: Data Encryption Post by: ca336458 on May 26, 2004, 12:38:49 AM I have been sitting here pondering what the best encryption algorithm might be. I am talking about an algorithm that is nearly impossible to decrypt. Anybody have any really good algorithms?[/code] Title: Data Encryption Post by: Neo on May 26, 2004, 11:35:50 AM An encryption algo that isn't decryptable sucks! :DTake a look at this very *d'Oh* example:Code:INPUT "String to encrypt:", M\$PRINT "Encrypted: " + CHR\$(186)But there are numerous of encryptions that are hard to decrypt. Note that COMPRESSION = a form of ENCRYPTION. So you could search on google for COMPRESSION (you'll turn to LZW probably) ;) Title: Re: Data Encryption Post by: Mango on May 27, 2004, 02:57:53 AM Quote from: "ca336458"I have been sitting here pondering what the best encryption algorithm might be. I am talking about an algorithm that is nearly impossible to decrypt. Anybody have any really good algorithms?[/code]one way is...get a good (crypto-quality) hash function, and a good (crypto-quality) Pseudo random number generator.  Your hash function should have the following characteristics:low probability of collisionsnon-feasable to find data that hashes to a particular valueThe PRNG should have the following features:statistically random outputdoes not leak internal state at a rate that would be useful for attackers (ie internal state cannot be determined from long runs of output)once you have good hash and PRNG functions, you could build a system like the following...to encrypt:1 get password to encrypt file2 hash the password3 hash the file4 seed the PRNG with 2 & 35 encrypt the file by combining file data with PRNG output6 hash the encrypted file7 seed a second PRNG with 2 & 68 encrypt 3 with 79 write the encrypted composit consisting of 8 & 5To unencrypt...1 get password2 hash passwordparse the encrypted composit file into:3 the encrypted hash of the original file4 the encrypted file5 hash 46 seed a PRNG with 2 & 57 unencrypt 3 with 68 hash 79 seed a second PRNG with 2 & 810 unencrypt  4 with 9Which would offer data integrity and authentication.  The security of this type of system rests on the security of the password.  If you make it costly to test each password, (eg takes several seconds of processing to seed the PRNG) then you should be pretty good, even if you don't want to use a very long password.  Another thing that this kind of scheme does is...even if an attacker has a plaintext/cyphertext pair, he can't recover your password, or attack another file encrypted using the same password.The pitfalls are many...and the learned folk on the sci.crypt newsgroup generally reccomend against "rolling your own", and reccomend using techniques that are "tried and true".  I've rolled one in c++...currently at    (http://bellsouthpwp.net/b/r/brightwave/JCryptW1060.zip) ...that works...it's a console app but it's easy to use in windows...just "drag-n-drop" or "send-to" files to the exe and it launches and prompts for passwords, etc.  I've had fun making the system, and have learned tons, but don't expect people to give you praise for your work.  Instead, people with knowledge will PooPoo your efforts, call it "snake-oil" and worse, and no one else will care...however, I encourage you to learn about, plan, and implement crypto...it's challenging and interesting.  Good luck. Title: Data Encryption Post by: na_th_an on May 27, 2004, 11:08:34 AM RSA and another methods of public/private password are impossible to decrypt without the password. Title: Data Encryption Post by: Neo on May 27, 2004, 11:12:46 AM How about md5 CRCs? Can't it be applied to a larger scale? Title: Data Encryption Post by: ca336458 on May 27, 2004, 12:25:06 PM The best way to encrypt is similar to winzip and wordperfect, programs that let you password lock a file. What you do is you ask the user for a password. You use this password to do something to the data. You don't store the password in the data at all. So in order to decrypt the data, the user would have to input the correct password. If they enter the wrong one, then what they get is random data based on the password they gave. And of course, the longer the password is, the better. It works well because disassembling the program that you use, will give you no clue either. Well, unless you are psychic and can read the person's mind for the password. So I guess there is no way to encrypt something that would make it impossible to decrypt. Title: Data Encryption Post by: na_th_an on May 27, 2004, 12:56:10 PM Quote from: "Neo"How about md5 CRCs? Can't it be applied to a larger scale?MD5 is a summing-up function. It sums up the message, then gets encrypted to create digital signatures or certificates. It is not a crypto-system itself. Title: Data Encryption Post by: oracle on May 27, 2004, 05:39:48 PM ... and it's impossible for a computer to decrypt anyway ;) Title: Data Encryption Post by: KiZ on May 28, 2004, 05:53:54 AM Yey. I made a crypto function yesterday. Quite pleased with it really. Impossible to crack without the password. When you put the same word and password in to be encrypted twice, you can get different results each time! Very secure.Method --takes a random number-XORs the random number with each ASCII of the password.-Then XORs each ASCII Char code of the text to be encrypted with the new password.-Produces a long number string, different every time.-can be decrypted fine every time.What do you guys think of the method? Title: Data Encryption Post by: ca336458 on May 28, 2004, 12:25:08 PM How do you decrypt the data if you are XOR(ing) your password with random numbers? To decrypt the program would XOR each char of the password that the user enters. How does the program know which random numbers to use? Title: Data Encryption Post by: KiZ on May 28, 2004, 03:57:31 PM I was wondering wether someone would pick up on that.What I neglected to mention was, that it stores the random number at the beggining of the number String ;)IEencodedstring = randomnumber + text XORed  with Password XORed with number at start of string.Really, its just to make it all the more confusing for the decryptors. Not that they could decrypt it without the password, anyway.The random number just makes it different every time, eg if you were passing these as private commands in an OS and you didnt want any observers to know what was being passed, then they wouldnt even know if you had passed the same one twice, because it would appear different everytime. =) Title: Data Encryption Post by: ca336458 on May 28, 2004, 06:17:51 PM A good decryption algorithm MUST have a password or random numbers to be good. And if they have both then it's even better. What about swapping the bits of all the data in the file? I mean using a password and then from that password, perform some swapping of the bits of all the data. Or even better, invent your own language, then use an encryption on it! Nobody will be able to decrypt something in a different language. Something like aliens sending us a message, we would never know what the message is. Well, WE wouldn't, but the government and military would know in time.  :rotfl: Title: Data Encryption Post by: whitetiger0990 on May 28, 2004, 06:28:08 PM nah aliens wont contact us. unless they are evil. it would mess up us all up. ever hear of the "Prime directive"? :wtnod2:edit: working... on.... algorithm... now..... Title: Data Encryption Post by: KiZ on May 29, 2004, 06:57:44 AM Quote from: "ca336458"A good decryption algorithm MUST have a password or random numbers to be good.So does that mean you like my routine? Title: Data Encryption Post by: ca336458 on May 29, 2004, 01:30:08 PM Quote from: "dark_prevail"Quote from: "ca336458"A good decryption algorithm MUST have a password or random numbers to be good.So does that mean you like my routine?Yes, I like the routine, but just as long as you realize that XORing 2 equal #'s (2 XOR 2) then you will get 0. So you would have to watch for that. You could add some more encryption layers to your code to make it even harder to crack. What I mean is you can execute your code, then maybe reverse(1=0, 0=1) all the bits in the data, then write the data from end to beginning, etc. To make it better, maybe your should force the user to enter a long password and generate more than one random number.  :rotfl: Title: Data Encryption Post by: Mango on May 29, 2004, 03:33:21 PM Quote from: "dark_prevail"I was wondering wether someone would pick up on that.What I neglected to mention was, that it stores the random number at the beggining of the number String ;)IEencodedstring = randomnumber + text XORed  with Password XORed with number at start of string.This is totally weak.  Suppose an attacker gives you a file to encrypt.  He now has a plaintext/cyphertext pair.  Based on your scheme, he can easily recover your original password and unencrypt any other file you have encrypted using the same password.  Any decent crypto-system should not be vulnerable to such a trivial "chosen plaintext" attack.  You might not think that this is important...you would be mistaken.  Suppose the attacker doesn't know the whole contents of the file...rather he just knows it's a Word document.  It is quite possible that knowledge of particular bytes in the Word file structure would be enough to back out your password!!!  This is a major vulnerability.  Cheers. Title: Data Encryption Post by: KiZ on May 29, 2004, 05:04:02 PM Yes, but he wouldnt know the structure of the encoded string. That is secret. I mean, even if I encoded some text he gave me, he still couldnt work it out unless he knew about what the number on the front did, and how to use it. And besides, the script is not for encoding text documents. It would be for encoding short messages or commands. =PNo need to be so condescending. Title: Data Encryption Post by: Mango on May 29, 2004, 07:46:49 PM Quote from: "dark_prevail"Yes, but he wouldnt know the structure of the encoded string. That is secret. I mean, even if I encoded some text he gave me, he still couldnt work it out unless he knew about what the number on the front did, and how to use it. And besides, the script is not for encoding text documents. It would be for encoding short messages or commands. =PNo need to be so condescending.sorry...didn't mean to be condescending.  Just trying to point out issues that others, smart people who have given encryption a great deal of thought, have come up with.  On another note...any decent encryption routine should remain secure *even if your attacker has your source code*.  This is critical.  "Security through obscurity" is a recipe for disaster.  Seriously...I'm not being condescending.  Crypography has many layers and issues.  If you are seriously interested there is a bunch of free literature available.  The "Handbook of applied cryptography" is a good free place to start...available on the net for free.   I wrote my first crypto in QB...using what I thought was a good PRNG.  After learning a bunch, I understood that my supposedly good PRNG leaked state like a sieve, and I had neglected to include authentication.  I then went and learned c++ because QB was ill-suited to providing an efficient implementation.  In my first post, I provide a link to the latest version of my encryption program/source.  I don't claim that it is the bomb...however, I've dealt with each issue as I have come to understand it.  It deals with many issues that weren't obvious to me until I had learned a bunch about the history of crypto.  I was just trying to help you bypass some pitfalls that *I* made as I became interested in cryptography.  Cheers, and keep talking...it'll make whatever you develop more secure...which is the goal, after-all.  You should avoid getting your ego involved.  Ego and crypto don't mix...ego will lead to blindness...and weak crypto...good luck. Title: Data Encryption Post by: na_th_an on May 29, 2004, 08:17:35 PM Yeah.Mathematicians have been ages developing secure crypto systems. A simple XOR system will always be easily beaten by a dictionary attack, you can do what you want, that it is true.If you want a good cryptosystem, google for RSA. Title: Data Encryption Post by: KiZ on May 29, 2004, 09:20:16 PM Quote from: "Mango"Cheers, and keep talking...it'll make whatever you develop more secure...which is the goal, after-all.  You should avoid getting your ego involved.  Ego and crypto don't mix...ego will lead to blindness...and weak crypto...good luck.Ego? Who ever said anything about my Ego? What has that got to do with it? Please, you are mistaken if you thought that I thought my crypto function was "Great" and "really secure".  I doubt that it stands up at all compared to modern crypto routines. Im just pleased with it, seeing as I dont even understand how proper ones work, and I have never studied them. Title: Data Encryption Post by: Mango on May 29, 2004, 09:28:48 PM Quote from: "dark_prevail"Quote from: "Mango"Cheers, and keep talking...it'll make whatever you develop more secure...which is the goal, after-all.  You should avoid getting your ego involved.  Ego and crypto don't mix...ego will lead to blindness...and weak crypto...good luck.Ego? Who ever said anything about my Ego? What has that got to do with it? Please, you are mistaken if you thought that I thought my crypto function was "Great" and "really secure".  I doubt that it stands up at all compared to modern crypto routines. Im just pleased with it, seeing as I dont even understand how proper ones work, and I have never studied them.I was just suggesting that defending what appear to me as obvious holes in your admittedly naive idea is, perhaps, counterproductive.  I never intended to, nor did I, in my eyes, insult or attack your ideas or work.  I was *attempting* to offer constructive criticism, although you will not be the first to be offended by such attempts.   Cheers, and good luck.  Cheers, and keep us informed about your progress. Title: Data Encryption Post by: KiZ on May 31, 2004, 11:51:15 AM Fair enough. I have major loopholes in my code, in certain ways, and I see now that it really doesnt stand up.   I made a program that can figure out the password using a piece of encrypted text, and the same, but non-encrypted text. I give up on this encryption thing =P Maybe when Im older and I have learnt more about crypto techniques.  :) Title: Re: Data Encryption Post by: Nemesis on July 30, 2004, 12:54:44 AM Quote from: "ca336458"I have been sitting here pondering what the best encryption algorithm might be. I am talking about an algorithm that is nearly impossible to decrypt. Anybody have any really good algorithms?[/code]Yes, I do...It's called Password Seeded Bit Encryption or P_S_B_Eit's practically impossible to decrypt without the password that encrypted it. (Works on any type of file :)Check it out, and tell me what you think...'''' P_S_B_E (Password_Seeded_Bit_Encryption), version 1.1'' (C)opyright 2004, Pure QB Innovations''' Email any questions, comments, or beta results to...'  ESmemberNEMESIS@aol.com'' Visit the Pure QB Innovations web site at...'  http://members.aol.com/esmembernemesis/index.htm'' THIS PROGRAM MAY BE DISTRIBUTED FREELY AS PUBLIC DOMAIN SOFTWARE' AS LONG AS ANY PART OF THIS FILE IS NOT ALTERED IN ANY WAY.' IF YOU DO WISH TO USE THESE ROUTINES IN YOUR OWN PROGRAMS' THEN PLEASE GIVE CREDIT TO THE AUTHOR... Mario LaRosa.'''''ON ERROR GOTO Event'DEFINT A-Z'SCREEN 0: WIDTH 80'GOSUB TitleGOSUB MenuGOSUB FileGOSUB PassGOSUB PlantGOSUB AlgorithmGOSUB Status'RUN'Title: CLS COLOR 8: LOCATE 25, 1: PRINT "( )opyright 2004,"; COLOR 7: LOCATE 25, 2: PRINT "C"; COLOR 4: LOCATE 25, 19: PRINT "Pure"; COLOR 2: LOCATE 25, 24: PRINT "QB"; COLOR 1: LOCATE 25, 27: PRINT "Innovations"; COLOR 8: LOCATE 1, 25: PRINT "Password_Seeded_Bit_Encryption" COLOR 7: LOCATE 1, 25: PRINT "P" LOCATE 1, 34: PRINT "S" LOCATE 1, 41: PRINT "B" LOCATE 1, 45: PRINT "E" RETURN'Menu: COLOR 8 PRINT : PRINT : PRINT PRINT "Please choose an option..." PRINT PRINT " ["; : COLOR 7: PRINT "D"; : COLOR 8: PRINT "]ecrypt file" PRINT " ["; : COLOR 7: PRINT "E"; : COLOR 8: PRINT "]ncrypt file" PRINT " ["; : COLOR 7: PRINT "Q"; : COLOR 8: PRINT "]uit PSBE" DO  K\$ = INKEY\$  SELECT CASE UCASE\$(K\$)   CASE "E"    Choice\$ = "encrypt"    EXIT DO   CASE "D"    Choice\$ = "decrypt"    EXIT DO   CASE "Q"    COLOR 7    SYSTEM  END SELECT LOOP RETURN'File: GOSUB Title COLOR 8 PRINT : PRINT : PRINT "Enter the name (including the source path)," PRINT "of the file you wish to "; Choice\$; "..." COLOR 7: PRINT : LINE INPUT " "; File\$ FileNum = FREEFILE OPEN File\$ FOR BINARY AS FileNum LenFile& = LOF(FileNum) IF LenFile& = 0 THEN CLOSE FileNum: KILL File\$: ERROR 53 RETURN'Pass: COLOR 8 PRINT : PRINT "Enter password to "; Choice\$; " this file..." COLOR 7 PRINT : LINE INPUT " "; Password\$ LenPassword = LEN(Password\$) IF LenPassword < 1 THEN  COLOR 4  PRINT : PRINT "Password not legal."  SLEEP 2  RUN END IF RETURN'Plant: seed& = &H8000 RANDOMIZE LenPassword FOR x = 1 TO LenPassword  r = INT(RND(1) * LenPassword + 1)  seed& = seed& + ASC(MID\$(Password\$, r, 1)) + (&H100 * (x - 1)) NEXT RANDOMIZE seed& RETURN'Algorithm: COLOR 4: PRINT : PRINT "Are you sure?" COLOR 8: PRINT : PRINT " [ ]o or [ ]es"; COLOR 15: LOCATE 15, 3: PRINT "N" LOCATE 15, 11: PRINT "Y" DO  K\$ = INKEY\$  SELECT CASE UCASE\$(K\$)   CASE "Y"    COLOR 2: PRINT : PRINT "..."; Choice\$; "ing..."    EXIT DO   CASE "N"    RUN  END SELECT LOOP DIM b AS STRING * 1 SELECT CASE Choice\$  CASE "encrypt"   FOR i& = 1 TO LenFile&    GET FileNum, i&, b    r = INT(RND(1) * LenPassword + 1)    f = ASC(MID\$(Password\$, r, 1))    s = ASC(b)    n = (f + s) AND 255    b = CHR\$(n)    PUT FileNum, i&, b   NEXT  CASE "decrypt"   FOR i& = 1 TO LenFile&    GET FileNum, i&, b    r = INT(RND(1) * LenPassword + 1)    f = ASC(MID\$(Password\$, r, 1))    s = ASC(b)    n = (s - f) AND 255    b = CHR\$(n)    PUT FileNum, i&, b   NEXT END SELECT CLOSE FileNum RETURN'Status: COLOR 7 PRINT : PRINT "File has been "; Choice\$; "ed." SLEEP 2 RETURN'Event: COLOR 4: PRINT : PRINT "File not found." SLEEP 2 RUN ' Title: Data Encryption Post by: Nemesis on August 16, 2004, 04:35:36 AM Hey everyone, I've noticed nobody had any comments on my encryption program, but I figured not to many of you are intrestedin this subject. For those that are, you'll notice this program is very secure, it's the most secure I've seen (for QBASIC) on the net. I wrote this algorithm a while back as a challenge because a few programmers on an, AOL QB programming board, said I couldn't code an encryption routine and reveal the source code that they couldn't crack. Well they admitted their current machines couldn'tcrack the encryption within their lifespans. (We all later became good friends).Then last year I took that encryption algorithm and made P_S_B_E. The encryption is very secure because of a few things I'll point out.First of all it's based on a random password that the user supplies,it can be a short password, like 6 characters, or it can be a long onelike say 32 characters or even more. Since a hacker doesn't know the password, he won't know the length of the password either.After a user enters his random password the program seeds the pseudo-random numbers with the length of the password and again with random bytes from the password...Code:seed& = &H8000RANDOMIZE LenPasswordFOR x = 1 TO LenPasswordr = INT(RND(1) * LenPassword + 1)seed& = seed& + ASC(MID\$(Password\$, r, 1)) + (&H100 * (x - 1))NEXTRANDOMIZE seed&Now there's no telling where the randomizers seed will startbecause first you don't know the length of the password,and second, two passwords of the same length can have the same seed too, or even totally different seeds!After the program seeds the randomizer, then it encrypts the selected file, byte X byte with random bytes from the password and adds them, rolling over any overflows.The program simply uses revers logic when decrypting files.Code:DIM b AS STRING * 1SELECT CASE Choice\$CASE "encrypt"FOR i& = 1 TO LenFile&GET FileNum, i&, br = INT(RND(1) * LenPassword + 1)f = ASC(MID\$(Password\$, r, 1))s = ASC(b)n = (f + s) AND 255b = CHR\$(n)PUT FileNum, i&, bNEXTCASE "decrypt"FOR i& = 1 TO LenFile&GET FileNum, i&, br = INT(RND(1) * LenPassword + 1)f = ASC(MID\$(Password\$, r, 1))s = ASC(b)n = (s - f) AND 255b = CHR\$(n)PUT FileNum, i&, bNEXTEND SELECTCLOSE FileNumThat's basically the scheme for my encryption routine,very secure even with the source available!One thing that sucks with this program is it's kinda slow since it reads/writes bytexbyte, I'll be working on another version soon that'll change the sluggishness by writing/reading 16 or 32 bytes at a time instead, and I'll maybe add a decent GUI too!Cya!P.S...I went ahead and uploaded P_S_B_E at Pete's QB site...http://www.petesqbsite.com/downloads/misc.shtmlyou can grab a copy there and post a review if you wish.THANX Title: Data Encryption Post by: Z!re on August 16, 2004, 05:33:10 AM Any encryption can be beaten, either directly, or by using good ol' research, even talking to an amployee can give you a password. Then it no longer matters what encryption is used.My old routine, not unbeatable, but extremely hard to crack:(Note it generates a 1/1 encryption (plsu one extra byte) so chars < 31 may turn out and mess up the printed strings  :P )Code:DEFINT A-Z '\$DYNAMIC DECLARE FUNCTION Decode\$ (in\$, pass\$) DECLARE FUNCTION Encode\$ (in\$, pass\$) RANDOMIZE TIMER CLS 'note same string and password in all 3 cases Coded\$ = Encode\$("Hello, World Hello, World", "password here") PRINT Coded\$ PRINT Decode\$(Coded\$, "password here") 'note same string and password in all 3 cases Coded\$ = Encode\$("Hello, World Hello, World", "password here") PRINT Coded\$ PRINT Decode\$(Coded\$, "password here") 'note same string and password in all 3 cases Coded\$ = Encode\$("Hello, World Hello, World", "password here") PRINT Coded\$ PRINT Decode\$(Coded\$, "password here") FUNCTION Decode\$ (in\$, pass\$) oin\$ = in\$ IF LEN(in\$) < 2 THEN EXIT FUNCTION t! = LEN(in\$) / 2 m = INT(LEN(in\$) / 2) IF m = t! THEN  d1\$ = LEFT\$(in\$, m - 1)  d2\$ = RIGHT\$(in\$, m)  m\$ = MID\$(in\$, m, 1) ELSE  d1\$ = LEFT\$(in\$, m)  d2\$ = RIGHT\$(in\$, m)  m\$ = MID\$(in\$, m + 1, 1) END IF in\$ = d1\$ + d2\$ g = ASC(m\$) FOR a = 1 TO LEN(in\$)  pl = pl + 1  IF pl > LEN(pass\$) THEN pl = 1: q = q + 1  b = ASC(MID\$(in\$, a, 1))  IF g > 127 THEN   c = ASC(MID\$(pass\$, LEN(pass\$) - (pl - 1), 1))  ELSE   c = ASC(MID\$(pass\$, pl, 1))  END IF  bc = b - c - g - a - pl - q  DO   IF bc < 0 THEN bc = bc + 255  LOOP WHILE bc < 0  d\$ = d\$ + CHR\$(bc) NEXT Decode\$ = d\$ in\$ = oin\$ END FUNCTION FUNCTION Encode\$ (in\$, pass\$) g = (255 * RND + 255 * RND) * RND IF g > 255 THEN g = g - 255 FOR a = 1 TO LEN(in\$)  pl = pl + 1  IF pl > LEN(pass\$) THEN pl = 1: q = q + 1  b = ASC(MID\$(in\$, a, 1))  IF g > 127 THEN   c = ASC(MID\$(pass\$, LEN(pass\$) - (pl - 1), 1))  ELSE   c = ASC(MID\$(pass\$, pl, 1))  END IF  bc = b + c + g + a + pl + q  DO   IF bc > 255 THEN bc = bc - 255  LOOP WHILE bc > 255  c\$ = CHR\$(VAL("&H" + HEX\$(bc)))  d\$ = d\$ + c\$ NEXT g\$ = CHR\$(VAL("&H" + HEX\$(g))) t! = LEN(d\$) / 2 m = INT(LEN(d\$) / 2) IF m = t! THEN  p1\$ = LEFT\$(d\$, m)  p2\$ = RIGHT\$(d\$, m)  d\$ = p1\$ + g\$ + p2\$ ELSE  p1\$ = LEFT\$(d\$, m)  p2\$ = RIGHT\$(d\$, m + 1)  d\$ = p1\$ + g\$ + p2\$ END IF Encode\$ = d\$ END FUNCTION Title: Data Encryption Post by: Mac on August 23, 2004, 05:12:27 AM OK, nemisis, I will comment on your codeHeh! I suspect the only acceptable comment is simply "Wow! That is certainly secure and engenious" and any lengthy analysis is boring and to be ignored. But anyway, here goes....You used:  r = INT(RND(1) * LenPassword + 1)   f = ASC(MID\$(Password\$, r, 1)) to get then encryption/decryption displacement.The code normally used is  f = INT(RND(1) * 256)If you run the program at the end of this reply, you will see that in an example, f only has the following values:32, 66, 83, 97, 99, 100, 101, 104, 110, and 121whereas in the normal method, f has values from 0 to 255.If I had a cryptogram produced by your program, I would have a head start knowing that I don't have all 255 displacements to worry about. Even though I don't know how many, I know that it is probably less than 33. Maybe even 6 or 7!Let's assume an encrypted English text. Then I would take the first character of the cryptogram and compute what values of displacements would yield a-z,A-Z,0-9,and punctuation. Continue for all other characters. Using this, I could quickly determine the list, especially since the displacements are known to be ASC values of characters typically used to create passwords.This technique does not apply to the conventional method as it would simply yield the result that the list is 0 through 255.So anyway, assuming the password used below, the list would be found. It would be seen that 97 was used twice as much, so the list is really32, 66, 83, 97, 97, 99, 100, 101, 104, 110, and 121In other words, every character is encrypted using one of those numbers, even though we still don't know which one.I won't continue, but it is no great challenge to decrypt using all those hints.I recommend changing to the normal method or, even better, to a version of RND better suited to encryption.The QBasic Forum has a subforum, "QBasic programs you are proud of".http://www.network54.com/Forum/178387I have posted there under "Mac" an elaborate encryption program (SuperC) and then noted a problem: "Security weakness uncovered".Finally, I posted "On the trail to the solution of the security weakness", including a subroutine, CRND, which provides a long enough series.You are welcome to use it.Mac'================================CLSDIM Used(255) AS INTEGER ' Used(f)=How many times f was used.PRINT "---------------------- Method you chose"y = RND(-2345)Password\$ = "Sandy Beach"LenPassword = LEN(Password\$)FOR i = 1 TO 5000  r = INT(RND(1) * LenPassword + 1)  f = ASC(MID\$(Password\$, r, 1))  Used(f) = Used(f) + 1NEXT iFOR i = 0 TO 255  IF Used(i) > 0 THEN PRINT i, Used(i): Used(i) = 0  NEXT i: PRINTPRINT "--------------------- Method normally used"y = RND(-2345)FOR i = 1 TO 5000  f = INT(RND(1) * 256)  Used(f) = Used(f) + 1NEXT iFOR i = 0 TO 55: PRINT Used(i); " "; : NEXT i: PRINTFOR i = 200 TO 255: PRINT Used(i); " "; : NEXT i: PRINTSYSTEM Title: Data Encryption Post by: Nemesis on August 27, 2004, 01:42:36 PM QuoteYou used:   r = INT(RND(1) * LenPassword + 1)   f = ASC(MID\$(Password\$, r, 1)) to get then encryption/decryption displacement. The code normally used is   f = INT(RND(1) * 256) There's a few things I think you over looked.Using int(RND(1)*256) leaves a big hole in security becausethat would follow a pattern in QB's pseudo-random # list.Just loking through the source would reveal that you are in fact generating a 256 random number, which wouldn't really be so random after all. Now, using random numbers based off the password is much more random because the password is random itself. Also the password isn't limited to typical characters.Your password can be, say 100+ characters long with odd characters like... _É¢ª¦Åô¼, so you are in fact able to use all 256 displacements if you think about it  :) Cya. Title: Data Encryption Post by: anarky on April 19, 2005, 01:45:36 PM QuoteA good decryption algorithm MUST have a password or random numbers to be good. And if they have both then it's even better. What about swapping the bits of all the data in the file? I mean using a password and then from that password, perform some swapping of the bits of all the data. Or even better, invent your own language, then use an encryption on it! Nobody will be able to decrypt something in a different language. Something like aliens sending us a message, we would never know what the message is. Well, WE wouldn't, but the government and military would know in time. That's how mine is designed to work, amongst password encoding etc.Here are the steps (I actually made it for an archiving utility):1. Pack all files into one unencoded file2. Prompt for password 8 chars or more3. Generate sequence number from that password4. Alternately raise and lower character values for each digit of the string, increasing in length per segment for each generated number placement IE: #1234 1byte raise 1 character (a=b), 2bytes lower (df=bd), etc5. Run twice over code, after performing a test decryption to verify (I still have trouble with this method as sometimes it leaves a decrypted file corrupt)6. Using same number, store decryption algorithm digits sperately at certain points of the ALREADY ENCRYPTED file7. Pass file through a level three encryption based on that number8. Close fileDecrypting is the reverse:1. Prompt for password2. Generate number using same algorithm (secretly embedded in the program3. Using number, pass file through level three security clearance4. At preset points in file, gather numbers to build decryption code5. Verify if entered and stored numbers match. If so, password is correct, continue decryption6. Pass through decryption in the reverse stated above, file should be decrypted completelyIn the unpacking process, this is built into the setup engine. After decryption (and uncompression (still dodgy)) files are unpacked to seperate files and checked against a file table built into the setup program. If there is a mismatch, the password is still incorrect. If all is ok, then you have success.Hope that's not too complex for you. The fact that mine is compressed also makes it doubly difficult to hack. Who's going to know it's compressed. Do you want the algorithm for my compression routine? HAHAHAA!!! Forget it!>anarky - secretive as always.