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:
- Share the public keys in advance, out of band
OR
- Use and trust a 3rd party certification authority.
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:
- Alice sends Bob an SHA hash of her public key
- Bob compares this hash to a hash of his own copy of Alice's public key
- If these hashes don't match, the connection is aborted.
- Ditto from Bob back to Alice
- Alice then generates a random 256-bit session key, plus a Blowfish CFB IV,
encrypts these against Bob's public key, then sends these to Bob
- Alice then signs these against her public key (proving that she possesses
the right matching private key), encrypts this signature against Bob's
public key, then sends this to Bob
- Bob decrypts all this, then verifies the session key and IV against Alice's
signature. If the signature is not correct, the session is aborted.
- Ditto again from Bob to Alice
- The session is now secured and open for traffic
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:
- Any attempt to send any packet fails (eg because physical TCP connection
has been broken),
- A ping packet hasn't been received from the other party in 90 seconds.