Zach, it does not matter which type you use. Whatever is used to has to translate the message back into plaintext, thus there is no point to this hack whatsoever.

You could store the key and the encryption type in the database or in a file somewhere. Or even make it an extra option for two users to create their own keys to be shared with eachother.

Its more than possible to encrypt them so an external source who may gain access to your database will not be able to read their contents.

How is a user going to tell which encryption (or whatever you want to call it) you're using?

Ofcourse, anyone can translate it back, else this hack wouldn't even be possible.

I didn't say it was easy, just possible.

@Zach thats a very nice guide, but users would need to install it first, wouldn't they?

EDIT I'm too slow today :/

I was replying to Trigunflame's post, but you just reply too fast :)

That's my point. If a person got access to the db, what is to prevent them from using the key itself.

All they would have to do is try different variations of encryptions, and arragements of the keys in relation to the data encrypted.

Whats worse, if they were a member at vbulletin.org, they will Know the arrangement of the keys, just by viewing this hack.

Like I said, It does not need to be stored in the database. I would assume if someone needs something like that encrypted they will give the second user the key so they can decrypt it.

But would the user installing this hack also need to install Mcrypt, or did I just read that wrong?

Mcrypt is compiled in most installations on *Nix.

And yes they would need it... however, there is no point to it. If you did use a key encryption, I would do it somewhat like;

encryption(plaintext password . PMData . passwordHashinVbulletin)

there has to be some form of user input, or they would be no point; as zach mentioned.