encryption

This topic is 4379 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

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

Share on other sites
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.

Share on other sites
Quote:
 Original post by SneftelIt'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?

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

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

-AJ

Share on other sites
Quote:
 Original post by u235Thanks 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.

Share on other sites
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.

Share on other sites
Quote:
 Original post by GoraxIt'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).

Share on other sites
Quote:
 Original post by ExtrariusIt 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.

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

Share on other sites
'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?

Share on other sites
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.

Share on other sites
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').

Share on other sites
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.

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

Share on other sites
Quote:
 Original post by u235I 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.

Share on other sites
Quote:
 Original post by GoraxIt 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?).

It has some flaws...? Oh really.... well, the complete lack of a security track record seems like a major flaw, which makes your algorithm completely useless for any purpose what so ever. Wanna launch a new crypto algorithm? The first thing you should have ready is some experiments that demonstrate that your algorithm is not vulnerable to common cryptanalysis attacks. "Cryptography is easy" my ass.

Share on other sites
Quote:
 Original post by Will FYou 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

Share on other sites
Quote:
 Original post by u235Is there something unique about 128 that makes it better than anything else?

No, It's just that 128 is enough not to be crackable. That's it. Sure, you could use larger keys - but what would you gain?

Share on other sites
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.

Share on other sites
Oh ok, cool. Thanks for the explanation.

-AJ

Share on other sites
Quote:
Original post by u235
Quote:
 Original post by Will FYou 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).

Share on other sites

This topic is 4379 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.