Page 1 of 2 12 LastLast
Results 1 to 10 of 16

Thread: Weird encryption concept

  1. #1

    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!

  2. #2
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207
    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

  3. #3
    Senior Member
    Join Date
    Nov 2003
    Posts
    107
    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.
    Is there a sum of an inifinite geometric series? Well, that all depends on what you consider a negligible amount.

  4. #4
    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.

  5. #5
    Now, RFC Compliant! Noia's Avatar
    Join Date
    Jan 2002
    Posts
    1,210
    with XOR based encryptions, depending on how they are preformed, you can manipulate the output by what you put in.....
    With all the subtlety of an artillery barrage / Follow blindly, for the true path is sketchy at best. .:Bring OS X to x86!:.
    Og ingen kan minnast dei linne drag i dronningas andlet den fagre dag Då landet her kvilte i heilag fred og alle hadde kjærleik å elske med.

  6. #6
    Regal Making Handler
    Join Date
    Jun 2002
    Posts
    1,668
    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.
    What happens if a big asteroid hits the Earth? Judging from realistic simulations involving a sledge hammer and a common laboratory frog, we can assume it will be pretty bad. - Dave Barry

  7. #7
    Senior Member
    Join Date
    Jun 2002
    Posts
    174
    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.
    I\'m back.

  8. #8
    Senior Member nihil's Avatar
    Join Date
    Jul 2003
    Location
    United Kingdom: Bridlington
    Posts
    17,188
    Hi Soda,

    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 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.

  9. #9
    Senior Member
    Join Date
    Jun 2002
    Posts
    174

    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.
    I\'m back.

  10. #10
    Senior Member nihil's Avatar
    Join Date
    Jul 2003
    Location
    United Kingdom: Bridlington
    Posts
    17,188
    Nice one Embro~

    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •