Jump to content
  • Advertisement
Sign in to follow this  
u235

encryption

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

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
Advertisement
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 this post


Link to post
Share on other sites
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?

Share this post


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

Share this post


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

-AJ

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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.

Share this post


Link to post
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 this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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_H

typedef 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 are
filled with the final offsets. This means you can store the offsets so
that data being stored/transferred/etc. in pieces doesn't start from the
first key all the time. This results in improved security through
transmissions, and files being encoded don't need extra data stored to
ensure 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 this post


Link to post
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 this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!