4

I must first say I have never studied cryptography, and everything I know on this topic is just basic notions.

We were looking at a fast and easy way to encrypt some data (to be stored into a database) using a password. I know the "safest" algorithm is AES, but it's probably too complicated for us and I know it requires us to obtain authorizations from the US government, etc.

We thought about this (simple) algorithm, which reminds me (but I may be wrong) a sort of "One time pad". (it's not written in any specific language... it's just the idea :) )

// The string we need to encrypt
string data = "hello world";

// Long string of random bytes that will be generated the first time we need to encrypt something
string randomData = "aajdfskjefafdsgsdewrbhf";

// The passphrase the user selected
string passphrase = "foo";

// Let's generate the encryption key, using randomData XOR passphrase (repeating this one)
string theKey = "";
j = 0;
for(i = 0; i < randomData.length; i++)
{
    theKey += randomData[i] ^ passphrase[j];
    j++;
    if(j == passphrase.length) j = 0;
}

// Encrypt the data, using data XOR theKey (with theKey.length >= data.length)
string encryptedData = "";
for(i = 0; i < data.length; i++)
{
    encryptedData += data[i] ^ theKey[i];
}

On disk, we will store then only randomData and encryptedData. passphrase will be asked to the user every time.

How safe will an algorithm like this be? Except with a brute force, are there other ways this could be cracked? I don't think statistical analysis will work on this, does it? Is it "as safe as" a One Time Pad?

Thank you!

Heisenbug
  • 38,762
  • 28
  • 132
  • 190
ItalyPaleAle
  • 7,185
  • 6
  • 42
  • 69
  • 15
    Rule #1: **Don't** invent your own encryption algorithm (or cryptographic hash, for that matter). One or two practical and really good encryption algorithms are found about a few times per decade, by exprienced cryptographers after lots and lots of work. Statistics alone say everything you come up with is bound to suck. –  May 26 '11 at 16:45
  • You're right. I'm not pretending to invent the safest algorithm :) Just asking if my idea was somehow good for non sensitive data. – ItalyPaleAle May 26 '11 at 16:51
  • 2
    *It's going to suck*. If you want to find and fix even the most obvious (to the expert) flaws, you'd need to devote quite some time to study and create more algorithms. That's a lot of time wasted and still no guarantee. You should simply use something existing. Either the data is so non-sensetive that you can omit the encryption or you should do it properly. If you want to learn some cryptography, please don't try it on anything remotely sensetive enough to be considered for encryption. –  May 26 '11 at 16:55

4 Answers4

9

You can just import an AES library and let it do all the heavy work. Authorizations from the US government? It is a public function, and the US government also uses it.

CQM
  • 42,592
  • 75
  • 224
  • 366
  • I've heard a lot of different opinions about this. Many told us that the authorization is required any time you use any AES function, even if you're linking with open source or system libraries. We found (here on StackOverflow) people saying the permission is required also when your application communicates with a web server on https! – ItalyPaleAle May 26 '11 at 16:53
  • 1
    Check out Note 4 in http://www.bis.doc.gov/encryption/ccl5pt2.pdf. As long as the primary purpose of whatever program is going to be encrypting the data and storing it in the database isn't maintaining the database, I think you should be fine. – JAB May 26 '11 at 17:23
5

This is extremely weak. Statistical analysis would crack it in the blink of an eye. Some diligent pen-and-paper guesswork would probably crack it pretty quickly too.

The only exception would be if (1) randomData was taken from a truly crypto-strength source, (2) randomData was at least as long as your plaintext data, (3) randomData was never, ever re-used for a different message, and (4) you got rid of passphrase altogether and treated randomData as your key. In that case you'd have what amounts to a one-time pad.

LukeH
  • 263,068
  • 57
  • 365
  • 409
  • (1) Well, suppose that randomData was "random enough"... Let's ignore that issue at the moment... (2) Did you really look at my "code"? randomData.length = theKey.length which is > data.length. (3) ok, I could re-generate randomData every time (4) I wrote in the post: "On disk, we will store then only randomData and encryptedData. passphrase will be asked to the user every time." – ItalyPaleAle May 26 '11 at 16:58
  • @Qualcuno: *(1)* Only crypto-strength random is random enough for cryptography. *(2)* Fair enough, you'd need to ensure that key.Length >= data.Length every time. *(4)* You'd need to treat `randomData` as your key. ie, keep it completely secret, not store it alongside your encrypted data. And you need to ditch the passphrase altogether: incorporating the passphrase into your key in this way is out of the question if you want any semblance of security. – LukeH May 26 '11 at 17:07
  • (4) Even if the key isn't really equal to randomData, but derives from it? Of course, then everything relies on the security of the password... – ItalyPaleAle May 26 '11 at 17:11
  • @Qualcuno: That really depends on how the key is derived from `randomData`, but in your case the derivation algorithm is extremely weak: I suspect that a half-decent attacker with `randomData` at their disposal could decrypt the data fairly easily (assuming that the passphrase itself wasn't a crypto-strength random stream at least as long as the plaintext!) – LukeH May 26 '11 at 17:17
  • I understand. Thank you. Not using this in any way, then: let's just say I learned many new things today! – ItalyPaleAle May 26 '11 at 17:26
5

No, this is not secure.

If the random data is stored alongside the encrypted data, then it is simply equivalent to XORing with the passphrase: this is because the attacker can simply XOR the encrypted data with the random data, and obtain plaintext XOR passphrase as the result.

caf
  • 233,326
  • 40
  • 323
  • 462
2

No, it isn't safe. Using xor with random data and password this way is completely wrong. A one time pad cryptograpy needs the random data to be the same length as the data to be encrypted.

Heisenbug
  • 38,762
  • 28
  • 132
  • 190
  • 1
    mmm..yes you are right.. anyway the are no longer random because you are xoring it with a repetitive short sequence of non random data. I think you can use similar technique that can be used for breaking a vigenere cypher (http://en.wikipedia.org/wiki/Vigen%C3%A8re_cipher#cite_note-0) . Anyway, @delnan comment is great. Follow his advice. – Heisenbug May 26 '11 at 17:16