encryption
Author
I was reading up on encryption algorithims and came across something that said 128-bit encryption is the best because with 128-bit you can't decode it simply by trying every key. First I would like to ask if this is true. Second I would like to ask, if this is true, why is true. I mean as opposed to other key bit lengths, why 128-bit tougher to decipher than others? Thanks.
-AJ
It's only true in that trying every key would take you a long time. The only cryptosystem which is not susceptible to brute force key search is the One-Time-Pad system.
Quote:Original post by Sneftel
It's only true in that trying every key would take you a long time. The only cryptosystem which is not susceptible to brute force key search is the One-Time-Pad system.
I think I read about that in some books by Tom Clancy, the Jack Ryan books, right?
You basically have a radio antenna that picks up just random universe signals, and then print out a huge book and use that you encode a message. The way that it is decoded is the reciever has a copy of the book right?
Pretty much. The "random universe signals" can be any source of sufficiently random data. Lava lamps have been used.
Author
Thanks for the clarification. I kind of had a feeling it wasn't truly hacker proof. Thanks again.
-AJ
-AJ
Quote:Original post by u235
Thanks for the clarification. I kind of had a feeling it wasn't truly hacker proof. Thanks again.
-AJ
It's hacker proof enough, in the way that nobody as of today can break the best 128 bit ciphers.
It's not that hard to implement your own encryption that doesn't limit it to 128 bits. I've done it, and I've added variable bit rotation too, so it makes it a little harder to crack again. I can post the code if anybody wants to take a look at it (it's all good and fun if you don't care how it works, and just want to use it, 'cause it lacks commenting (like most of my stuff)). In any case, regardless of the encryption you use, it's crackable, but the better it is, the longer it'll take to crack.
Quote:Original post by GoraxYes, it is. It is very difficult to properly implement any encryption algorithm, and it is a hundred times more difficult to create your own encryption algorithm that is secure in any sense.
It's not that hard to implement your own encryption that doesn't limit it to 128 bits.[...]
Unless you can list all the cryptographic properties of your algorithm, you don't know enough about cryptography to have designed a decent system. Even if you could (or can), there is still a good chance your algorithm isn't any good because you (probably) haven't had experts extensivly review your algorithm like the widely used algorithms have.
There are already quality algorithms that accept keys longer than 128 bits (256 is common), so making up your own is not only pointless, but also counter-productive (unless you happen to be a cryptography expert and don't need to actually use the algorithm for a few years).
Quote:Original post by Extrarius
It is very difficult to properly implement any encryption algorithm ...
It all depends on exactly how far you want to go with it. Mine's fairly simple, but also fairly effective.
Quote:
Unless you can list all the cryptographic properties of your algorithm ...
I can't name them because I only did it for something to do while I was bored, rather than actually studying cryptography to learn how to do it.
Quote:
There are already quality algorithms that accept keys longer than 128 bits (256 is common), so making up your own is not only pointless, but also counter-productive ...
It took me longer to find out how to rotate bits in assembly than it did to write the entire thing. Sure it's pointless, but it's not exactly counter-productive.
Rather than try and explain it, I'll post the code.
Header:
#ifndef _ENDECODE_H#define _ENDECODE_Htypedef unsigned int EndeKey;typedef struct { //number of bits to shift the current 32-bits by unsigned char shift; //shift before encrypted if 1, shift after if 0 //NOTE: shiftBefore is USELESS if it's not used with a key unsigned char shiftBefore;}EndeShift;/*NOTE:The starting value pointers are NOT required. If they are used, they arefilled with the final offsets. This means you can store the offsets sothat data being stored/transferred/etc. in pieces doesn't start from thefirst key all the time. This results in improved security throughtransmissions, and files being encoded don't need extra data stored toensure the proper keys are used.*/extern void endecodeData( unsigned char encoding,unsigned char* buffer,unsigned int len, EndeKey* keys,unsigned int numKeys,unsigned int* startKey, EndeShift* shifts,unsigned int numShifts,unsigned int* startShift);#endifSource:
#include "EnDecode.h"#define ROR32(value,bits) asm ( "rorl %b1, %0" : "=r" (value) : "c" (bits), "0" (value) )#define ROL32(value,bits) asm ( "roll %b1, %0" : "=r" (value) : "c" (bits), "0" (value) )void endecodeData( unsigned char encoding,unsigned char* buffer,unsigned int len, EndeKey* keys,unsigned int numKeys,unsigned int* startKey, EndeShift* shifts,unsigned int numShifts,unsigned int* startShift){ if (!(buffer && len)) return; unsigned int* ptr = (unsigned int*)buffer; //start from the starting points if we can unsigned int k = startKey ? *startKey : 0; unsigned int s = startShift ? *startShift : 0; //always +4, since we don't want to start playing with data we don't own unsigned int i = 4; if (encoding){ if (keys && numKeys){ if (shifts && numShifts){ while (i <= len){ if (shifts.shiftBefore){<br> ROR32(*ptr,shifts.shift);<br> *ptr ^= keys[k];<br> }<span class="cpp-keyword">else</span>{<br> *ptr ^= keys[k];<br> ROR32(*ptr,shifts.shift);<br> }<br> ptr = &ptr[<span class="cpp-number">1</span>];<br> k++;<br> <span class="cpp-keyword">if</span> (k == numKeys) k = <span class="cpp-number">0</span>;<br> s++;<br> <span class="cpp-keyword">if</span> (s == numShifts) s = <span class="cpp-number">0</span>;<br> i += <span class="cpp-number">4</span>;<br> }<br> }<span class="cpp-keyword">else</span>{<br> <span class="cpp-keyword">while</span> (i <= len){<br> *ptr ^= keys[k];<br> ptr = &ptr[<span class="cpp-number">1</span>];<br> k++;<br> <span class="cpp-keyword">if</span> (k == numKeys) k = <span class="cpp-number">0</span>;<br> i += <span class="cpp-number">4</span>;<br> }<br> }<br> }<span class="cpp-keyword">else</span> <span class="cpp-keyword">if</span> (shifts && numShifts){<br> <span class="cpp-keyword">while</span> (i <= len){<br> ROR32(*ptr,shifts.shift);<br> ptr = &ptr[<span class="cpp-number">1</span>];<br> s++;<br> <span class="cpp-keyword">if</span> (s == numShifts) s = <span class="cpp-number">0</span>;<br> i += <span class="cpp-number">4</span>;<br> }<br> }<br> }<span class="cpp-keyword">else</span>{<br> <span class="cpp-keyword">if</span> (keys && numKeys){<br> <span class="cpp-keyword">if</span> (shifts && numShifts){<br> <span class="cpp-keyword">while</span> (i <= len){<br> <span class="cpp-keyword">if</span> (shifts.shiftBefore){<br> *ptr ^= keys[k];<br> ROL32(*ptr,shifts.shift);<br> }<span class="cpp-keyword">else</span>{<br> ROL32(*ptr,shifts.shift);<br> *ptr ^= keys[k];<br> }<br> ptr = &ptr[<span class="cpp-number">1</span>];<br> k++;<br> <span class="cpp-keyword">if</span> (k == numKeys) k = <span class="cpp-number">0</span>;<br> s++;<br> <span class="cpp-keyword">if</span> (s == numShifts) s = <span class="cpp-number">0</span>;<br> i += <span class="cpp-number">4</span>;<br> }<br> }<span class="cpp-keyword">else</span>{<br> <span class="cpp-keyword">while</span> (i <= len){<br> *ptr ^= keys[k];<br> ptr = &ptr[<span class="cpp-number">1</span>];<br> k++;<br> <span class="cpp-keyword">if</span> (k == numKeys) k = <span class="cpp-number">0</span>;<br> i += <span class="cpp-number">4</span>;<br> }<br> }<br> }<span class="cpp-keyword">else</span> <span class="cpp-keyword">if</span> (shifts && numShifts){<br> <span class="cpp-keyword">while</span> (i <= len){<br> ROL32(*ptr,shifts.shift);<br> ptr = &ptr[<span class="cpp-number">1</span>];<br> s++;<br> <span class="cpp-keyword">if</span> (s == numShifts) s = <span class="cpp-number">0</span>;<br> i += <span class="cpp-number">4</span>;<br> }<br> }<br> }<br> <br> <span class="cpp-keyword">if</span> (startKey) *startKey = k;<br> <span class="cpp-keyword">if</span> (startShift) *startShift = s;<br>}<br><br>#undef ROR32<br>#undef ROL32<br><br></pre></div><!–ENDSCRIPT–><br><br>It's been written for speed, rather than something that'd run slower, but would be easier to read as code (which you can tell by the giant if/else blocks that are nearly identical). I found the bit rotation code on the net somewhere, since my knowledge of assembly is pathetic at best, but as long as it works, I don't really care.<br><br>It does have some flaws. For instance, I'm using an ints (32 bits) and chars (8 bits) instead of defining new types with the same sizes for different platforms. That and it can't encode or decode anything less than 32 bits (but then again, why in the hell would you want to encode anything less than 32 bits?).
'm thinking that people trying to crack encrypted files are not going to figure out how your encryption algorithm works. they're going to look for a 'black box' in your code that takes in an encrypted file, and spits out a decrypted file. then they will try to extract this code, and make it into a stand-alone app that decrypts your files. if so, then there are tactics one can do to make the job of extracting code more difficult. any validity to this notion?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
