Definition of X-bit encryption

[CryoEnix]

Hey guys, I'm curious as to what encryption programs mean when they say they use '512 bit encryption'/'256 bit encryption'. Are they just meaning the size of the encryption key*8?

 

If so, then surely the 'x-bit encryption' level is just dependent on the size of the key? Somebody please elaborate on this.

Edited January 25, 2005 by CryoEnix

[mhildner]

x-bit just means that x is the size of the key. So 128 bit encryption uses a key that's 128 bits.

[CryoEnix]

x-bit just means that x is the size of the key. So 128 bit encryption uses a key that's 128 bits.

 

Hmm, so programs that boast 512 bit encryption just have a key 64 characters long - interesting, as that would make my encryption program 50678051688 bits in power.... I take it that's good, then?

[thenerd]

You can even HAVE a variable 6.3 billion characters long?

 

And there's probably more to it than that, but I don't know what I'm talking about.

[CryoEnix]

You can even HAVE a variable 6.3 billion characters long?

 

And there's probably more to it than that, but I don't know what I'm talking about.

 

Yes, but not in one string. If you tried then VB would kick and scream like a kid with ADD. By using several different keys set at different lengths, the lowest common denominator for the key(s) length equals 50678051688 bits, or 6,334,756,461 bytes in length. Thus, this would effectively be the length of the overall key.

[thenerd]

I mean, how would you run this program, something that's 6.3 billion bytes is 6.3 gigabytes. That's a lot of memory.

[CryoEnix]

I mean' date=' how would you run this program, something that's 6.3 billion bytes is 6.3 gigabytes. That's a lot of memory.[/quote']

 

Sorry, I might not have explained correctly. The encryption algorithm uses three different keys of different lengths, so in essence it should only take about 96 KB of memory at the most (assuming that all strings take up 32,767 bytes of RAM). These three keys work together on the particular piece of data to encrypt/decrypt it, and due to the fact that the lowest common denominator for the length of the keys works out at a 'virtual' key of 6.3 billion characters. It just isn't stored in the memory in a conventional sense.

 

Think of a files hash code. It's unique for every file, yet it's tiny compared to the actual file in question. (I think this analogy is appropriate, at least...)

Edited January 30, 2005 by CryoEnix

[IngisKahn]

You are aware that .NET has a very powerful encryption library with all the industry standard methods, right?

[CryoEnix]

You are aware that .NET has a very powerful encryption library with all the industry standard methods' date=' right?[/quote']

 

To be honest, I wasn't. But I needed to make my algorithm uniqe, so this is how I did it. The actual algorithm is coded in Java for speed, I just posted here because it's the only decent programming forum I know :)

[PlausiblyDamp]

When it comes to encryption unique is not always best - tried and tested routines are often far more secure than self-coded solutions. Also there is probably no real speed advantage in using Java over .Net.

 

http://sunsite.nstu.nsk.su/sunworldonline/swol-03-1997/swol-03-encrypt.html gives a good overview of terminology including key lengths.