PrivateBin–A Self-Hosted, Zero Knowledge Encrypted Pastebin

PrivateBin is a self-hosted pastebin where the hosting server has zero knowledge about the contents of any pasted data. PrivateBin encrypts and decrypts the pasted data in the browser using AES 256.

What PrivateBin provides

* As a server administrator you don’t have to worry if your users post content that is considered illegal in your country. You have no knowledge of any of the pastes content. If requested or enforced, you can delete any paste from your system.

* Pastebin-like system to store text documents, code samples, etc.

* Encryption of data sent to server.

* Possibility to set a password which is required to read the paste. It further protects a paste and prevents people stumbling upon your paste’s link from being able to read it without the password.

PrivateBin has a fairly well thought-out set of features, including the ability to set expiration dates, and even a burn-after-reading option so that the paste is deleted from the server after it is accessed.

Cryptomator–Open Source Tool to Encrypt Files Stored in the Cloud

Cryptomator is an open source tool that transparently encrypts files that users upload to various cloud storage services, such as Dropbox or Google Drive.

With Cryptomator users set up what it calls vaults with encryption keys that only the user has access to (not the cloud provider). Files that are stored within these vaults are then encrypted automatically (including the filenames).

As long as the user has unlocked the vault on a local device, however, on that device the files are unencrypted automatically for the user. As Cryptomator puts it, this effectively creates a virtual hard drive that is encrypted and decrypted only with the user’s key.

Cryptomator encrypts file contents and names using AES. Your passphrase is protected against bruteforcing attempts using scrypt. Directory structures get obfuscated. The only thing which cannot be encrypted without breaking your cloud synchronization is the modification date of your files.

Cryptomator is a free and open source software licensed under the GPLv3. This allows anyone to check our code. It is impossible to introduce backdoors for third parties. Also we cannot hide vulnerabilities. And the best thing is: There is no need to trust us, as you can control us!

Along with free clients for Windows, Mac and Linxu, Cryptomator also has Android and iOS applications which they do charge for (the Android app is about $10).

SIGSALY–An Encrypted Voice Communication System Deployed By Allied Forces During World War II

SIGSALY was system for encrypting voice communications used during World War II,

SIGSALY used a random noise mask to encrypt voice conversations which had been encoded by a vocoder. The latter was used both to minimize the amount of redundancy (which is high in voice traffic), and also to reduce the amount of information to be encrypted.
The voice encoding used the fact that speech varies fairly slowly as the components of the throat move. The system extracts information about the voice signal around 25 times a second.

. . .


Next, each signal was sampled for its amplitude once every 20 milliseconds. For the band amplitude signals, the amplitude converted into one of six amplitude levels, with values from 0 through 5. The amplitude levels were on a nonlinear scale, with the steps between levels wide at high amplitudes and narrower at low amplitudes. This scheme, known as “companding” or “compressing-expanding”, exploits the fact that the fidelity of voice signals is more sensitive to low amplitudes than to high amplitudes. The pitch signal, which required greater sensitivity, was encoded by a pair of six-level values (one coarse, and one fine), giving thirty-six levels in all.

A cryptographic key, consisting of a series of random values from the same set of six levels, was subtracted from each sampled voice amplitude value to encrypt them before transmission. The subtraction was performed using modular arithmetic: a “wraparound” fashion, meaning that if there was a negative result, it was added to six to give a positive result.

. . .

The SIGSALY terminal was massive, consisting of 40 racks of equipment. It weighed over 50 tons, and used about 30 kW of power, necessitating an air-conditioned room to hold it. Too big and cumbersome for general use, it was only used for the highest level of voice communications.

A dozen SIGSALY terminal installations were eventually set up all over the world. The first was installed in the Pentagon building rather than the White House, which had an extension line, as President Franklin Roosevelt knew of British Prime Minister Winston Churchill’s insistence that he be able to call at any time of the day or night. The second was installed 60 metres (200 ft) below street level in the basement of Selfridges department store on Oxford Street, London, close to the US Embassy on Grosvenor Square. The first conference took place on 15 July 1943, and it was used by both General Dwight D. Eisenhower as the commander of SHAEF, and Churchill, before extensions were installed to the Embassy, 10 Downing Street and the Cabinet War Rooms.[3] One was installed in a ship and followed General Douglas MacArthur during his South Pacific campaigns. In total during WW2, the system supported about 3,000 high-level telephone conferences.

The installation and maintenance of all SIGSALY machines was undertaken by the specially formed and vetted members of the 805th Signal Service Company of the US Army Signal Corps. The system was cumbersome, but it worked very effectively. When the Allies invaded Germany, an investigative team discovered that the Germans had recorded significant amounts of traffic from the system, but had erroneously concluded that it was a complex telegraphic encoding system.

SIGSALY Exhibit at the National Cryptologic Museum
SIGSALY Exhibit at the National Cryptologic Museum

Mozilla’s Cartoon Intro to DNS over HTTPS

Mozilla’s Lin Clark has a cartoon guide to DNS over HTTPS that . . . well . . . bottom line, there is no way to talk about DNS over HTTPS without getting fairly technical (one of the subheads on Lin’s lengthy pice is “What isn’t fixed by TRR with DoH?”) but this is probably as close as anyone is going to get.

A cartoon intro to DNS over HTTPS
A cartoon intro to DNS over HTTPS

EFF’s STARTTLS Everywhere Project

As a sort of sequel to its highly successful HTTPS Everywhere campaign, the Electronic Frontier Foundation has initiated a STARTTLS Everywhere project to improve email security.

Unfortunately, this is likely to prove a bit more challenging than HTTPS Everywhere because of issues with STARTTLS,

Although many mailservers enable STARTTLS, most still do not validate certificates. Without certificate validation, an active attacker on the network can read and even modify emails sent through your supposedly “secure” connection. Since it’s not common practice to validate certificates, there’s often little incentive to present valid certificates in the first place. A brief experiment on Censys shows that about half of the mailservers that support STARTTLS use self-signed certificates.

. . .

When two mailservers support STARTTLS, their insecure connection is opportunistically upgraded to a secure one. In order to make that upgrade, the two mailservers ask each other if they support STARTTLS. Since this initial negotiation is unencrypted, network attackers can alter these messages to make it seem like neither server supports STARTTLS, causing any emails to be sent unencrypted. ISPs in the U.S. and abroad have been caught doing exactly this, and in 2014, several researchers found that encryption on outbound email from several countries were being regularly stripped.

But you have to start somewhere, and the EFF should be commended for going beyond simply issuing policy prescriptions and recommendations, and doing a lot of the heavy lifting to improve end user security.