From /tech/ Wiki
Jump to navigationJump to search

Encryption covers many areas of computing and covers many levels of security.

Disk encryption

Tip: The Arch Linux Wiki has comprehensive articles on all manners of disk encryption more detailed than anything that could be provided here.
Warning: Most disk encryption setups keep the /boot partition unencrypted. The boot partition contains the boot loader which is loaded by firmware, either BIOS or UEFI. It also contains the kernel and initramfs image. If any of these components are missing or inaccessible (say, because they are encrypted) then the system will not boot. There is a workaround: GRUB supports a feature called cryptdisk by which the decryption passphrase is passed to GRUB so that it can load the kernel. In this situation GRUB cannot reside under /boot - these are your options:
  • By using the GRUB payload with libreboot or coreboot. In this case, GRUB is embedded in the flash chip. This will not stop a sufficiently skilled hostile actor with physical access from tampering with the boot loader.
  • By using an external device such as a flash drive or smart card to store GRUB. You can keep the device on your person to prevent the above issue.
Warning: Encryption is only as strong as your passphrase. Make sure to practice good password etiquette.
Warning: Veracrypt is proprietary software (specifically source-available freeware) and should not be used.

Disk encryption makes your drive unreadable before a decryption key is provided on boot. This prevents unauthorized guests from accessing or tampering with your data.

Disk encryption will not benefit you while your device is online because your encryption key is stored in RAM.

usbkill and Silk Guardian can be used to quickly turn off your device and clear RAM. usbkill was created in response to the arrest of Ross Ulbricht, who was using disk encryption at the time.


dm-crypt + LUKS

Most Linux distributions provide encryption option during their installation process.

dm-crypt and LUKS can be set up using the cryptsetup utility.

dm-crypt + LUKS is the recommended encryption solution for Linux. LVM is optional, but recommended.

Take note of the --iter-time parameter while creating a dm-crypt volume. This is a delay (in milliseconds) to guard against brute force attacks, which the FBI have shown archived that they have problems attacking. archived. It should be set to at least 500 (1/2 second), preferably higher.


Android supports disk encryption via dm-crypt[1].

Be aware that any phone which can be flashed with a custom rom can also be flashed with a malicious rom (i.e. any phone which LineageOS can be flashed on can also be flashed with fbi-nsa-fiveeyes.rom). Any phone locked to a telco provider (e.g. AT&T only) is probably compromised by US LEA too.

Your pincode sucks btw.

Crypto Wars

Crypto Wars

Crypto Wars II

Cryptowars 2.0 began in February 2016 after the FBI recovered an encrypted iPhone from a car owned by the mother of a terrorist. The FBI demanded Apple write and sign custom firmware to flash upon the iPhone which would:

  • Allow more than 10 password guesses per hour.
  • Not allow the phone to wipe itself after 10 bad guesses.
  • Allow guesses to be made via USB/whatever interface, rather than the touchscreen.

i.e. circumvent all the regular iPhone protections against a brute force attack on it's password.

The Electronic Frontier Foundation accuses the FBI of playing politics, stating this was an attempt to establish judicial precedent so that future cases can allow encryption to be bypassed/criminalized.

The Department of Justice’s Office of the Inspector General (OIG) last week released a new report that supports what EFF has long suspected: that the FBI’s legal fight with Apple in 2016 to create backdoor access to a San Bernardino shooter’s iPhone was more focused on creating legal precedent than it was on accessing the one specific device.

In the end, the FBI purchased a tool designed to disable security measures on the phone from an "outside party" (likely a private security firm), which allowed the agency to brute force the phone's 4 digit PIN. The FBI has been very vague about this, with some agents saying they bought a 0day to use, while some specifically say they paid hackers themselves to get into the iPhone. The 0day, which is specific to an iPhone 5C running iOS 9.2, has been patched already by a recent update, making it defunct to any phones with that update.

Despite how the issue was framed by the FBI and its director James Comey, there was reason to believe the phone contained no useful information. According to a security researcher:

It is unclear why Farook would destroy his personal phone but not his work phone if the work phone had sensitive data. They were already destroying two devices, why not three? They were executing some sort of ‘going dark’ plan. It seems entirely possible that they didn’t see the need to destroy a device that was never used for anything sensitive. Source

Crypto Wars III

The FBI wants Apple's "help" to get into the phone of another dead terrorist.

Single file encryption

Warning: GPG/PGP is insecure.[2]

Beyond Full Disk Encryption, a single file can be encrypted with ease. Several programs such as 7Zip, WinRAR and WinZip can encrypt one or more files.


Tomb is a utility for creating GPG encrypted containers with ease. It can also hide keys in JPEGs using steghide, providing a layer of obfuscation. Tarballs can be obtained here, installation instructions if you don't know how to use make can be found here.

  • Creating a 10mb tomb named "installgentoo": $ sudo tomb dig -s 10 installgentoo.tomb
  • Creating a key for our new tomb: $ sudo tomb forge installgentoo.tomb.key
  • Locking our tomb with our newly created key: $ sudo tomb lock installgentoo.tomb -k installgentoo.tomb.key
  • Opening our locked tomb with our new key (opens in /media/): $ sudo tomb open installgentoo.tomb -k installgentoo.tomb.key
  • Hiding a key in a JPEG (original file is untouched): $ sudo tomb bury picture.jpg -k installgentoo.tomb.key



Web encryption


HTTPS relies upon trusted parties called Certificate Authorities (CAs). CA Authorities sign certificates to validate credentials and to stop imposters. Your OS/web browser includes a number of root certificates issued by CAs, and those trusted certificates are used to verify the authenticity of web certificates. Certificates are time-sensitive. If your time is misconfigured (e.g. you are using hardware time and your internal clock has run dry) then your browser may reject certificates

LetsEncrypt is a CA Authority that provides services at not cost.

In 2017, major web browsers began labeling unencrypted web pages or those with self-signed certificates as insecure. Not wanting to look shady, this spurred these websites to adopt HTTPS. As of January 2020 over 80% of web pages use HTTP encrypted with TLS (HTTPS).[3] There are plans to block pages with mixed content entirely.

HTTPS Everywhere, Smart HTTPS, and HTTPZ are a few extensions that try to use HTTPs where it is supported but not configured to be used by default.

DNS Encryption

DNS over HTTPS (DoH)

Tip: DoH is enabled by default in Firefox for US users.[4]

DNS over HTTPS is really just DNS over HTTP over TLS. By using DoH, domain lookups become indistinct from regular encrypted web traffic and difficult to censor without traffic analysis. Mozilla was voted "internet villain of the year" by UK ISPs for disrupting their censorship-surveillance regime with DoH.[5]

DNS over TLS (DoT)

Easier for network operators but easier to censor. Avoid.


Encrypted SNI

Even when using HTTPS certain information is still sent in plain-text. ESNI (Encrypted Server Name Idication) encrypts this information, but it is new and not well supported.


STARTLS is a command sent by a MTA (mail server) to establish a secure connection with another MTA. A man-in-the-middle can strip this header to trick a MTA into establishing an insecure connection. An attacker could also perform a DNS spoofing attack to have mail delivered to his MTA, possibly silently passing on the messages to their true destination. MTA-STS is meant to fix both of these issues.

This only secures email in transit. For proper security mail should be sent end-to-end encrypted and decrypted client-side.

Encrypted Messaging

End to End encryption works on the principal that only the sender and recipient can understand the message being sent. Any third party (including any server the message is sent through) will not be able to decrypt the message. This is the preferred method for all communications.

Encrypted Email

There are certain privacy conscious email providers:

Tip: Protonmail requires Tor users to provide a phone number or secondary email address during registration. Users paying with Bitcoin can get around this (related: Financial_privacy#xmr.to).

Encrypted email invites new problems for password security. If the same password is used for decryption and authentication then a mail server could decrypt sensitive email with ease. A solution is to use two separate passwords for login and decryption as Protonmail originally did. However, maintaining two passwords is inconvenient. Tutanota and Protonmail have each implemented clever methods to securely unify login and decryption passwords. Tutanota salts and hashes login passwords on the client-side; hashes are transmitted and checked against the hash of a hash on the server-side. In this way not only does Tutanota never see user passwords, but server-side hashes cannot be used for authentication.[6] Protonmail uses a related approach, but derives the keys differently and uses SRP for zero-knowledge password authentication.[7]

Other links

This Crunchbang forum post archived (named "The Paranoid Crunchbang Security Guide") has tools and techniques that specifically apply to #!++ (Crunchbang Plus-Plus), but easily applies to other distros as well. Very good resource.