Let's have an encryption CHALLENGE! - Printable Version +- Qbasicnews.com (http://qbasicnews.com/newforum) +-- Forum: QbasicNews.Com (http://qbasicnews.com/newforum/forum-3.html) +--- Forum: Challenges (http://qbasicnews.com/newforum/forum-10.html) +--- Thread: Let's have an encryption CHALLENGE! (/thread-1160.html) |
Let's have an encryption CHALLENGE! - oracle - 06-12-2003 Go on then... break mine. Let's have an encryption CHALLENGE! - Agamemnus - 06-12-2003 Those zeros really give it away....... or not.... Sigh.. I just looked at the key length. It's very long, so I'll need a much larger text to decrypt...... key update - Mango - 06-12-2003 Quote:Mango: I have been thinking of using CA (2D, though) to encrypt files. Using a key to generate another, larger key and then adding it into the plaintext is possibly unbeatable. Agamemnus...I'm assuming "The key is updated as it is used" came from the readme file? Basically, my key is a subset of the final state of the "rule 30" 1-D CA, seeded with the password. In V 3.11, I constructed it so that the key would be variable length, but in the 500-1000 bit range. Therefore, if a file longer than 1000 bits is being encrypted, the key must either repeate (generally a no no) or be updated at each iteration. As I wrote 3.11, the key is updated using a modification of the rule 30 automata used to generate the key from the password. This turns out to be a problem, *IF* an attacker has partial knowledge about the contents of an encrypted file...it is of no help if the attacker is in the dark, but helps him if he is already partially in...I've changed my key update method in the current iteration. RE: 1d vs 2d CA....read Wolfram's book...it really doesn't buy you anything to use a 2d...once the threshhold of complexity that will produce "intractiblly random-appearing behavior" is reached, it doesn't buy you *anything* to try to make it *more random appearing*. In fact, you actually run the risk of deluding yourself...if you use a CA of higher dimmensionallity you may end up with a repeating pattern that you don't reccognize...Make sure whatever 2d CA you use is non-reversable, and produces non-nesting patterns... I've actually studied and learned a BUNCH in the last 6-mos on this topic...if you want to discuss what you are doing, or details of my scheme, e-mail me and I'll gladly respond... did you try my program??? did it work? I hope so...it gives great pleasure to find out that someone else was actually able to successfully run your code... ;-) It should produce random-looking data irregardless of the regularity of the input data-stream or the password chosen...In fact, I submit that the output of *any* file encoded using jcrypt 3.1 with *any* password is a better PRNG (pseudo random number generator) than the RND function in QB 4.5!!! Cheers...I hope I answered your Q regarding key update... Let's have an encryption CHALLENGE! - oracle - 06-12-2003 I only added the zeroes for... wait, why did I? Just so it would take me 5 minutes to break if I knew the key. If you want, remove the zeroes and lose the +9999, for a real challenge, go ahead. And if I was really serious, the key would be 15000+-5000 characters long... :wink: Let's have an encryption CHALLENGE! - Agamemnus - 06-12-2003 mango: I read about 70% of Wolfram's book.. got me started on 2D. I just wasn't thinking along the lines with 1D at the time. Sounded really boring. I was infatuated with my 2D map maker program: takes a "random" seed and makes islands from it.. ------------------------------- But I'm still lost, though: "Therefore, if a file longer than 1000 bits is being encrypted, the key must either repeate (generally a no no) or be updated at each iteration." So you make the key longer. Is that correct? -------------------------------- One more question: Do you actually update every single bit and expand by two bits each time? Or do you just keep adding the previous step, which would make it A LOT faster? (and still random most likely..) My prog - Meg - 06-12-2003 I don't know anything about encryption, but I think this is a pretty cool challenge. I wrote this code on a whim; I don't expect it to earn me any points, but it is kinda fun watching the text string turn to garbage and then back! Code: tt = 1000 *peace* Meg. Let's have an encryption CHALLENGE! - Mango - 06-12-2003 Quote:mango: no...what I did in v3.1 is to take the key and xor the file against it. When I ran out of key, I would stop encrypting, and update the key, so that it would never repete. The key update scheme involved "stepping an automata" seeded with the key on a (32-bit)word-by-word basis...I did this for speed...turns out that this is not a good method, because if someone has partial info about the file (eg they guessed it was a word doc and knew the header structure) *and* if they correctly guessed the key length, then they would be able to unencrypt portions of the rest of the file that fell under the part of the original key (and it's updated versions) that the attacker knew. Quote:One more question: Do you actually update every single bit and expand by two bits each time? Or do you just keep adding the previous step, which would make it A LOT faster? (and still random most likely..) yes-I updated every bit and discarded all previous info. It would be unsafe to simply add the update to the previous key...then...if an attacker knew the contents of the first little bit of the encrypted file, he could easily get the whole key...this is the basic problem with my key-update scheme. However, its not so bad since the key is pretty long...basically, you dont want an attacker's knowledge of part of the key to allow him to calculate the rest (or part of the rest) of the key...and summing the lines of the automata would allow just that... it only takes a second or so to generate the 1000 bit key...and that is using my slow method...my current method that works in parrallel is circa 25 times faster....it's really not a problem. Try encrypting a big file (like a 1 MB jpg) with an 8-10 character password...it should take less than 10 seconds to do the encryption. cheers Let's have an encryption CHALLENGE! - HystericPoison - 06-15-2003 im about the same as Meg, i know nothing about encryption, but this baby program i wrote was fun for me to do. my program will take the text ( or file ) that you enter and change each character to its ascii value. i know a real attack could take it without even thinking, but nobody in my house knows anything about anything. Code: DECLARE SUB Encrypt (outputmethod%, text$, outfile$) Let's have an encryption CHALLENGE! - Agamemnus - 06-15-2003 heh... ok Reply to HistericPoison re encryption code - Moneo - 06-15-2003 Just a tip to eliminate unnecessary conditional (if's) code. Instead of: IF (LEN(newcode$) <= 2) THEN encrypted$ = encrypted$ + "0" + newcode$ ELSE encrypted$ = encrypted$ + newcode$ END IF Do this instead (asumming you always want to append a three character ASCII code: encrypted$ = encrypted$ + right$(("000" + newcode$) ,3) Get it? ***** |