SixChat (TM) is a revolutionary product from Sixscape Communications. It is the first implementation of an IETF open standard (RFC 3923) that has been around since 2004. It is by far the most secure chat app available for the Internet. It uses the same technology (S/MIME) used to secure E-mail, but applied to every XMPP (Jabber) chat message. Each message is encrypted and digitally signed inside the sending app, and goes through any intermediary XMPP servers (e.g. eJabberD) transparently (but fully secure). When the message arrives at the recipient app, it is decrypted and the digital signature is verified. This provides true end-to-end security and sender-to-recipient authentication. Your chat conversation is completely private, and you both know for certain who you are communicating with. We even support secure group chat. As with S/MIME Email, each message is encrypted once with a symmetric session key, then that session key is encrypted with the public key of all recipients (including yourself). Each recipient can decrypt the encrypted session key with their own private key, and then decrypt the message with the recovered session key.

To the best of our knowledge, we are the only company to have ever implemented this IETF standard (even though it is 13 years old). No other secure chat system is based on IETF end-to-end S/MIME or digital certificates. For truly secure end-to-end chat, a system must have the following:

  • Individual X,509 client certs for each participant, trusted by all other participants, ideally published in LDAP
  • Private keys for each participant corresponding to their client cert, kept in their possession, ideally in a FIPS 140-2 certified hardware cryptographic token.
  • Ideally the key material (certificate and private key) should be published (encrypted) in PKCS12 format to expedite and simplify installation of key material on each client
  • S/MIME style digital signatures and digital envelopes for each message
  • Some way for each user to securely and easily request and obtain client certs that support XMPP S/MIME

No other secure chat scheme meets these requirements. Most do not allow the users to possess and control their own keys. No other system is based on X.509 certificates and PKI. No other system is based on an IETF standard. No other system allows keeping the private key in a hardware cryptographic token.

Today online chat is dominated by a number of incompatible proprietary protocols. This is similar to the situation in the early days of E-mail, with MS-Mail (from Microsoft), MCI Mail, cc:Mail, etc. Eventually all of these were phased out in favor of the IETF standards (SMTP and IMAP). This often happens in the Internet. Open standards always eventually win out and become dominant. The official IETF standard for instant message is XMPP (formerly known as Jabber). No one company owns or controls it, and many IETF engineers have refined it and improved it until it is the best and most powerful instant messaging system available (from a technical viewpoint). S/MIME is the IETF open standard for end-to-end security. X.509 certificates are the IETF open standard for identity management and key exchange.

Nobody else has implemented what should be the obvious technology due to the difficulty and cost of creating and managing millions or even billions of client certs with current (web based) CA designs. Sixscape’s pioneering Identity Registration Protocol solves that problem by making it possible and affordable to issue any number of client certificates. Even devices can obtain a client cert via IRP and do highly secure XMPP messaging to or from any other XMPP node (that supports S/MIME). IRP is already available on our Sixscape Certificate Manager, and can be added to any CA (including public hierarchy CAs). With IRP, the client certs needed to make this work and scale are possible.

A number of XMPP clients have implemented an “end-to-end encryption” scheme called OTR (“Off The Record”). Unlike S/MIME, OTR is not based on X.509 certificates or PKI, and there is no real authentication. in fact, one of OTR’s “benefits” is the ability to deny having ever sent a message, which is the opposite of knowing for certain who you are communicating with. OTR may be of value and interest to politicians, but corporations and government agencies are more concerned with knowing for certain who is communicating than with plausible deniability. We will later include support for OTR “security” to be able to interoperate with XMPP clients that only support OTR, but if you are communicating with another user that has XMPP S/MIME (e.g. SixChat), that is a dramatically better level of security.

In the encryption scheme for WhatsApp, the vendor controls and owns all the keys. This is a very bad design. They could use those keys themselves to compromise your privacy, or provide them to third parties without your permission or even knowledge (regardless of any claims to the contrary). Ideally your private key should be in your possession, that should be the only copy of that key, and for highest security it should exist only in a FIPS-140-2 certified hardware token.


We have implemented SixChat for Android and iOS using Xamarin (based on C#.Net) for high performance, reliability and security. We will soon be releasing versions for MacOS and Windows, that are fully interoperable with the mobile versions. If you are chatting with someone using a client that does not support S/MIME security, you will be able to communicate in a non-secure manner. XMPP will normally be protected with TLS (but that protects only a single link, e.g. XMPP client to local XMPP server). There is no way to achieve end-to-end security with TLS.

Later we will implement and end-to-end direct XMPP user agent (that can originate or accept connections) over IPv6. No intermediary server is needed in this case. With that, TLS is end-to-end since there is only a single link, but even then S/MIME will protect the messages (e.g. in storage or archive), and provide a digital signature on each message (not provided by TLS). We will support group chat by creating mesh connections between all participants, or optionally via an intermediary server.

All Sixscape products are fully IPv6 compliant, and will work in IPv4-only, dual stack and IPv6-only networks. The end-to-end direct mode will work only if all participants have IPv6.


SixChat Brochure (PDF 129 KB)