Doctor's Crypto - Introduction [Part 1]

Cryptology
1

Hey mates,

long long time ago I made my last post, but now I’m back with a simple series about a little self-made Crypto (Nah, it’s more a key generation), which uses a (At least I think it is :grin:) new idea for key crafting. Either you’re now thinking “Oh, cool! Let’s see what his idea is” or you’re thinking “Self-made Crypto?!? Dude, WTF’s wrong with you?”, I hope anyway you’re liking this article, even if it’s just entertaining ;).

Am I an Idiot?

That’s a great question! Nope, I think I’m not (Okay, maybe… But that’s not the point here ;)). Of course I don’t want to create an EES (Extreme Encryption Standard), but just want to try out my idea, which I had already about half a year ago.

This series can be seen as a little hobby project, which I want to share with you, and not as a serious attempt to create a good Crypto. So with this in our mind, let’s start!

Introduction to my Idea

Maybe some of you know one problem of synchronous ciphers: You want to have long keys for a good encryption, but the key has to be sent to the decrypter, so it shouldn’t be too long. To solve this problem I stumbled upon a way of generating never ending keys out of a normal number.

Yes, it isn’t magic. It isn’t even pretty clever. I just thought of using a number to get it’s square root, because this is as long as you can calculate it. The first thing we have to check of course, if we want to know whether this way looks promising, is to have a look at the frequencies of the numbers 0-9 in different square roots.

With this in mind I wrote a simple program in C# to test for different frequencies in numbers. The big problem was that the double type in C# for representing decimals can only have about 17 digits after the floating point; but my original idea was to use up to 10000 digits for the key!

Ok, so I decided to just test these 17 digits for their frequencies first and then maybe think of an idea to expand it.

My Program

This tool is a simple Windows Forms Application, which takes a starting number and then calculates the square root of it. After it has done this it increases the number and calculates the next square root. The frequencies of the digits are shown with the number and percentage of their occurence.

You can get the project here. Little Note: I’m very sorry for the poor programming style. I can’t concentrate when it’s that hot :wink:

If you’re only interested in the executable you can get it here

If you run it you should see something like this:

You can start with a different number, but you’ll get the pretty same results. At this point I add an important fact: My program ignores any digits in front of the floating point! This is important to make sure that not everytime a 1 is added to the frequency just because the program is currently at the 1 billions. I tried that before and it changed the frequencies a lot!

Anyway, I was very surprised, when I saw this results! It’s very promising that every digit, except the Zero, has the pretty same frequency as every other digit. Another interesting thing is that this behaviour begins pretty fast.

Above you can see what happens if we stop the procedure at the very beginning. The frequencies aren’t that different!

Future Improvements

Here you come into play! I thought it could be interesting, if you guys start to share your thoughts on this project and how it could get better.

My thoughts:

How can we get longer keys (Currently only 17 digits can be used)
I would just use these 17 digits of the number and then increase it by one, to use the next square root and so on, till you got the key length you need. Here comes a little problem:

The frequencies aren’t perfectly spread
When you just need a small key, that’s right. This key generation can’t be used for small texts, but I think when you need more than 1.000.000 digits it’s good enough.

Improve probability spreading
This part is interesting. I thought of maybe putting always two digits into a group to mask the frequencies better, e.g. if you have this: 067453 you put it into this: 06 74 53. This should help a bit. (Not tested yet, though!)

What encryption can be used along this key generation?
Yep, here ends my knowledge :grin:. Maybe some of you have an idea which encryption technique would get along with a key like this one?

And it has to get practiced
As you see I didn’t test much about the frequencies in different states. I think it depends heavily on the encryption technique whether this key generation could be valuable or not. As I said before, I don’t have the knowledge/experience to select a good technique, so here it’s up to you ;).

Conclusion

This key generation could be usefull for generating large keys out of just a simple number or word (Words can be converted into numbers). The big big advantage would be that you would have an infinite amount of numbers, so you got as much keys as you want! These can be used to generate OTPs (One time pads; yes, this aren’t real OTPs, but they’re pretty close ;)), which are the optimal way of encrypting.

I hope maybe some of you got interested in this project as well and are keen on making cryptography great again! (Sorry, forgive me that bad joke :grin:)

|-TheDoctor-|

4 Likes
2

I don’t get it. Last I checked, there has to be a less ambiguous mathematical relationship between the keys used. What’s the point of analyzing digit frequency if you keep mutating the number? What are you even looking for?

And, floats aren’t accurate in a machine, so what’re you doing to accommodate for that?

3

I’m very sorry, if I couldn’t explain it good enough in english :slight_smile:. It’s not my native language (I think this is pretty obvious, when you read my texts :wink:), so especially speaking about maths in english is very hard. Here’s another try to explain my idea:

The plan looks like this: You want to send a secret message to a friend. Roughly said, the longer your key is, the better the protection (In case of even encryptions). But if you just take a key as long as your whole plain text, you don’t solve this problem, because this key has to be sent to your friend too.

My solution for this is to take one simple key, e.g. 123456 (Yes, pretty secure ;)). This key can be used to generate an OTP (See description above; it’s not a real OTP), with the technique given in the post. You take the first 16-17 digits from the square root of this number and then increase it to get the next square root, e.g. 123457, and so on.

These square roots get every time put together to a long string containing all digits. This is the key, which you can make as long as you want; and you just need ONE number to generate this! Another advantage is that we got an infinite amount of numbers, which could be used as key, so brute-forcing it takes theoretically an infinte amount of time.

The post above was to explain the theory and to show that the frequencies of the digits in different square roots are pretty equal, except Zero.

I hope you got at least my idea now :grin:

4

Hi @TheDoctor,

Not being a cryptography expert myself, these are my first thoughts:

  • The sqrt operation is quite costly. Normally you have to use an iterative/approximation process to calculate it. To my understanding, the key is not generated and then used, but calculated on-the fly as more digits are needed, so, at first glance it will have an impact on performance, and may be difficult to use it, for instance, on comms.
  • As your seed gets bigger you are probably losing precision on the fractional part of your significant . That means that you probably need to write special code to do the calculations. You will have to anyway because the native floating point formats supported by the machine (right now) cannot go over those 30-34 digits (check the table in the wiki page)
  • Instead of using decimal digits, I would use the binary bits. Using decimal digits you are constraint to an alphabet of 10 symbols per byte against the 255 possible. As I said, I’m not an expert on cryptography but intuitively seems that a brute force attack against a piece of the message may be feasible and not require much effort. Not sure if you understand what I mean… Not sure either if it is possible.
  • I think that an histogram is not enough to prove you are producing a random uniform sequence. Probably you need a more strong statistical method ( https://en.wikipedia.org/wiki/Diehard_tests )

Hope this helps

1 Like
5

Nice answer @0x00pf! Here are my thoughts on your’s :grin:.

  1. Yes, I searched a bit if there’s a good way of using some algorithm to calculate the square root digit by digit. The sqrt function has many downsides, but I didn’t find a good way of doing it yourself. Another point was, that I was sure the frequencies wouldn’t be that widely spread and that my idea will already be killed at the very beginning, so I wanted to try it out roughly first.

  2. Yep, I wanted to use the decimal type in C# first, which would have been worth these 30 digits, but sqrt doesn’t come along with it ;). The main problem stays the way of calculating the square root. Maybe some math kings here know a good way?

  3. I already thought about binary digits, but I didn’t knew a good way of converting the decimals to binaries without losing the random effect. With binary digits it would be easier to find a suitable encryption method.

  4. Again you’re right. As I said above it was just a rough test for showing whether this technique could be valuable or not. If this test had already failed, the whole idea would be rubbish :grin:

1 Like
6

Reading the comments there appears to be some doubts about the method, although I am a fan of the idea of using square roots to generate numbers. Reminds me how people use checksums/hashes from passwords to generate more sophisticated passwords.

I say you should keep trying on this, people may disagree in some areas, but you should still pursue your ideas.

Good luck and nice work :slight_smile:

2 Likes
7

This topic was automatically closed after 30 days. New replies are no longer allowed.