[1] http://en.wikipedia.org/wiki/Password-authenticated_key_agre...
Don't get creative and start rolling your own zero-knowledge proof of passwords here. It's really easy to get wrong. Use a very-well peer-reviewed Augmented PAKE algorithm.
THE NAIVE WRONG WAY for Alice to prove to Bob that she knows the Password (but might look good at first glance) is for Alice to send to Bob HMAC(Password, Alice's Public Key) because then if Bob doesn't know Password, he can still start bruit-forcing guesses without further interaction with Alice. On average, it will take the Stasi an afternoon to bruit-force Password after pretending once to be Bob, and after that they can impersonate Alice when talking to Bob. It's very unlikely Alice will ever mention to Bob the one failed authentication, and nearly impossible that she'll mention it within the window of time they have before the Stasi bruit-force the password.
Use an Augmented PAKE instead of a balanced PAKE, because you should use an Augmented PAKE for users to authenticate themselves to you, and that way you can share one implementation for both purposes and expose yourself to half the potential bugs. With a Balanced PAKE, if an attacker gets read-only access to your server's password store, they could immediately authenticate themselves to your service and upload more public keys as the user. An Augmented PAKE in this case would slow down an attacker by forcing the attacker to bruit-force the passwords, and would completely save the 1% of your users who use passwords with 80 or more bits of entropy.
Single DES is absurd in this day and age, and password-based encryption is worse. Jack the Ripper renders this no stronger than a secret decoder ring, and a thousand times more dangerous because of the false sense of security.
Edit: I'm probably overly sensitive. One of my ex girlfriends has several uncles, three of whom went to prison for not belonging to the state religion. Thankfully they didn't live in one of the countries where such things are currently capital offenses, and were able to immigrate to more tolerant countries.
Perfect forward secrecy needs to be the default, perhaps with an option to switch to a stored history mode. Use 256-bit AES in GCM mode.
For the stored mode, don't use password-based-encryption, but rather generate a GnuPG key pair on each device the first time the client is used. 4096-bit RSA/El Gamal or 256-bit ECC should be the minimum key sizes. The first time a new device is added to an account, upload its public key and tell the user they need to "authorize" this device from one of their existing devices in order to see past conversations. When they log in from another device, ask them if they've really added the new device, and if they respond that they have, have the old device add the new device as a recipient to all of the existing messages. This can be done by sending only the preamble of each message to the old client for it to decrypt the symmetric key, and re-encrypt the session key for the new recipient, and send the encrypted session key back to the server. Don't take any shortcuts. If a conversation is between Alice and Bob, and Alice adds a new device, never ask Bob to re-encrypt old conversations for Alice's new device, because Bob's answer will always be "Mein StasiPhone? I dunno if Alice added a new device. Fuck it, sure, why wouldn't I give Alice's new phone access?"
If your product as currently implemented gets many users, it's a statistical certainty that some of them will go to prison due to the false sense of security you're giving them. I hope they're all going to nice prisons in respectable countries and for doing things that are objectively evil.