How to get the strength of encryption

Hello!
I've often seen programs saying that the encrypt with 128 bits, meaning that they are very safe.
My question is, how do you calculate how many bits your algoritmh is ?
I'm using Randomize(Seed) (where seed is the key, a number choosen by the user)
This gives a series of pseudo-random numbers, which I add to the ASCII-value of each character.
Tee user can input seeds from 1 to 1 000 000 000 000,
but due to a bug in Randomize, it gives only about 22 millions different seeds.
How many bits is this?
Or do you measure the strength of encryption in another way?
Hope somebody can help me, so I can compare my program to the "real" ones on the market.
Pentax

Random number functions are seldom used for encryption. Many (perhaps most) schemes use some algorithm requiring a string of bits. In order to decrypt, you must know that string. When they say 128-bit encryption, they are specifying the length of the string. I think 128 bits is considered adequate, but not strong.

The Xor function has the property that Xor twice with the same binary value results in the original value. If you break a message into 128-bit binary pieces and Xor with a 128-bit key against each piece, you get what looks like garbage. If you take the garbage, break it into 128-bit pieces and Xor using same 128-bit key you get the original message back. This is a fairly good encryption algorithm. Using a longer key makes it better.

The above is an example, there are more sophisticated methods in use. I am sure that you can find web sites or books on the subject. Try "Public Key encryption" in a web search or just "encryption." You might find more data.

It does not pay to reinvent wheels. Do research before spending time on an idea.

Hehe... Your random number fits in a Long (var) so it's 4 Bits..

Most Encryptors / Decryptors use a string to mix up the data....

128 bits / 8 = lenght of string.

How longer the string, the better the encryption.

so.. Creating 4048 Bit encryption would mean you need a encryption string(key) of 506 chars.

Four bits?
That's not much...
On the other hand, to bruteforce through all 22 millions of cimbination would take sime time, right?
Especially if the user encrypts two or three times, with different keys.
Do you think it's too unsafe?

As for reinventing wheels, that's what makes it fun.
I could of cource get PGP, but then what? I want to program an encrypter, I don't need it.
Pentax

Kedaman:
First, I hope you do not take offense for me reinventing the wheel. I don't think I can do something as good as the PGP, and my main concerne is to create a good text editor, with possibilities to encrypt.
But I'm still curious over encryption...
But if you can't measure the strength in bits, is it possible to calculate if the algoritm is good or not?

If, for instance, I only allowed keys from 1 to 100, it would be an easy thing to brute force through all possible keys and see when you get clear text.
But with 22 milions keys it's a bit more difficult.
So is it possible to say if the algortihm is secure or not?
Pentax

Of course i don't take any offense, i'm usually reinventing the wheels all the time myself hehe.
No it's really hard to calculate a algoritms "strength", just because algoritms can be so different, although keyencryption have the common part, the key length, doesn't mean it's hard to make long keys. No the algoritm itself has tons of factors that can improove or make it weak. I wasn't really aiming at security myself when i did those algoritms at my homepage but performance instead, well now i have random encryption, and from some tests done, including nongeneric private keys, it seems to encrypt them well. But that's just a guess. There might be flaws you don't know about, tricks that hackers can use, to make your encryption obsolete, or at least easier to crack.

Usually those big encryption algoritms out there are much "stronger" since they have been used, been cracked against and improoved over and over again. Could be called sort of "experience".

It is simple to calculate your algorithms strenth.
It all depends on the length of the key you use to encrypt with. A 128 bit encryption algorithm uses a key length of 128 bits. There are 8 bits per byte. Each character is a byte. Therefore, if you have say, an 10 character key, that repeats, you have 80 bit encryption. When i say 'repeats' i mean like so:

Your key is ABCDE
Your text to encrypt is ABCDEFGHIJKLMNOPQRSTUVXYZ or other suitable text,
therefore, to encrypt it, you 'cycle' the key:

Key Characters: ABCDEABCDEABCDEABCDEABCDEA
Text Characters: ABCDEFGHIJKLMNOPQRSTUVWXYZ
This means that you figure out your result by doing whatever you choose to do to your original text with your key, be it xor or whatever.

Therefore, 128bit encryption uses a 16character key.

By the way, it is best not to use a random number in an algorithm. You will have to store the number somewhere. This makes it imo insecure and i would recommend that you dont use them.

I was searching for something on http://www.planet-source-code.com and I found this encryption/password strength rater which does what it says. And its got many votes and is the contest winner, so I guess it's a good program to test your encryption to see whether it is strong or not.

Try AES its the new Advanced Encryption Standard for the US to replace DES. 128,192 & 256 bit encryption.

Forget PGP, it's public key and primarily used for having peaple pass data to each other not for just keeping something safe (although it could be used like that)

Encription strength in bits is considered to be the size of the key assuming the algorithm is safe, not some little 'XOR the text with a random number key'. The serious algorithms are much more complex.

as for
"22 millions of cimbination would take sime time, right"
no!
expect a normal PC to be able to try several million combinations a second.

you want to put your own encryption algorithm in your software then you'll need a good disclaimer. Like

"This Algorithm was written by me, has not been tested by any authority and the data ecryption strenght cannot be guarenteed, Use of this software implies the user understands that their data may not be safe from crypto-analysis"

If you want to do it, go buy a book. If you read though the other encryption articles here you'll see that most people don't know.

Paul I really appreciate your input, but I think Pentax want's to do this himself, in other words reinvent the wheel :) And it's definitely not 22 million combinations, i figured out it's 3025552, using this code:

Code:

---

For z = 0 To 30
  Counter = 0
  For y = 2 ^ z To 2 ^ z + 1 Step 0.00001
    Rnd -1
    Randomize y
    x = Rnd
    If xx <> x Then Counter = Counter + 1:
    xx = x
  Next y
  Debug.Print 2 ^ z & ":" & Counter
Next z
End Sub
'1:100000
'2:100000
'4:100001
'8:100001
'16:65536
'32:32768
'64:16384
'128:8192
'256:4096
'512:2048
'1024:1024
'2048:512
'4096:256
'8192:128
'16384:64
'32768:32
'65536:16
'131072:8
'262144:4
'524288:2
'1048576:1 <- Here's the X=1 point. log(1048576)/log(2)=20
'2097152:1
'4194304:1
'8388608:1
'16777216:1
'33554432:1
'67108864:1
'134217728:1
'268435456:1
'536870912:1
'1073741824:1
'2147483648:1
'Combinations: 4* d/dx[1, 96] 2^(20-x)= 3025552

---

Anyway that's not my point, random encryption in combination with a key makes it strong, KKRSE is a great example of that.

BTW, the calculations got wrong, should be

Code:

---

'Combinations: 2* d/dx[-96, 96] 2^(20-x)= 2.3970E35,
'that's 240 decillions combinations!!! That's equalent to 118 bit encryption

---

Howeever when you combine it with a nongeneric key you won't even see the combinations anymore, the key length gets into the exponent of the random algoritms possibilities.

Hmmm.
When I calculated it I went from 1 to 1 000 000 000 000.
I wrote about this in a thread called Encryption? by Dennis Wrenn (I think).
I got it that every number up to 2^21 (a bit more than 2 millions) got an unique series of random numbers.
After that e million more for every time the exponent (z in 2^z) got one higher.
That made 22 millions.
As for testin several millions combinations every second I think is a bit optimistic.
The PC must decrypt the text and also test it to find words like "the", "and" and stuff liek that.
It takes time (unless you've got a Cray T-94, of course).
Pentax

Note how random encryption chooses the series, look at my code above, that demonstrates how often the series changes in a specific interval (Actually I wouldn't have done this little research if you didn't mention about it). For instance between the interval 0-1 you have probably 99.9% of the series. I think what you meant is that you have 1 trillion combination, only with wholes. I found out you have 240 decillions, if you use the whole spec with a Decimal Datatype.

Well, of course there is one trillion whole numbers from one to one trillion (I take it that we're speaking of a trillion as one million millions, and a billion as a thousand millions).
But as you said, there are holes in the combinations.
So when I say 22 millions, I mean 22 millions seeds which give different series with Randomize.
I'm only using whole numbers, so that can be one reason to why we get different results.
And Kedaman, what do you mean with a decillion?
I've never heard of it before.
Pentax

1 000 000 000 000 000 000 000 000 000 000 000
Yep 10E33 and you have 240 decillion combinations
And yeah the swedish billion is one million millions, but were not talking about that. The thing is that you are using a long integer right? Well you are as much allowed to use any datatype as the seed number, including floating points, but the decimal datatype is most accurate :)

Everything i bigger and better in Sweden ;)
Actually, I use Double, and then round them of to integers (to make life a bit more simple).
But maybe I'd get even more if I didn't?
Btw, I've asked around a bit, and one of my friends should ask one of his friends (and so on and so on...)
And told me later the the friend had laughed homself into pices when he heard about an Encryption program made in VB.
It would be a piece of cake to crack it, he said.
That might be true, but does it matter?
As longa s you don't have the key, bwhat good is it tha know how the algorithm works?
I know of course it gives you a start when tying to crack it, but I wonder if it really matters?
Anyone got an idea?
Pentax

Don't round it Pentax, whatever you do, dont round it, because you will loose almost all combinations. Floating points or Decimals are good in this case because The Rnd seed spec is hugest between 0 and 1. The closer to 0 you get, the smaller intervals between each different seed ;)

Your friend, does he know much about encryptions? I'm almost sure encryptions will always be the same on whatever language, if it's easier to decompile vb code shouldn't affect the security of it, since you use a key :) Anyway i haven't heard they have made decompilers for vb6 yet.
BTW the best algoritms are public and you usually know how it works if you are a cracker, otherways you can't be a cracker at all. More private und unknown algoritms usually have some flaws and can be easy to crack in some way.

Hmm.
Yes, maybe.
But still, 22 combinations, isn't that good engough?
When encrypting three times it makes about 1E22 (10 000 millions millions millions) combinations. One xec on each, that's 300 million millions years.
And by that time, "We attack in the morning" is quite outdated, wouldn't you think?
I'll look into it.
Maybe it would be a nice little project to see how you can get the most rnd combinations...
But still my original question is there.
How safe is it?
Pentax

Yeah,

you can say that from the point of view of a brute force you will be safe but what are we really talking about here?

Like was mentioned earlier, it's math not programming! if your protecting your data from a group of VB programmers I'm sure you'll be fine, in fact XOR with a bit of a twist will do but if you are talking REAL encription, considering this discussion most people don't know whether the algorithm is safe or not.

If it can be cracked easily by a pro crypto-analyst then it's poor and not worth using
If your just playing then it doesn't matter

I'm of the opinion that if you don't want to spend years researching the subject then impliment a known algorithm, if you can't even do that then you have no business in the field and should use a=1, b=2 like the australian govt ;).

I've implemented a few simplistic algorithms in basic and the complexity of the permutations in them makes this look laughable.

I may look like an a$$hole for saying that but why not implement an known algorithm as a reality check to see how it's really done? you'll learn heaps, I did! at least enough realise the gap between what they were doing and my ideas of encryption.

Remember it's a serious subject if your distributing an application to the big wide world

I'll post some links if you like, DES, blowfish, MD5 are all do-able and are a LOT better than this, yeah, DES is only 56bit, but you will have to search that, there's little chance of cracking the alorithm itself. This search has been done in about 3 days but the systems had 1500 CPUs

The algorithm itself was secure, and still is

Carried away?
Well, a bit maybe...
And I must say, there's a lot of things between using Ceasar's crypto (a=c, b=d, c=e, d=f) and implement known algorithms like PGP etc.
Simon Singh, author of "The Code Book", included a encrypted text as a price contest for the readers.
It seemed safe enough, but was cracked some weeks ago (by a couple of Swedes, btw).
I could of course do the same to test my app, but I can't afford it.
So what I try to say is this:
I can't make an encrption program safe enough to stop NSA to read my mails, and to stop my sister from doing it simple Ceasar crypto would be enough. But there is something between, a program that would be reasonable safe without taking years to do.
And now I wonder how you can calcualate the safety of my app, allthough I know it can be cracked by a real pro.
As for you being an a$$hole, maybe, but I forgive you ;)
I guess you think I'm a dreamer, who can't see reality in the eyes, but believe me, I do this for the fun of it, not because I want to be spotted by an talent scout from NSA (The part of American intelligence which take care of encryption/decryption, for those of you who do not know).

I'll soon make an encrypted text and post it together with the algorithm, so everyone can try to crack it.
Pentax

Nice idea Pentax, i'll think about cracking it, might be some feeling to proove myself to be wrong, the hard way! What am I trying to do? Eh, I'll just say that i don't know if it's secure enough but that depends on your purpose for the algoritm, if i succeed, then i might tell you how hard it was, if i don't, then i haven't prooved anything

Quote:

---

Hehe... Your random number fits in a Long (var) so it's 4 Bits

---

Would that be 4 bits or 4 bytes and 32 bits???

four bits would only let you count to 16...

Just wondering.

sq1

Quote:

---

Originally posted by Paul282
Yeah,

I'll post some links if you like, DES, blowfish, MD5 are all do-able and are a LOT better than this, yeah, DES is only 56bit, but you will have to search that, there's little chance of cracking the alorithm itself. This search has been done in about 3 days but the systems had 1500 CPUs

The algorithm itself was secure, and still is

---

MD5 is a one way hash. You cannot decrypt it like say, Blowfish.

The measure of thye strength of an encryption is dependent on the algorithhm and the seed key. If one can guess the seed, which is the only variant across multiple executions of the algorithm, the whole thing fails. The alogrithm can be "re-constructed" by a debugger. Therefore random seed *has* to be "random".

There are many algorithms that are avialable to encrypt given data, most of which depend on the computational unviability of factorising a number into its prime roots. Others depend on more complex numerical analysis such as Combinatorial Algorithms among others. But these are all published or one can generate your algorithm by stepping through the debugger.

Therefore, random number generation becomes paramount to the success of the encryption. The "Key" can then be generated from a truly random seed.

The random seed is not easy to generate. System Time is a bad idea!

More links on cryptography and RNG

• http://www.random.org/
• http://www.itsecurity.com/papers/upaq.htm
• http://crypto-systems.com/meyer.html
• http://triumvir.org/rng/
• http://www.cs.berkeley.edu/~daw/rnd/

And one *cannot* get any more random than this

Hope the above helped.