PSST - Theory of Operation

PSST is Open Source

PSST is a fully open source software, meaning that all the algorithms, protocols and implementation are freely open to public, professional and academic review.

But doesn't this make PSST less secure?

No - the opposite is actually true.

People who market proprietary, closed-source software have apent a lot of money to deceive people into thinking that closed source offers greater protection.

But practical experience has proven this to be an absolute lie. However, there are marketing people who are still deliberately pushing this fraud.

The reason why open source software is more secure, is that it gets reviewed by thousands or millions of people, instead of dozens or hundreds (which is typically the case with proprietary code).

Throughout the open source community, a great many people get a lot of intellectual satisfaction from finding security weaknesses in other people's code, then telling the authors about these weaknesses, often also providing advice or even working code which fixes the weakness.

The result is that open source software can call on a far greater pool of experts to hone its security to near-bulletproof. For example, consider the OpenBSD operating system, which has only suffered one remote security exploit in seven years, compared to Microsoft (TM) Windows (TM) operating systems, each of which have suffered up to dozens of security exploits each year.

So if you study PSST source code, and find a security weakness, please Notify Me.

PSST Encryption

PSST relies totally on Public Key Cryptography for its encryption.

The public key algorithm is RSA, with a selectable key size between 1024 and 4096 bits. (Unless you're on a painfully slow computer, I recommend 4096 bits).

Fighting Man In The Middle Attacks

By its very design, PSST will not allow connections to other users without prior sharing of public keys. Yes - this is a bit of a pain, but I've chosen this strategy to protect against Man In The Middle Attacks.
Any encryption software that automatically exchanges keys in-band, without using out-of-band authentication, leaves you open to an intruder sitting between you and the other party, and substituting fake keys on both ends, thus allowing them to listen in to your conversations.
There are only two ways to guarantee privacy for end-end communication - either:



For me, certification has problems. It would require me to set up and operate a full-time server, which I'm just not prepared to do - not only because of the cost, but also because I don't want the legal and political exposure which would result from having a server with my name on it. Also, under New Zealand law, I could be forced on pain of jail time to compromise this server to facilitate government surveillance, or else other agencies could invade such a server themselves. For these reasons, using a certification model is totally not an option.

Session Establishment

Once a physical TCP connection is made, PSST goes through the following protocol to verify the identity of each party and secure the line:



Note from this protocol that there are two separate session keys - one for Alice talking to Bob, and another for Bob talking back to Alice. This is aimed at increasing the annoyance for attackers (eg governments). Because if, say, Bob resides in a hostile regime like UK or Australia, and is forced to hand over his private key, the attacker will only be able to decrypt the communication he has received from Alice. They still won't be able to decrypt what he himself has said to Alice, which could give him a strong legal protection.

Session Protocol

This is fairly cave-man. Basically, data is sent and received in chunks. If you study the Python source code (or, should I say, when you study the source code), you'll see that the communication methods guarantee the receipt of exact-sized chunks.

Each chunk has a variable length, and is prefixed by an identifier byte - a character which indicates whether this chunk is typed text, a voice fragment, a ping, or whatever. I have deliberately chosen not to document these here, because the protocol may be massively extended ih the near future. So please RTFS!

Session Termination

A chat session is terminated if any of the following occur: