June 3rd, 2004, 05:02 AM
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.
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.
June 3rd, 2004, 05:49 AM
Dunno about that. As a child of 17, I'm not exactly up to par on all the jargon.
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
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.
June 3rd, 2004, 05:51 AM
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.
June 3rd, 2004, 06:47 AM
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.
\"Life should NOT be a journey to the grave with the intention of arriving safely in an attractive and well preserved body, but rather to skid in sideways, Champagne in one hand - strawberries in the other, body thoroughly used up, totally worn out and screaming WOO HOO - What a Ride!\"
June 3rd, 2004, 09:27 AM
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...
for (key1=0; key1>keysize; key1++)
decrypt1 = decrypt(encrypted, key1);
for (key2=0; key2>keysize; key2++)
decrypt2 = decrypt(decrypt1, key2);
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...
June 3rd, 2004, 10:37 AM
"Triple Cypher", "1600 code"(Pennsylvania Avenue?)......................the concept has been around for a long time, and Mox is quite correct.
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.
The weak link is the human element?
Exactly. Either you hand the keys out, or the knowledge of how to derive them.
but you'd have to solve key distribution.
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"
I can think of several ways around this but they involve fanaticism, corruption, violence, chemicals or electricity?