• Quick note - the problem with Youtube videos not embedding on the forum appears to have been fixed, thanks to ZiprHead. If you do still see problems let me know.

Remote Viewing Locker Encryption

kalen

Your Daddy
kalen
Joined
Mar 11, 2004
Messages
933
It seems to me someone is always breaking the encrypted description for the contents of the remote viewing locker. I sent Mr. Randi the following, and it would be interesting to see what others had to say about it.

Dear Mr. Randi,

This week's commentary (Feb 2) mentioned that the encryption scheme used for the object in your Remote Viewing Locker had been broken. I am not sure if you changed the method by which you encrypted the plaintext, but looking at the ciphertext (only letters), it still appears like it could be a weak encryption.

I understand the need to give some sort of code that describes the contents of the locker, so there is no way for you to underhandedly change the contents if somebody "sees"/guesses correctly.

Here is a way that guanantees a strong encryption, and lets anyone who is interested check the result themselves, when the contents are finally revealed. It will ensure no cheating by any party.

There is a program widely available for most computers called md5sum. It takes a string of characters, or the contents of a file, and produces 128-bit checksum based on that input. Small changes in the input produce radically different checksums. Altering the input to produce the same checksum is basically impossible. Altering the input to produce the same checksum while the input is not gibberish is impossible.

Here's how it would work if I were to do this on my computer. It's a linux
machine, but it would work similar to windows.

First make a file, locker_contents.txt, say, and write the description of the item in the file (human brain, say). Then, run md5sum on the file. The output will look something like

53c292a2f55a81567b06e5972ad0590d

and this is what you would publish on your website. If you ever wanted to reveal the contents of the locker, then you would publish the original file locker_contents.txt. People could then even run md5sum on locker_contents.txt themselves to see if the published checksum matches.

The only way that is remotely practical to foil this scheme is to try alot of words, maybe using a dictionary, and hope that a match with the checksum occurs. With comupters nowadays, this would not take a really long time. But there is still a way!! Not only in locker_contents.txt do you put the description, but also a bit of goobledegook. eg. Instead of

human brain

write

hjhsd lskdjflskjdf lsdkjflksdjf sdlkfjslkdjallalk
jlksjdfjjfdk77865 HUMAN BRAIN 7884jlkdffhslldkjfs
sdfsd9)sdfjslkdf*ms.dkfkjajjslkdfjkdjfsllalkghs,p

Here, it is clear what is in the locker, but now the dictionary attack is no longer a threat. The checksum is still only 32 characters long no matter how big locker_contents.txt gets.

I hope this solves your encryption problems. I'd be more than happy to clarify anything I've written here. It's a neat idea. I'm not sure if checksums have been used in quite this way before, though it will work great.

As a demonstration, here is the checksum of a file that describes what is in *my* Remote Viewing Locker:

4920bf22bef0929cb42efef1c9f39244

Based on this alone, there is no way to find out. (If you really want to
know, find the locker_contents.txt file here:

http://hep.physics.utoronto.ca/~fmartens/locker_contents.txt

All the best,

Kalen
Click to expand...
 
Last edited:
As long as he knows one of them in principle, this will solve the encryption problem once and for all. Lots of data has been protected with essentially the same technology. Great idea, kalen!
 
Altering the input to an MD5 sum and getting out the same hash is not impossible. If I recall correctly, MD5 was recently broken, and is no longer considered a secure hashing function. Same with SHA hashing. Here is a resource about sha hashing being broken:
http://www.schneier.com/blog/archives/2005/02/sha1_broken.html
It doesn't really make sense anyway to use a hashing function to encrypt data, since the solution is not unique for each input, thus making it impossible to know what was really said. A one time pad can be used to encrypt the contents of the locker, and no one will figure that out. A one time pad is certainly unbreakable, and given the key there is only one solution given the cipher text. There are other secure ways other than one time pads like AES for encrypting text without hashing it. This seems like a more reasonable solution for encrypting the contents of the locker.
 
The problem with a one-time-pad as with all other codes and ciphers that do not depend on large primary numbers is that both parties must have the same one-time pad.

On the other hand I could generate pseudo random numbers via maths formula and encode and send you the message. Then later I tell you how to generate the random numbers and you can decode the message.

I could even tell you the formula in advance. Just leave out two 10 digit numbers, plus a few other minor details. That would leave me unable to change the formula to get another message.
 
HappyCat said:
Altering the input to an MD5 sum and getting out the same hash is not impossible. If I recall correctly, MD5 was recently broken, and is no longer considered a secure hashing function. Same with SHA hashing. Here is a resource about sha hashing being broken:
http://www.schneier.com/blog/archives/2005/02/sha1_broken.html
It doesn't really make sense anyway to use a hashing function to encrypt data, since the solution is not unique for each input, thus making it impossible to know what was really said. A one time pad can be used to encrypt the contents of the locker, and no one will figure that out. A one time pad is certainly unbreakable, and given the key there is only one solution given the cipher text. There are other secure ways other than one time pads like AES for encrypting text without hashing it. This seems like a more reasonable solution for encrypting the contents of the locker.
Click to expand...

No, he can't use a one time pad- the whole point of the encryption is that later, he wants to be able to prove what was in the locker! That way, if the remote viewers said "It's a blender," and he said, "No, it's not," he can prove that he didn't just open the locker and switch the blender with something else.

The problem with the one time pad is that since Randi's the only one who has the key, he can make the encrypted message correspond to whatever plaintext he wants! A one-time pad has a one-to-one-to-one correspondence between plaintexts, ciphertexts, and keys. So the ciphertext JMEFUIT would be BLENDER with one key, SPATULA with another... this completely negates the purpose of publishing a cipher at all.

A one-time-pad is exactly what you don't want.
 
HappyCat said:
Altering the input to an MD5 sum and getting out the same hash is not impossible. If I recall correctly, MD5 was recently broken, and is no longer considered a secure hashing function. Same with SHA hashing. Here is a resource about sha hashing being broken:
http://www.schneier.com/blog/archives/2005/02/sha1_broken.html
It doesn't really make sense anyway to use a hashing function to encrypt data, since the solution is not unique for each input, thus making it impossible to know what was really said. A one time pad can be used to encrypt the contents of the locker, and no one will figure that out. A one time pad is certainly unbreakable, and given the key there is only one solution given the cipher text. There are other secure ways other than one time pads like AES for encrypting text without hashing it. This seems like a more reasonable solution for encrypting the contents of the locker.
Click to expand...

There are an infinite number of possible files (in theory, at least), and only 2^128 possible hashes. Therefore, there is an infinite number of files with the same hash. The trick, however, would be to find a file with a similar format as shown above (ie. 3 lines, all ASCII, real english words in caps surrounded by gibberish) that has the same hash. This is not in the realm of possibilities.

I have to emphasize that the point here is not to encrypt the file that describes the locker contents, but to ensure the integrity of the file without having to distribute keys.
 
Use this instead. Encrypt a plain text file using PGP, then publish the encrypted file. Anyone interested can download and save a copy of the file. When it is time to prove the psychic wrong, just publish the public key.

Use a new private key for each time the locker contents are changed. No problem, and the encryption is guaranteed to be far stronger than anything the average Joe can think up (or crack.)

Randi may be a great magician, and a great debunker. That doesn't make him an encryption specialist. I'm NOT knocking him. Encryption specialists aren't necessarily good magicians, either.

Added on preview:
This also addresses Kalen's objection. The point of all of this is to provide proof that the contents weren't changed after the fact. An encrypted file using strong encryption does just this. Strong encryption doesn't have ambiguities that would allow two keys to decode one encrypted message into two different cleartext messages.

Distributing the key is easy, as well. Just post it for download just like any other file. Post the encrypted file for download. When a psychic makes a guess, post the key. The psychic should download the encrypted file before making the attempt, then download the key afterwards. If the key doesn't decrypt the file, then somebody cheated.
 
I don't disagree with MortFurd as to the security issue. I haven't used PGP myself, so I wouldn't know how simple it might be to use. The link provided to 'gpg4win' suggests that it's for Windows, something that I don't use.I'm sure there are linux / Mac versions of PGP.

Q: will all PGP programs give the same plaintext when given the ciphertext and key?

If one has to configure this and that, then the simplicity is lost.

For added security with the method I suggested, just specify that the first line must contain a specific string. eg.

JREF REMOTE VIEWING LOCKER CONTENTS
hjhsd lskdjflskjdf lsdkjflksdjf sdlkfjslkdjallalk
jlksjdfjjfdk77865 HUMAN BRAIN 7884jlkdffhslldkjfs
sdfsd9)sdfjslkdf*ms.dkfkjajjslkdfjkdjfsllalkghs,p

I guarantee the next smallest file with the same md5 checksum and the same first line will not be 4 lines of ASCII.
 
kalen said:
I don't disagree with MortFurd as to the security issue. I haven't used PGP myself, so I wouldn't know how simple it might be to use. The link provided to 'gpg4win' suggests that it's for Windows, something that I don't use.I'm sure there are linux / Mac versions of PGP.

Q: will all PGP programs give the same plaintext when given the ciphertext and key?

If one has to configure this and that, then the simplicity is lost.

For added security with the method I suggested, just specify that the first line must contain a specific string. eg.

JREF REMOTE VIEWING LOCKER CONTENTS
hjhsd lskdjflskjdf lsdkjflksdjf sdlkfjslkdjallalk
jlksjdfjjfdk77865 HUMAN BRAIN 7884jlkdffhslldkjfs
sdfsd9)sdfjslkdf*ms.dkfkjajjslkdfjkdjfsllalkghs,p

I guarantee the next smallest file with the same md5 checksum and the same first line will not be 4 lines of ASCII.
Click to expand...
Instead of including garbage characters to lengthen the text to be hashed/encrypted, there should be a long plaintext message. Otherwise, someone could accuse Randi of artificially inflating the number of seemingly valid messages that hash (or decrypt) to the same value. Remember that this whole validation process has to be secure and transparent.
 
delphi_ote said:
...
Otherwise, someone could accuse Randi of artificially inflating the number of seemingly valid messages that hash (or decrypt) to the same value. ...
Click to expand...

Somebody could accuse him of that, but it would of course have no basis if one requires 4 lines of ASCII with some formatting and other requirements.

The purist will use strong encryption as MortFund suggests.

But, in the end, there is absolutely nothing one can do to stop some people of accusing Randi of cheating.
 
kalen said:
Somebody could accuse him of that, but it would of course have no basis if one requires 4 lines of ASCII with some formatting and other requirements.

The purist will use strong encryption as MortFund suggests.

But, in the end, there is absolutely nothing one can do to stop some people of accusing Randi of cheating.
Click to expand...
If you include a large number of arbitrary characters, that will combinatorially increase the number of seemingly valid collisions. It's a valid complaint.
 
A few small comments:

kalen used the word "checksum" to describe the md5sum algorithm. Checksum in the past referred to a summation of all the data in a file that resulted in a value that could be used to detect unintended changes in the file. md5 doesn't use this kind of simple algorithm. But the word "checksum" seems to be used today to refer to the output of a hashing function of some sort and in fact the wikipedia article on md6 seemed to use it that way. So whether I like it or not the scope of the word "checksum" seems to have increased.

MortFurd's post:
I understand that publishing the encrypted version of the file seems like the most robust way to go here but I didn't understand why public key cryptography is of value for this purpose.

I considered a variety of scenarios trying to figure out what you were recommending but none of them made any sense to me. It seems like all that is necessary is to encrypt the message using a standard encryption program and publish the encrypted message. When it comes time to check Randi just publishes the key.

Warning, not much of value follows. I was just trying to figure out what MF was suggesting and wrote down my musings on that.

Scenario one:
psychic produces public and private keys and transmits public key to Randi and psychic can decrypt file whenever he wants because he's got the private key.

Scenario two:
Randi produces public and private key and provides psychic with public key. Psychic can never decrypt file because he's doesn't have the private key.

Scenario three:
Randi produces public and private key, encrypts and publishes encrypted file and provides psychic with public key. When psychic claims to have determined plain text psychic encrypts results and passes them back to Randi. Randi decrypts psychic's attempt at plain text and determines if psychic has correctly determined the hidden plain text. Still doesn't make sense why doesn't psychic just send his guess to Randi in the clear.
 
delphi_ote said:
If you include a large number of arbitrary characters, that will combinatorially increase the number of seemingly valid collisions. It's a valid complaint.
Click to expand...

I will agree. Twenty-six arbitrary lower case characters means 26^26 possible combinations. Maybe there are too many random characters....

Is there a happy medium that will prevent a dictionary style attack, but be small enough to make the probability of a collision small? Ten characters, maybe?

ETA: Maybe the rule of thumb should be: the probability of a collision is much smaller than a random guess would be of the locker contents.
 
Last edited:
Another thought:

With any these methods, the weakest link is probably the security of the computer on which the plaintext file (or the PGP key) resides.
 
There is a very specific reason that Randi does not use a technological solution like any of the above. In fact, he has explicitly stated why. I believe his reasoning was quoted in the article written by the gentleman who cracked the previous code. A technological solution, while secure, is not understood by a great many people. The results have to be clear and above dispute to anyone. A technophobe, or technology neophyte will just say, "you can make that computer mumbo jumbo say whatever you want." It doesn't matter how hard you try to explain the encryption to him, he will not accept it, because he doesn't understand it. That's why Randi's previous coding was done the way it was. So that once Randi has revealed the key, any lummox who can read can go to a public library and find the information himself.
 
Gr8wight said:
There is a very specific reason that Randi does not use a technological solution like any of the above. In fact, he has explicitly stated why. I believe his reasoning was quoted in the article written by the gentleman who cracked the previous code. A technological solution, while secure, is not understood by a great many people. The results have to be clear and above dispute to anyone. A technophobe, or technology neophyte will just say, "you can make that computer mumbo jumbo say whatever you want." It doesn't matter how hard you try to explain the encryption to him, he will not accept it, because he doesn't understand it. That's why Randi's previous coding was done the way it was. So that once Randi has revealed the key, any lummox who can read can go to a public library and find the information himself.
Click to expand...
But if the current code is broken, these principles might help.
 
davefoc said:
I understand that publishing the encrypted version of the file seems like the most robust way to go here but I didn't understand why public key cryptography is of value for this purpose.
Click to expand...

I've only a minimal understanding here, but as far as I recall, there's three subtly different functions of encryption:

Encryption: you send me a message, and no-one else can read it

Authentication: you send me a message, and I *know* that no-one else sent it pretending to be you

Non-repudiation: you send a message, and can't later pretend you didn't.

I believe what we'd need for a remote viewing test is that the description be both encrypted (so the would-be psychic can't read it), and non-repuditable (so Randi can't later change what it decrypts to). If Randi publishes the encrypted message now, and the decryption key later, is it possible that an alternate key will decrypt the message to a different but still English plaintext? Obviously, with a one-time pad, it is, which is why one-time pads are provably perfect for encryption, but utterly useless for authentication and non-repudiation. There are digital signatures which might work for non-repuditation, but not so hot for encryption. So for this application, we either need a system which does both, or we need to combine two systems. But I'm not the best person to figure out what that system is. And of course, for this application in particular, we need something transparent enough to be trusted by the would-be psychic, who may not be so much a math whiz...
 
rudar: You forgot one, which is the important one here:

Integrity: Beeing shure that the message has not been altered between sender (Randi posting it the first time) and receiver (Randi releasing it when time comes).
 
You must log in or register to reply here.

Back
Top Bottom