🔒 Locked

encryption

Started by u235 Jan 20, 2006 at 1:42 AM 19 replies 1.8k views

Original Post

Jan 20, 2006 at 1:42 AM

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

Sneftel

296

Sneftel

Jan 20, 2006 at 1:54 AM

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.

Endar

139

Endar

Jan 20, 2006 at 2:01 AM

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?

Sneftel

296

Sneftel

Jan 20, 2006 at 2:03 AM

Pretty much. The "random universe signals" can be any source of sufficiently random data. Lava lamps have been used.

u235

Author

u235

Jan 20, 2006 at 3:44 AM

Thanks for the clarification. I kind of had a feeling it wasn't truly hacker proof. Thanks again.

-AJ

Gorax

Jan 20, 2006 at 10:20 AM

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.

Extrarius

234

Extrarius

Jan 20, 2006 at 10:54 AM

Quote:
Original post by Gorax
It's not that hard to implement your own encryption that doesn't limit it to 128 bits.[...]

Yes, 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.

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).

Gorax

Jan 20, 2006 at 11:30 AM

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);#endif

Source:

#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[s].shiftBefore){            ROR32(*ptr,shifts[s].shift);            *ptr ^= keys[k];          }else{            *ptr ^= keys[k];            ROR32(*ptr,shifts[s].shift);          }          ptr = &ptr[1];          k++;          if (k == numKeys) k = 0;          s++;          if (s == numShifts) s = 0;          i += 4;        }      }else{        while (i <= len){          *ptr ^= keys[k];          ptr = &ptr[1];          k++;          if (k == numKeys) k = 0;          i += 4;        }      }    }else if (shifts && numShifts){      while (i <= len){        ROR32(*ptr,shifts[s].shift);        ptr = &ptr[1];        s++;        if (s == numShifts) s = 0;        i += 4;      }    }  }else{    if (keys && numKeys){      if (shifts && numShifts){        while (i <= len){          if (shifts[s].shiftBefore){            *ptr ^= keys[k];            ROL32(*ptr,shifts[s].shift);          }else{            ROL32(*ptr,shifts[s].shift);            *ptr ^= keys[k];          }          ptr = &ptr[1];          k++;          if (k == numKeys) k = 0;          s++;          if (s == numShifts) s = 0;          i += 4;        }      }else{        while (i <= len){          *ptr ^= keys[k];          ptr = &ptr[1];          k++;          if (k == numKeys) k = 0;          i += 4;        }      }    }else if (shifts && numShifts){      while (i <= len){        ROL32(*ptr,shifts[s].shift);        ptr = &ptr[1];        s++;        if (s == numShifts) s = 0;        i += 4;      }    }  }    if (startKey)   *startKey   = k;  if (startShift) *startShift = s;}#undef ROR32#undef ROL32

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.

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?).

Scoob Droolins

Jan 20, 2006 at 1:12 PM

'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?

Extrarius

234

Extrarius

Jan 20, 2006 at 1:53 PM

Quote:
Original post by Scoob Droolins
'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?

No, they won't even bother extracting it, they'll just make a program that loads your program, sets up the right information (like putting a 'return' intruction at the end of the decrypt part if it doesn't have one, setting up the arguments to the function, etc), and jumps straight into your code.

Then later, the psuedo-encryption will be examined by somebody bored, and they'll write their own library that anybody can use to encrypt and decrypt using the right algorithm.

Extrarius

234

Extrarius

Jan 20, 2006 at 2:00 PM

Quote:
Original post by Gorax
[...]It all depends on exactly how far you want to go with it. Mine's fairly simple, but also fairly effective.
[...]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.[...]

So what you're saying is "I don't know anything about cryptography, but I made this great cryptographic algorithm!" ?

If you don't want much security, you can use a simple algorithm like the 'tiny encrypion algorithm'(TEA) that is something like 10 lines of very fast, freely available C code that uses 64 bit keys and works on 64 bits of data at a time.

If you want a decent amount of security, you need to use a well-known algorithm in the proper manner, which means you need to know what you're doing.

Neither option includes "make something up without knowing what you're doing." The only reason to do that is that you want to use something you fully understand without studying cryptography at all, but in that case the best option would be to just xor a psuedorandom number with each byte (starting with a seed that is the 'key').

_winterdyne_

Jan 20, 2006 at 2:26 PM

Hmm. The TEA variant I have has 128bit encryption by using two 64bit keys. TEA's a relatively trivial block cipher to implement, loads of good examples around the place.

If you're interested in encryption the things to start with are large integers and modulo arithmetic on them and (strong) pseudoprime generation (Rabin-Miller or Solovay-Strassen are easy enough to get your head round).

Writing your own classes to deal with these is a good learning experience - many people just say use Open SSL or some other crypto library, but if you don't need the code-bloat and are willing to do some head-scratching I'd vote roll your own.

Extrarius

234

Extrarius

Jan 20, 2006 at 2:32 PM

My mistake, I misremembered. TEA uses 128 bits of key material to encrypt 64 bits of data.

Will F

112

Will F

Jan 20, 2006 at 2:43 PM

Quote:
Original post by u235
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.

You can decode something encrypted in 128-bit by a brute force attack, but the time required to do so is measured in millions of years.

A more realistic expectation for having your data decrypted is someone breaking into your house, getting a copy of your secret key, and installing a key logger on your computer. See United States v. Scarfo for more info.

u235

Author

u235

Jan 20, 2006 at 3:30 PM

Quote:
Original post by Will F
You can decode something encrypted in 128-bit by a brute force attack, but the time required to do so is measured in millions of years.

Just so I am clear, this mean that there are (128!)*2 possible combinations for a 128-bit key? So for a n-bit key, the number of possible keys is (n!)*2? But if that were the case, why is 256-bit or even higher encryption not more popular. It seems every e-commerce website boasts about their 128-bit encryption. Is there something unique about 128 that makes it better than anything else?

-AJ

Extrarius

234

Extrarius

Jan 20, 2006 at 3:49 PM

Quote:
Original post by u235
[...]Just so I am clear, this mean that there are (128!)*2 possible combinations for a 128-bit key? So for a n-bit key, the number of possible keys is (n!)*2? But if that were the case, why is 256-bit or even higher encryption not more popular. It seems every e-commerce website boasts about their 128-bit encryption. Is there something unique about 128 that makes it better than anything else?[...]

No, it's a standard number system problem: Bits are base 2 'digits', so N bits can store 2^N (^ meaning 'raised to the power of') values, which for 128 bits comes out to a 38-digit number.

If a computer could test 2^32 keys per second (which I don't think a consumer PC could), it would take 2^96 seconds (32+96=128), which is a LONG time.

For comparison, a year is almost 2^25 seconds (quite a bit less actually, but 2^24.911... isn't as nice a number). That means that 2^96 seconds is 2^71 years, which is 2361183241434822606848 years.

u235

Author

u235

Jan 20, 2006 at 4:06 PM

Oh ok, cool. Thanks for the explanation.

-AJ

Zahlman

257

Zahlman

Jan 20, 2006 at 4:06 PM

Quote:
Original post by u235
Quote:
Original post by Will F
You can decode something encrypted in 128-bit by a brute force attack, but the time required to do so is measured in millions of years.

Just so I am clear, this mean that there are (128!)*2 possible combinations for a 128-bit key? So for a n-bit key, the number of possible keys is (n!)*2?

No, it is 2**n (exponentiation). This is easily seen by treating the key as a binary number and considering it analogously to decimal numbers. 2**128 is still very large, however (about 3.4 * 10**38).

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.