Opis kryteriów

SECURE MESSAGING SCORECARD

  • Encrypted in transit?

    This criterion requires that all user communications are encrypted along all the links in the communication path. Note that we are not requiring encryption of data that is transmitted on a company network, though that is ideal. We do not require that metadata (such as user names or addresses) is encrypted.

  • Encrypted so the provider can’t read it?

    This criterion requires that all user communications are end-to-end encrypted. This means the keys necessary to decrypt messages must be generated and stored at the endpoints (i.e. by users, not by servers). The keys should never leave endpoints except with explicit user action, such as to backup a key or synchronize keys between two devices. It is fine if users’ public keys are exchanged using a centralized server.

  • Can you verify contacts’ identities?

    This criterion requires that a built-in method exists for users to verify the identity of correspondents they are speaking with and the integrity of the channel, even if the service provider or other third parties are compromised. Two acceptable solutions are:

    • An interface for users to view the fingerprint (hash) of their correspondent’s public keys as well as their own, which users can verify manually or out-of-band.
    • A key exchange protocol with a short-authentication-string comparison, such as the Socialist Millionaire’s protocol.

    Other solutions are possible, but any solution must verify a binding between users and the cryptographic channel which has been set up. For the scorecard, we are simply requiring that a mechanism is implemented and not evaluating the usability and security of that mechanism.

  • Are past comms secure if your keys are stolen?

    This criterion requires that the app provide forward secrecy, that is, all communications must be encrypted with ephemeral keys which are routinely deleted (along with the random values used to derive them). It is imperative that these keys cannot be reconstructed after the fact by anybody even given access to both parties’ long-term private keys, ensuring that if users choose to delete their local copies of correspondence, they are permanently deleted. Note that this criterion requires criterion 2, end-to-end encryption.

    Note: For this phase of the campaign, we accept a hybrid forward-secrecy approach with forward secrecy on the transport layer (for example through TLS with a Diffie-Hellman cipher suite) and non-forward-secret end-to-end encryption, plus an explicit guarantee that ciphertexts are not logged by the provider. This is a compromise as it requires trusting the provider not to log ciphertexts, but we prefer this setup to having no forward secrecy at all.

  • Is the client code open to independent review?

    This criterion requires that sufficient source-code has been published that a compatible implementation can be independently compiled. Although it is preferable, we do not require the code to be released under any specific free/open source license. We only require that all code which could affect the communication and encryption performed by the client is available for review in order to detect bugs, back doors, and structural problems. Note: when tools are provided by an operating system vendor, we only require code for the tool and not the entire OS. This is a compromise, but the task of securing OSes and updates to OSes is beyond the scope of this project.

  • Is the server code open for independent review?

    This criterion requires that server side code providing service to the clients is also available for review. It doesn’t need to be published or released under any specific free/open source license. It means that server side code can be a subject to an audit.

  • Is security design properly documented?

    This criterion requires clear and detailed explanations of the cryptography used by the application. Preferably this should take the form of a white-paper written for review by an audience of professional cryptographers. This must provide answers to the following questions:

    • Which algorithms and parameters (such as key sizes or elliptic curve groups) are used in every step of the encryption and authentication process
    • How keys are generated, stored, and exchanged between users
    • The life-cycle of keys and the process for users to change or revoke their key
    • A clear statement of the properties and protections the software aims to provide (implicitly, this tends to also provide a threat model, though it’s good to have an explicit threat model too). This should also include a clear statement of scenarios in which the protocol is not secure.
  • Has there been any recent code audit?

    This criterion requires an independent security review has been performed within the 12 months prior to evaluation. This review must cover both the design and the implementation of the app and must be performed by a named auditing party that is independent of the tool’s main development team. Audits by an independent security team within a large organization are sufficient. Recognizing that unpublished audits can be valuable, we do not require that the results of the audit have been made public, only that a named party is willing to verify that the audit took place.

  • Is the data safe from legal threats like the disclosure under USA Patriot Act?

    This criterion requires that the content of data transmission between parties is never stored in a form readable by the provider. This doesn’t mean that users’ identities, ip addresses or the fact of communication between parties are protected. Ideally, the communication should take place in peer to peer fashion.

  • Strong encryption

    Encryption uses keys of at least 128 bits in length for symmetric encryption as well as at least 2048 bits in length for RSA/DSA keys and at least 256 bits in length for elliptic curve keys and hash functions.

  • Simultanous use of many independent cryptographic algorithms

    This criterion requires that the app provides increased strangth encryption by using simultanously at least two different cryptographic algorithms for symmetric data encryption process. It is fine if the app uses the same key for different algorithms. It also counts if the app uses different algorithms for different transmission channels.

  • Secure chat

    The app has secure chat feature. The chat content cannot be stored in unencrypted form anywhere on the client or on the server.

  • Secure file sharing

    The app has secure file sharing feature ensuring that the file content is transfered in an encrypted form across the network. The file doesn’t need to be encrypted when stored on the client device. The file content has to be encrypted when stored on the server.

  • Secure audio/video

    The app has secure audio/video communication feature. The real time communication channel between parties is encrypted with symmetric encryption with the key of at least 128 bits in size.

  • Web browser access

    The app is accessible from the web browser. This also counts even if only one browser type is able to access the app.

  • Mobile access

    The app is accessible form mobile devices. This also counts even if only one mobile device type is able to access the app.

Criterion Safreum Signal Silent Phone Telegram Threema RetroShare Pidgin
Encrypted in transit?

+

+

+

+

+

+

+

Encrypted so the provider can’t read it?

+

+

+

+

+

+

+

Can you verify contacts’ identities?

+

+

+

+

+

+

+

Are past comms secure if your keys are stolen?

+

+

+

+

+

+

+

Is the client code open to independent review?

+

+

+

+

+

+

Is the server code open for independent review?

+

+

+

+

+

Is security design properly documented?

+

+

+

+

+

+

+

Has there been any recent code audit?

+

+

+

+

+

Safe from legal threats?

+

+

+

+

+

Strong encryption?

+

+

+

+

+

+

Many independent cryptographic algorithms?

+

+

Secure chat?

+

+

+

+

+

+

Secure file sharing?

+

+

+

+

+

+

Secure audio/video?

+

+

Web browser access?

+

+

Mobile access

+

+

+

+

+

+