Please enable JS


Discreete Linux is typically used for one of the following needs:

Not only documents and information are in the crosshairs of trojan attacks. In the same way, or even more, attempts are made to steal the secret encryption keys themselves. The victims of such attacks often consider themselves in deceptive security: While they encrypt all email communication with GnuPG, the attacker, which gained access to the private key (and if need be the password, it is protected with), can easily decrypt everything – even communication, that was transmitted before he gained access to the key.

If encryption needs to be highly reliable, the encryption process itself must not take place on a system, the attacker can gain access to. That’s why the GnuPG private keys in Discreete Linux are stored inside the so called Cryptoboxes (see section “Features”). As the keys are only accessible in Discreete Linux’s isolated offline environment, they of course can not be used by an email program like Thunderbird/Eenigma. In the Discreete workflow, files containing the messages are encrypted locally and later on sent as an email attachment from a computer with internet-access. When receiving encrypted messages, the process goes vice versa: The attachments have to be brought into the Discreete environment and can be decrypted and stored there – out of the trojans reach. The inconvenience compared to using the keys on the email computer itself is obvious. But if your physical integrity, freedom or even life depend on trustworthy encryption, a small inconvenience is certainly acceptable.

Common GnuPG frontends like Seahorse are not designed to work this way. That’s why the Discreete Linux project developed it’s own GnuPG frontend, to make the workflow easier for the users. Also it is one of the most functional GnuPG frontends existing.
If you until now have used GnuPG on a computer connected to the internet and are concerned that it might have been infected with trojan software, you maybe want to generate a new pair of keys and stop using the old one.

This is the most obvious usecase: Sensitive data is stored and edited only inside the Cryptobox, which in turn is only opened in the secure, isolated Discreete Linux system. This way attacks with trojan software have no opportunity, to access your data. For exchanging (encrypted) messages and documents with other people, see the tab “SECURE GNUPG EN-/DECRYPTION ENVIRONMENT”

If you run an OpenSSL Certification Authority or use GnuPG to create digital signatures, e.g. to prove the integrity of software packages, other people rely on the trustworthiness of your signatures.
Therefore the integrity of your private key(s) is a very high value. If an attacker gains access to your private key (and the related password), he could e.g. sign and distribute manipulated software in your name and all users would trust it, because it would have your correct signature. Or he could issue fake certificates in your CA’s name to intercept other users SSL connections.

But the problem actually starts earlier, namely when the signing key is generated. Incidents like the introduction of the Dual EC DRBG Cryptotrojan by the NSA show, that attackers want to force victims to generate weak keys that can easily be broken. Therefore private keys have to be generated in a trustworthy environment with verified software. And should, in the best case, never leave that trusworthy, protected environment.
Discreete Linux’s Cryptoboxes provide both: A secure environment and all open source software needed, to generate the keys – and a secure environment to store the keys in and process the signing of files or certificates itself.