Weird encryption concept

I was just wondering if their was a name for this type of encryption.

Code:

---

String plainText="something written here";
String password="fruitloops";

String encryptedText= encrypt(plaintext,password);


decrypt(encryptedText,password); // Would return "something written here"
decrypt(encryptedText,randomPassword); //Would return some garbage, incorrect string

decrypt(encryptedText,fakePassword); // Would return "something incorrect written here"

---

Basically, are there any encryption methods that can have false keys that generate false outputs? I figure it can be useful if you want to find someone who tries to brute force a password hash. If someone gets a hold of your password hash, they brute force it, and try to connect with a dummy output, then it can be logged that someone somehow got a hold of your password hash? Let me know if this is concept is stupid, confusing, or exists already!

As far as I'm aware, all symmetric ciphers work fine if you use the wrong key, you just get rubbish output (as you described). Obviously someone trying to brute force a symmetric key would need to be able to identify the true message from rubbish; this is fairly easy with real data.

What this has to do with password hashes, I cannot seem to determine from your message. Would you care to elaborate?

Slarty

I've heard of it before. I think it's called false OTP. OTP stands for one-time-pad and works by xoring a key (usually a stream from a PRNG) which is the size of the message with the actual message. Now, you take the fake message and xor it with the ciphertext from the real one. This gives you the fake key. So, now your ciphertext has two different meanings depending on which key is used. What's also interesting about this type of thing is that you can use it as a two-level system. You could send a fake message, that when xor'ed with the correct key, yields the real message. For this very reason, one of my policies for file registration is that if encrypted content is stored, the file must be registered and mapped before and after encryption to ensure that no one tries to use a false OTP attack against me for anything stored on my machine.

Very handy :). However, OTP schemes aren't used very often in common practice and it doesn't interface with the hashes in the way you're thinking. In modern hash systems, the way people crack it is by hashing a bunch of chosen values and checking for matches. The only way for you to try to do a dummy hash thing is try a bunch of different inputs to the function and find two matching outputs. Then, based on how you think the cracker will attempt to crack (IE which direction they'll go in during brute-force), pick the input that they would try second. That way, they'll think that they cracked the password, but when they try, it's the wrong one AND one that you know they'll try. That's the only way I could think to do something like this though.

Well, heres what I'm thinking.

I wrote a program in java, that takes a message string and a password string, and encrypts the message with that password. To reveal the message, you use the password. I was thinking of the vulnerabilities of this, and one was brute force. If someone tried to use every password on my encryption, eventually they would find the message. I was wondering if I could have a second fake password on that same encrypted string, that would yield different results, like FR said.

with XOR based encryptions, depending on how they are preformed, you can manipulate the output by what you put in.....

Soda i'm no crypto expert but, from the way i read what you have discribed the vulnerabilty is. If the password is cracked so is the encryption (unless i miss understand).

The way i look at it, is this. You have a file you want to protect, so encrypt it. Then passwword protect it. So there are two layers of security. In your example the password would seem to be the key to the encryption.

This is nice, but wouldn't a brute force attack have equal odds of picking the correct or incorrect key? I mean, what if it picks the right on and stops. They have the message. If they get the wrong one, they have the wrong message. Seems to me that, although kinda cool, there is a certain risk of playing the odds.

One could argue that a brute force attack typically starts at the bottom and goes up (a-ZZZZZ etc), and therefor would get the "lower" key first. If that were true, you could plan you keys accordingly, so that the "lower" one is the false one.

Unfortunately, not all brute force programs attack in sequence. Some go on a random generation algorythm, making it unpredictible as to which would be tested first.

Another unfortunate thing: When dealing with plain text, since a computer doesn't truly know when a message has been decoded properly or not (unless you matched each tested solution against a dictionary to conclude that, yes, the code has been broken successfully), the program would simply keep running until all possible combinations have been tried. This is espially true when there is no one overseeing the cracking process...as I rarely stand around while my computer checks 1x10^23 or whatever keys (exaggerating a bit....)

But, as stated above, this "false OTP" method does exist, and is infact used in other forms of encryption. Many zip files, I've found, do this. While running a bruteforce attack on a password protected zip file, I found several false keys, which caused the program to quit, thinking it had cracked the password. Now there are new and better programs that can detect these false keys and simply make a record when they find one, and then keep chugging along...

Excellent thread.
~Em.

Hi Soda,

Quote:

---

If someone tried to use every password on my encryption, eventually they would find the message. I was wondering if I could have a second fake password on that same encrypted string, that would yield different results, like FR said.

---

The main problem with that is that you would have to ensure that the fake password was brute forced first?

Another issue would be plausibility? like you would need fake data with a weaker encryption, and the real data with stronger encryption.

As it is that time of the year please consider this example:

" Attack Pas de Calais June 6"
and:
" Attack Normandy June 6"

How are you going to get significantly different patterns to look the same?

What I am trying to get at that if it is an access password and it doesn't work, they will just continue from where they left off?.

If it allows access to a file's contents (that is decrypts it) but gives false information, you have gone beyond crypto and into the world of social engineering :eek: OK the simple solution is to use dummy blocks, or simpler still, make sure the fake message is always larger than the real one. But the false information has to seem plausible and not easily refuted?

OK if I get some encrypted data crack it and immediately realise that it is rubbish, I am going to be straight back on the case, aren't I.

Just my thoughts

Jinxy, as I understand Soda it is a bit like the old triple cypher, but in this case one is deliberately more vulnerable, and gives a misleading result.

:eek:

Quote:

---

The main problem with that is that you would have to ensure that the fake password was brute forced first?

---

nihil, we must be twins or something! Beat you by three minutes. ;)

Nice one Embro~ :D

I was sort of coming from the Intelligence/Security officer's angle, and you were taking a more technical crypto view. The problems are the same of course.

It is an interesting subject.

I think I am showing my age?.......I use terms like "dummy blocks", you say "false keys"...........the concept is the same...........just the technology is a few years apart :)

Cheers

The reason I got on this topic, was because I was wondering how you could stop someone that found your password hash from a server or something. I figure a dummy password could turn on "honeypot mode" in a software design, therefore doing something cool.

//off topic



Typing your ATM pin number backwards will get police to your ATM if you are being mugged, and are forced to get money out of the ATM at gunpoint or something. Sorta like a honeypot mode.

http://www.msnbc.msn.com/id/4086277/

Quote:

---

Originally posted here by nihil

I think I am showing my age?.......I use terms like "dummy blocks", you say "false keys"...........the concept is the same...........just the technology is a few years apart :)

---

Dunno about that. As a child of 17, I'm not exactly up to par on all the jargon.

Soda_Popinsky - That's interesting... I don't know if you could apply the same methods when using brute force attacks as an example. This could quite possible work as a sort of redundant authentication method, but I'm not sure how you would implement it to get predictable results (-referring to making sure the false password was used and not the real one). What would be more interesting would be to have an encryption method like this, but have the real message be another encoded one. This way, they would have to run a brute force attack on each of the resultants of a previous attack. You could have the fake password reveal a plain text (and false) message. So I could take the message "I hate dogs" convert it to "blahblahencryptedtext" then use your method to encyrypt it again, but have your "false keys". That way, when they finally found your key, they would get "Dogs are great" with the false key, and think they got it, since it would be the only cleartext message. You would take your key, decrypt, and get "blahblahencryptedtext" then run it through again and get "I hate dogs". You follow? I tend to ramble like an incoherent pig, since I have a hard time putting my thoughts into words...

I'm sure there already exists something like this, though I would be interested actually see it in practice.

Wow. The more I think about it, the more cool I think that would be. Imagine, you would have to test virtually every output... That increases time expoentially, further decreasing the probability that they could crack it...

We should make a program that does this.

Well.....I think that you are trying to move a book by using a forklift when you could just pick it up. In other words, why be so complicated when a simple solution is right there.

Just double encrypt your message. Use one key to encrypt the original message, and then another key to encrypt it again. If some one is attempting to crack your password/key, they will keep trying to get a plain text solution, never even coming close to the actual message, because when they crack the first key they will think that it is a false key, because the message is still encrypted.

Only some one who has both keys and knows that after the first key is used, that they must use the second key to decrypt the message again.

Simple works better every time.

Then if you wish to send them into a honeypot solution, use a small exe file that runs after a timed period, if the second key is not entered.

embro1001 - Sounds interesting.

Moxnix - embro suggested that in the above post. It is cryptic, but I made it out...

embro101 - I'm sure it is possible to do that, but would be easiest with XOR. You could XOR your encrypted message (I hate dogs encrypted into gibberish) with some plain text message of the same length, and get they key needed go get that plain text. It wouldn't be the only plain text though, since it appears (in my version) to be a variation of a XOR One-Time-Pad. With XOR you can easily make a one time pad, and that isn't worth bothering with (by the cracker in cracking). Unforunately, if you encrypt it again, it might acturally undermine the security since there would be a way to verify if you got the correct data or not. They could probably drop a couple trillion results (one of them will acturally be your message in plain text unless compression was performed, but they're looking for an encrypted message and would overlook it among other plain text), but still have a few trillion more that could still be correct... Just a plain one-time-pad would be best, but you'd have to solve key distribution.


Encrypting twice could probably be effective, since a well encrypted file would look like rubbish, and the cracker would not be able to distinguish between the correct decryption (which is an encoded message that looks like random meaningless data) and random meaningless data. If they knew that the key length was at most x bits, I think it would take around 2^x^x tries in the worse case... Because they have to start the first decryption, and then work on that result through the rest of the keyspace, before moving into the next itteration for the larger set... Example brute-force code... I probably messed up the loop conditional...

Code:

---

for (key1=0; key1>keysize; key1++)
{
  decrypt1 = decrypt(encrypted, key1);

  for (key2=0; key2>keysize; key2++)
  {
    decrypt2 = decrypt(decrypt1, key2);

    if (successfullyDecoded(decrypt2))
    {
      break;
    }
  }
}

---

As mentioned, you can XOR stuff together and make your own fake keys. The XOR One-Time Pad relies on this not knowing what the real key vs. fake key is. Probably the best example of what Soda was looking for in the OP.


Well, after several revisions during typing, I'll just post it. Good luck figuring this out...

-Tim_axe

Hmmm,

Quote:

---

ust double encrypt your message. Use one key to encrypt the original message, and then another key to encrypt it again. If some one is attempting to crack your password/key, they will keep trying to get a plain text solution, never even coming close to the actual message, because when they crack the first key they will think that it is a false key, because the message is still encrypted.

---

"Triple Cypher", "1600 code"(Pennsylvania Avenue?)......................the concept has been around for a long time, and Mox is quite correct.

The weak link is the human element?

Quote:

---

but you'd have to solve key distribution.

---

Exactly. Either you hand the keys out, or the knowledge of how to derive them.

Remember that the British had obtained an ENIGMA machine before WWII started, and it took them quite a while, and the incompetence/laziness of a German officer before they figured out how to use it. A very interesting story, by the way.

IBM used to make cypher machines for the US government, for all I know, they may still do. A more modern version of the same concept?

But if one falls into the wrong hands, it is only a matter of time. Obviously the fewer people/machines involved, the lower the potential risk.

I think that Soda's original concept is an interesting variation though, as here you have multiple layered encryption. All look plausible, but only one is correct............and which one is that?

OK so looking at Soda's other idea about password hashes. I would assume that brute forcing will be either total or stop at the first hit............it wouldn't make sense to do anything else?

So your system produces 10 apparently valid solutions. One is correct and the rest take you into a honeypot. If you add one of those key fob random number/pass generators to the equation, you have massively increased the security level? (I used to have one that generated a six digit random number every minute) If you operate a three strike rule then it becomes impossible, because the random number changes every 60 seconds? You would need to have correctly cracked my hash AND have my personal "decoder ring" :D

I can think of several ways around this but they involve fanaticism, corruption, violence, chemicals or electricity?

Interesting topic

Cheers