Not much. Once you install the application, you have to register a unique username with the server. This username and your public key will be uploaded, and, if you consent, a hash of your phone number so your friends can find you by searching for it. Note that we never have access to your number in clear text.

That is it. No real name, no email address - nothing. We don't want to know who you are or what you do. All we ask is that you keep it legal.

If you choose to enable notifications about incoming messages, we need to store a unique device identifier so we can talk to the notification services. This identifier is stored encrypted on the servers. However, since the server could be compromised, the compromising party could potentially get hold of this identifier, which would allow them to identify the phone and maybe the phone owner. However, this identifier cannot be used to access data in any way.

Encrypted messages are stored on the server until you delete them. However, all encryption happens on the device, so we never have access to your messages in clear text and we also cannot decrypt them – all decryption happens on the end devices as well.

We only keep minimal logs for now to review service performance, since this is a new service and we collect them to debug and keep track of the usage and resources. We might disable them eventually.

There are three encryption steps before a message is sent.

A random message key is generated and the message is then encrypted using the blowfish algorithm and this random key.

The random key is encrypted with the recipient’s public key. This way it is made sure that only the intended receiver can decrypt the message key and with it the message.

A SHA2-hash is computed from the encrypted message and encrypted with the sender’s private key. This way, any tampering with the encrypted message can be detected.

For voice and video we use SRTP to encrypt the streaming data and ZRTP to negotiate the key used by SRTP.

This will use a different key for every call. So even if an attacker records the streamed data and manages to decrypt one audio or video message, it will not help them in the decryption of any other encoded stream. This is usually called "forward security".

No, we cannot. Your private key is needed to decrypt all messages sent to you. Since that key is generated and on your phone, nobody can read your messages, including us.

For the voice and video calls the keys are negotiated in a secure fashion between you and the contact you are calling. So we do not have the key and hence cannot listen to your conversation.

A public-private key pair is generated when you sign up for the application. The private key is immediately encrypted with your password and then stored. The security depends on the fact that this private key is never revealed to anyone. So we keep it encrypted all the time.

The message key is just a random string and a new one is generated for each message. It is a long standing fact in cryptography that only one-time keys can be considered secure. So we use one-time keys for every message.

For voice and video, a new key is negotiated between the two parties for each call and they are not stored at all.

We use RSA for public-private keys. We use blowfish as the main encryption algorithm and we use SHA2 for hashing.

At the time of this writing, all of them are considered secure, if implemented correctly. We only use open source libraries.

We do not use any of the libraries that come with the SDKs or operating systems, as we do not know who had their fingers in them.

For voice and video we use ZRTP to negotiate the key and SRTP with AES to encrypt the data stream.

RSA uses 2048-bit keys. Blowfish uses 16 rounds with 256-bit keys.

All messages are encrypted and are only decrypted for viewing by the receiver. For the decryption, the private key stored on the device is necessary. The private key itself is encrypted with your password. So even if someone steals the phone or gets access to the server, they would still need your password to decode the keys before they can access the messages.

Needless to say that the password is of course not stored in clear text, but as a hash. But the security of the whole process will depend on the strength of your password. So choose wisely, and keep a copy of your password safe and secure elsewhere; we cannot retrieve anything for you.

No. If you could, someone else could. So no, this is not possible. Since the private key is encrypted with this password, there is also no way to recover the private key. And therefore all messages are lost, too. Therefore, it is important to keep a copy of your password in a safe and secure location.

This is for tin-foil-hat-wearers. If you lose your password, the only option for you is to either create a new account, or to uninstall the application and start all over again. New keys will be generated, so you could not use them to retrieve old messages, even if you kept them.

The application has a “Password Hint” function. Use it.

Because RSA can only be considered secure if the encrypted message is not longer than the key itself. Since the keys are rather short, we feel it would be restricting ourselves too much if we force messages to be short enough. Hence the additional step with the random message key.

Using RSA and the random message key, we can make sure that the message itself cannot be read by anyone except the intended recipient. But as we have to consider the connection and the server compromised, we have to find a way to detect if someone tries to change the message. For example, they could just rip the complete message out and replace it with a different one.

Think of a hash like a checksum for the message. If the message changes the slightest bit, the checksum will change, too.

By encrypting the checksum with the sender private key we can guarantee that only this sender could have computed and sent this checksum. So, if the checksum of the received message does not match the one coming with the message, we know someone altered it.

If the application detects tampering, it will just disregard the corresponding messages.

You can login on any device that has PandaTalk installed with your username and password. The messages will then be synced to this device.

If there are lots of messages, it might take a bit of time for this to complete. PandaTalk tries to be smart about what it syncs first, but if there is a lot of data, then there is not much to be done – there are no miracles when it comes to send a lot of data over a network.

Land line calls are only encrypted while they are transmitted over the Internet. There is usually no encryption on the public telephone network.

The servers are in a data center in Europe. We are Germans and Australians based in Asia. We know that some Asian countries do not have a very good reputation when it comes to privacy and related topics, but it is a lot better than the 5-eyes-countries, right? And if someone like Mr. Snowden is seeking asylum in Russia, then maybe this an indication that things change in the world and it is time to overcome old clichés - or clichés in general, for that matter, if you ask us.