Tag: Encryption

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.

Android Stuck at “Encrypting SD card: 0%”

So I got my Note 8 and started going the laborious, multi-day process of moving all of my apps, data and settings when I ran into an odd roadblock. I couldn’t get my Note 8 to encrypt my SD card.

I’ve got a 200gb microSD card that I unencrypted on my V20 and had been using without an issue in my Note 8. Since it can take hours to for Android to encrypt such a large microSD I waited until the end of the day and got the encryption process going.

Except rather than actually encrypt the microSD card, the process was stuck for about 20 minutes (way too long) with this message:

Encrypting SD card: 0%

It never advanced past that. A couple Google searches only turned up a single forum post about that specific problem, though there were other posts regarding Android getting stuck encrypting SD cards. One of the replies to the user who had the same problem I was experiencing set off a light bulb in my head:

Is your lockscreen locked with a password? If not, the SD card won’t encrypt. (You should be given that message as soon as you try to encrypt it.)

Okay, I’ve got a lockscreen password set, so it should start encry….hey, wait a minute, it couldn’t possibly be… oh, FFS, it is.

So, I own a Samsung Gear S3 watch. Typically I set my phone up so that it will unlock without having to enter my phone password as long as it is connected via Bluetooth to the watch.

And wouldn’t you know it, the second I disabled that feature on the phone, the encryption process actually started.

Okay, that’s ridiculous. If having something like that option turned on is going to prevent the OS from encrypting the microSD card, then the OS shouldn’t allow the users to choose “Encrypt SD card” until the unlock feature causing the problem is resolved.

The “Encrypt SD Card” button should be grayed out with a message like:

This device can be unlocked by the presence of a paired Bluetooth device. The SD card cannot be encrypted while the phone is configured this way.

A better option would be to allow the user to encrypt the microSD card in this state, since it applies only to the initial encrypting of the card rather than its ongoing use.

What’s the point of the system refusing to allow you to encrypt a microSD card if the device can be unlocked by the a Bluetooth device, when it’s going to allow the user to routinely access the data on the microSD card via this method once it is finally encrypted?