# Pi Message Encryption [duplicate]

I created a simple yet efficient message encrypting page that will encrypt messages using Pi. Though not being an expert in this area, I am nowhere near sure how secure this is and how easy it would be to crack the encryption.

Basically how it works is there are 2 inputs into the function, the message to be encrypted, and the key. The key specifies which digit in pi to begin with.

So pi is 3.14159... and if the key was 3, the encryption would start at 4.

Can someone tell me how well this system works? If it has flaws and what are they so I can fix them?

The page can be found here: http://spedwards.github.io/projects/msgencrypt/

The encryption source can be found here: https://github.com/Spedwards/JS-MessageEncrypter

If flawed can someone please crack the message within the quotes as proof. "Hlont, iutgrcuxnewmova xn topdoqj akmy nthscuwros."

-

## marked as duplicate by fgrieu, e-sushi♦, Stephen Touset, Maarten Bodewes, rathJul 1 '14 at 19:39

This is a poor idea simply because you gain nothing by choosing an offset of $\pi$. Even assuming $\pi$ is unpredictably random, the "key" is the index of the starting digit of pi you wish to use, and to meet modern security expectations, it would need to be at least 128 bits long. But if you already have a 128-bit random key, you're done — you don't need to index into pi to get random digits! –  Stephen Touset Jun 30 '14 at 16:37
@StephenTouset, unless your message is longer than 128 bits... –  otus Jun 30 '14 at 21:56
@otus This doesn't really solve that issue anyway, since related-key attacks are trivial; even if you wanted to keep the spirit of this approach, you'd want to feed the output through a PRG anyway to avoid close keys effectively becoming two-time pads. –  Stephen Touset Jun 30 '14 at 22:15

Assuming the digits of $\pi$ are pseudorandom (which hasn't been proven), you could construct a cipher from it. However:

1. Your numbers are way too small to be secure.
2. You seem to be adding a decimal digit to the letter, which means the ciphertext leaks more than half the bits: you know 'j' was one of 'a'...'j' originally.
3. You only handle lower case letters – upper case and other characters stay the same.
4. It can be trivially broken with a known plaintext attack or if you use the same key twice.

A secure stream cipher could have a 128-bit key, a 128-bit nonce and e.g. $2^{64}$ bits of output for each key–nonce pair. To get independent outputs you would use a total of $2^{128+128+64}=2^{320}$ bits of $\pi$, which is infeasible.

For example, if your cipher XORed the message with the binary digits of $\pi$ starting from position $2^{192k+64n}$, where $k$ is a 128-bit key and $n$ a 128-bit nonce, it might be secure. (There are formulas calculate the $n$th binary digit of $\pi$ quickly, just not that quickly.)

Of course, you shouldn't use this idea in the real world even if you could make it work, when there are well reviewed and tested algorithms you can use instead.

-
Upper case characters are screwing up right now, they were working. –  Spedwards Jun 30 '14 at 15:55
Any sane encryption algorithm shouldn't care about "characters" anyway. It should care about bytes. –  Stephen Touset Jun 30 '14 at 16:38

If flawed can someone please crack the message within the quotes as proof. "Hlont, iutgrcuxnewmova xn topdoqj akmy nthscuwros."

Hello, congratulations on solving this encryption.

Took < 1 second in Ruby. Basically it is far too easy to brute-force due to your very small key space, as explained in otus' answer. All I did was translate your decrypt routine into Ruby and iterate through the possible keys.

If you used a much larger key space and converted all characters (i.e. including punctuation and spaces) so that any resulting encrypted character was equally likely, then it would not have been so easy.

If you do take this further, it might be an interesting exercise, and in principle you could make a cipher based around the core idea that had a chance of being secure by modern measures. However you should bear in mind that it would not have any objective merits over existing ciphers (in fact most likely a few flaws*), but it might have a subjective "I made this" feeling, and be a chance to practice or understand general data manipulation functions related to cryptography.

* Probably the most obvious flaw unfortunately goes to the heart of the idea: Using $\pi$ as a secure PRNG has perhaps a cool factor, but in order to make the output unguessable, you need the output from a secure PRNG so you can choose randomly from a large enough range of offsets.

-
Even then, there are catastrophic flaws in the implementation. No use of initialization vectors. No authentication of the ciphertext. Operation on characters rather than bytes. This is something you might use to "encrypt" notes passed around in high school, and no more. –  Stephen Touset Jun 30 '14 at 16:45
@StephenTouset. Yes. But as a beginner's question of the form "I have made this, can it be attacked?" I think the OP has made a good effort (providing a description and an implementation), and is asking in the right place. –  Neil Slater Jun 30 '14 at 17:20
I agree. That said, I think it's important to be clear where this approach falls in the general spectrum of security. This approach will not likely benefit from repeating a cycle of pointing out weaknesses and "patching" them. –  Stephen Touset Jun 30 '14 at 18:52