Question for Coders (Computers)

[Demagog]

How long would it take for a regular computer to go through 256! possible combinations in order to find an anagram? Every letter is used and there are no spaces in the original text. I'm making a cipher and I'm trying to decide if I should either leave it as is or add in junk text.

[Tabit]

When you say 256! combinations... Please clarify.
Is there 256! letters to de-scramble?

also... 256! is a HUGE   number. your talking....   ???  Massive. That's 256*255*254*...... *2*1  8)


  
Well, I can help you either way. Your answer determines the time by a HUGE factor.

[Tabit]

Ok, I'll solve Both situations... just, one situation will be more realistic.

Sorry for this long post ahead of time.

Ok, it really depends on what type of computer you consider normal. Mine is a 3Ghz processor x2 (Dual core); so, effectively, it is 6Ghz of processing power.

And when I mean power I mean SPEED. Each line of code in a program takes roughly 2-5 cycles to process the code segment. This is for Assembly language. An anagram decoder takes about 50 lines of code give or take. it is a rough estimate based off researching internet. This is for a Java code. Which is a higher level language but works the same.
Lets assume it to be 50 lines with 4 cycles each for the line. Also, there are loops in the code which a particular part is repeated over and over with a few lines. Lets assume this repetition is about 10 lines of code (this is where the 256! or the 256 makes a BIG difference in time.). 

Now when I talk about cycles, I'm talking about the clock frequency, or the time between periods of a processors crystal oscillator (it generates the clock frequency in lame terms).

Lets use my computer as a common computer.
It has 6Ghz or (1/6GHz = 16.6667nano-seconds/cycle).

If 256!:
NOTE: c = cycles, s = seconds
I’ll use deciBels because it is simpler math and easier to convert to and fro.

1/6GHz = 16.6667ns/cycle

log(16.6667E-9) = -9.77815dBs/c
256! = 8.57818E506 or 8.57818 x 10^506 (HUGE NUMBER)
log(8.57818E506) = 506.933 <<<<See? Logarithms are so much easier.

Doing Math....
506.933 + 1 = 507.933dBc      NOTE: the 1 is = to the *10 lines. If you understand math. You'll understand the basics of logarithms.

507.933dBc + -9.77815dBs/c = 498.155dBs

1.42889E498 seconds

4.54344E487 millenniums to decipher the anagram.      



IF 256:
(256*10)c + 40c = 2600 cycles.

16.6667ns/cycle * 2600 cycles = 433.333ns to decode the anagram.



Note: I could have the time wrong. Because I am sure that the signal is slowed down some during the process of the computer. Plus, the computer is not SOLELY processing this program. It is using other programs in between this one. I am going to check with my teacher at school for this question. This is where baud rates are required to calculate the exact processing time.

[Tabit]

in the above Post. Forgot to multiply everything by 4 cycles. So, everything I did in the above post is 4x longer.

You can do the math for the 256! version.

It's pretty straight forward for the 256 version.

[Demagog]

I forgot all about asking this question.

I wasn't thinking right when I asked about 256!. The encrypting method I was using doesn't completely fill all of the slots; it's a 16x16 grid and the plaintext (the encrypted message) only takes up 1/4 of that, or 64 slots. So I could just fill in the extra 192 slots with random letters.  Normally I use a two dimensional grid, but it's possible to use infinite "dimensions." I decided to use a cube with sides equal to 4 slots, so that's 4^3 = 64. And because of my encrypting method, when using sides of length 4, all of the grid (or figure) is filled with the plaintext. Basically, the formula for how much of a grid is filled using the encrypting method is 4*x^-1 = y (x is the side length, y is how much of the grid can be filled with plaintext; if the plaintext isn't long enough, you just end the encrypting method and start adding in random letters). I'm taking a computer science course next semester, and maybe more afterwards if I like it. Eventually I'll make a program that can do all of this for me. Hopefully I'll wind up with something that can create infinitely large encryptions that are impossible to decrypt without the key.

I've made a few competitions with these encryptions in another game's forum (I give large rewards), and only the first one has been solved, and it was an easy one (8x8 with no fancy stuff). It's been a few months now, so I'm fairly confident in this encrypting method.

And just to clarify, my questions should have been how long would it take a computer to go through 64! possible combinations. And in the future it won't matter because I'll use 8 as a minimum side length, and I'll probably use multiple dimensions.

[Tabit]

I completely forgot about using multi-dimensional arrays. See, I'm not a normal programmer. I am a beginner of sorts, but I am more into the systems of micro-controllers and how they work than in high level programming languages. But, I have a general idea of how they work. Unfortunately, I didn't get arrays too well, I might go back and study them and do some research in my programming books to see what's up and how to. Then I might be able to solve this problem.

See, I'm studying to be electrical engineer. So, programming is not my main area of study. I just have the idea of it and have a good idea of how computers transfer signals.