- Website contains no details of the cryptography.

- Stores private key by: a) SHA384-ing your passphrase, and choosing a sub-sequence of the output depending on one bit of the output (this is poor for brute-force resistance compared to PB-KDF2), b) DES3 in CBC mode with a fixed IV and PKCS5 padding (insecure for CCA2 and providing no authenticity. This is vulnerable to recovery using the padding oracle attack).

- Messages are encrypted with RSA-PKCS1.5 in signing mode (in other words, RSASSA-PKCS1-v1_5, not RSAES-PKCS1-v1_5). That means messages are trivially recoverable through KPA.

So: don't use this for anything other than a toy. The crypto is misdesigned.

This is awesome feedback. Thank you very much. Your comments are noted and will be reflected in the next revision.

Are you serious? If you need secure messaging, surely you have other options than twitter?

Just copy and paste a PGP encrypted message to pastebin.ca and and tweet the link, if you must.

The broader motivation is to bring crypto to services that people are using, not the other way round.

Please describe a realistic scenario in which all of the following are true:

1) You are in imminent danger of being "shot in the face" or similarly harmed;

2) Your best means of salvation from (1) is communication via Twitter DM;

3) The absence of a means in which your message could be encrypted on the client side beyond the HTTPS connection to Twitter's servers would significantly increase the chance of (1).

This is a serious question.

Protests in which you are faced with policemen who have guns, and your survival depends on efficiently communicating and organising 1) without police intercepting your messages 2) without your communications being held as evidence against you in prosecution

1) https://twitter.com/ (and if someone can do a MITM on that, they can also do it on your cryptweet server)

2) environments where "your survival depends on efficiently communicating and organising" tend to ignore habeus corpus and standards of evidence. Realistically, your survival depends on external factors (your side winning) rather than hoping you and everyone you've been communicating with can withstand torture indefinitely.

2b) digitally signing a message reduces plausible deniability

You probably should have sat down and figured out how to encrypt your communications beforehand.

Ofcourse it'd be great if twitter did the job for you, but I don't necessarily see why it ought to be Twitters position to fulfill this edge case rather than say a protester who knows they are about to go into a life threatening scenario and need to organize--both beforehand and during the escapade.

XMPP+OTR

I just gave it a quick scan and found some issues: 1. PKCS1 verification looks vulnerable to a timing attack. 2. They're using plain RSA to encrypt message data without any padding like OAEP. This is not semantically secure. 3. They are not generating strong primes for RSA keys.

sweet jeebus. If you really need strong crypto for Twitter DM's, for god's sake just use PGP or GPG.

For the children.

I think you are discounting the level of thought and care that went into this. Meh, fail.

The level of care and thought put into creating a secure encryption scheme doesn't matter if the cryptography is broken. There's a reason you constantly hear cryptographers telling everyone to never invent their own crypto-systems; it's extremely difficult to do right.

so copy pasting PGP is somehow getting it right?

Parent made no mention of PGP, only that care and thought are meaningless if the crypto is flawed, which from the looks of some of the more knowledgable commenters, is the case.

It's understandable that you have a personal obligation to defend your friend, but it really isn't necessary. Sit back, relax, and allow the author to reflect on the constructive feedback here.

Why even bother breaking the crypto? They say right on the site that they use HTTP for public key retrieval so a MITM would simply serve up bogus public keys to the clients.

Assume for a moment that the implementation of the encryption and decryption processes are perfect. You've now completed the easiest part of the problem (to be very generous, let's call this 10% progress).

You still need to solve the problem of distributing public keys in a way that both parties can be sure they're receiving and sending messages from the correct entity. Do you trust all of the certification authorities that are automatically trusted in standard browser or operating system distributions? If not, how do you communicate public keys securely between two or more parties?

And how do you distribute the application and ensure that users aren't tricked into using a modified/backdoored version?

How do you ensure that users aren't tricked via a phishing attack into inadvertently handing over keys, downloading software from the attacker or otherwise compromising their own security?

If one party to a conversation is compromised, do you care if the identities and messages from other parties to the conversation become compromised as a flow-on effect?

How do you ensure that parties to a conversation are receiving all the messages sent -- is an adversary blocking random messages? Is an adversary reordering the delivery of messages to change the overall meaning of the conversation?

Have you carefully considered the implications of replay attacks?

Do you care if the system is leaking important side channel information such as the frequency of communication and time between responses?

Have you considered what users will resort to in the event that their communication method is deliberately denied? Will users fall back to a weaker method of communication? Will users tend to perform a Google search that returns a maliciously placed help/reference page that executes malware on their system?

Does the system have a means for users to expose the presence of an adversary that has compromised the system?

Algorithm implementations are just a minor (but still highly important) aspect of a full crypto system implementation.

Nice initial attempt. Besides the encryption issues mentioned here, here's my suggestion. This needs to be built into a mobile twitter application (non-jailbreak), I use pgp encryption/decryption programs on my iPhone and they are fast. Also, you should allow the use of any key server that the user wants, as known public key server access can be blocked by a country.

We built something very similar a couple years ago except all encryption/decryption is done broswer side, so no keys are ever sent through our server. Also, it uses actual tweets as opposed to DM's.

http://cryptwit.com

You can see an example here:

http://cryptwit.com/decrypt

Enter "yickster", then passphrase "hackernews"

Users need to verify the source code to cryptwit.com on every single page load to ensure that the "client side" code is not leaking the key/plaintext. There are many highly creative methods for leaking this information that would pass unnoticed through a quick code review. For this reason (amongst numerous others) the site is useless at best and harmful at worst (false sense of security for unsuspecting users).