Espionage 3.6.6 Released!

Nothing exciting, just an important bug fix. In the meantime, we’re continuing our work to sustainably open-source Espionage.

  • Fixes
    • Fixed crash on macOS Sierra during installation.

The signature for Espionage.dmg is here and also here (pubkey here). The SHA256 of the main binary is also noted below.

Enjoy! ūüėÄ

$ openssl dgst -sha256
SHA256( 348702cb35208a5b834ea34556879483f7ad51d715868777ee46a6ca5a5a7f90

[Security] Protecting Mail On Recent Versions Of OS X

It has been brought to our attention that recent versions of Mail on OS X (perhaps starting with 10.10, but definitely since¬†10.11), will re-download all of your email from your email server. And since your server doesn’t encrypt your email, that’s a serious concern.

This means that the following attack is possible to bypass Espionage’s protection of your email:

  1. While¬†Mail’s folder(s) are locked and empty, open Mail.
  2. Follow the dialogs and allow Mail to import your messages.
  3. Wait for a while as your email is re-downloaded.

We do not believe this behavior existed in older versions of OS X, but we still should have noticed earlier. Our sincere apologies for not having done so ourselves, and our sincere thanks to the customer who reported this issue!

During¬†our investigations, we were not able to find any folder that could be encrypted to prevent this from happening. This has lead us to conclude that Mail must¬†be fetching¬†account information directly from OS X’s keychain.


Unless Apple changes their code for, there doesn’t appear to be a way to prevent it from using the credentials in OS X’s Keychain to re-download all messages‚ÄĒwhere, we should emphasize, they are¬†unencrypted.

There are at least three mitigations:

Option #1: Move messages to the “On My Mac” section

In the sidebar on the left that shows all of your accounts and mailboxes, there should be a section that says “On My Mac”:

On My Mac

If this section is missing you can make¬†it to appear by creating a new “local” folder via¬†the¬†Mailbox menu:¬†Mailbox > New Mailbox… and then: Location:¬†On My Mac.

All folders in this section correspond to folders¬†only on your Mac (and not the server). Therefore, any messages moved into these folders¬†should disappear from the server and won’t be re-downloaded by Mail.

You can use Mail’s Inbox Rules¬†(via the Preferences) to automatically move messages to one of these local folders. The downside is these messages will not be synced to your¬†other devices.

Option #2: Use GPGTools to encrypt messages

You can use the wonderful¬†GPGTools software to store, send, and receive messages that are encrypted¬†even on the server. However, this¬†approach isn’t for everyone as it¬†may be¬†somewhat¬†less¬†user-friendly, and it requires that the recipient also be using GPG.

Option #3:¬†Don’t use

Use an email app that either does not store its credentials in the Keychain, or (if it does) does not re-download everything if its primary data folder is missing.

You can verify this yourself by encrypting the data folder of an app like Thunderbird and then opening the app¬†while its¬†folder is locked. If it does not re-download everything, then at least the messages¬†on your computer should be safe. The messages on your email server or on your friend’s computers‚Ķ are a different story.

Conclusion: Email Must Die

I have spent a good portion of my life attempting to fix email and on the general problem of secure messaging. You’d think this would be easy, right?¬†Wrong!

Here’s what my quest has involved so far:

Yet here I am, 8 years later… Email is still an unsolved problem and it is only getting worse. The complexity of self-hosting means more people are relying on companies like Google and Microsoft, and this has led to a centralization of the entire system. These entities are now using their position to further discourage self-hosting by (possibly illegally) dropping or junking email from correctly setup email servers, using spam as an excuse to secure their monopoly.

It’s because of this that I’ve come to the conclusion that¬†email must die.

I’ll leave you with a few email related tweets:

Espionage 3.6.3 drops 10.7, 10.8, 10.9 + Sparklegate Fix

EDIT February 17, 2016: 3.6.4 and 3.6.5 release notes included here as there are only minor changes.

We’re momentarily back from our break in cryptocurrency-research-land (where we’ve been advancing our goal of sustainably open-sourcing Espionage) to bring you the immediate release of Espionage 3.6.3!

“But wait! This doesn’t seem like such an exciting release! What is this business about dropping support for three operating systems? Are you trying to screw us over?! Bad Tao Effect, bad!”


Our dear customers, we love you, we only want what’s best for you, and we will never try to screw you over. ^_^

10.7, 10.8, and 10.9 Are All Insecure. Stop Using Them.

Although we will keep Espionage 3.6.2 available for download here, we strongly recommend that all users upgrade to at least 10.10 (preferably 10.11), and here’s why:

Problem #1: Internet connections are not secure on 10.7 and 10.8

While investigating a serious vulnerability in Sparkle (the software update framework Espionage uses), we discovered that Sparkle did not work at all on our 10.7 test machine.

It turns out that neither Mac OS 10.7 nor 10.8 are capable of handling secure SSL/TLS connections! TLS is the protocol behind the S in HTTPS, and it’s responsible for securing almost all Internet connections.

Versions of TLS prior to 1.2 are afflicted by a serious vulnerability, making the lock icon in your web browser even less meaningful than it already is. It seemed silly to support these insecure systems when they can’t even load Espionage’s homepage (because it only allows TLSv1.2).

Well known infosec researcher Adam Langley had this to say:

This seems like a good moment to reiterate that everything less than TLS 1.2 with an AEAD cipher suite is cryptographically broken.

Problem #2: 10.7, 10.8, and 10.9 are all vulnerable to root privileges escalation

Your Mac has various user accounts on it besides the one you use, and the most powerful of these accounts is called root. Up until 10.11, this account could do anything (and even in 10.11 it can do almost anything). It can delete anything and install anything, including key loggers that would break Espionage’s protection.

Normally it is not possible for a program to gain these “root powers” (privileges) unless you, the user, manually type in your admin password. However, sometimes a bug is discovered that will allow a program running under any account to gain these privileges without any intervention from the user. This is extremely dangerous, and this will forever be the reality all the way up to Mac OS 10.9.

Combine Problem #1 with Problem #2 and you have a recipe for total disaster. Therefore we want to do everything we can to discourage the use of these insecure operating systems, especially given that our customers want security.

The #1 thing users can do to keep themselves secure is keeping their software up-to-date.


Speaking of keeping software up-to-date, Espionage 3.6.3 includes an updated version of Sparkle, the popular OS X software-update framework.

Sparkle had a vulnerability that made it possible for anyone on your network (a malicious attacker) to execute arbitrary code on your machine.

This problem is mitigated somewhat for apps that use HTTPS to check for updates (as Espionage does), but it is still a serious problem, especially on OS X 10.7 – 10.8 because HTTPS is broken on those operating systems (as described above), and even then it’s still possible (though rare) for someone to compromise HTTPS for TLSv1.2 (the latest version).

So just to be on the safe side we’ve updated Espionage’s version of Sparkle and we’ve dropped support for all the compromised operating systems that Apple is no longer updating.

However, you still most likely have compromised apps, so read this:

Sparkle is a very commonly used framework. Almost every app you have that you did not get from the App Store will be using it, and this vulnerability is ultimately due to a fundamental flaw in OS X, so there may be other affected other apps out there.

Until Apple fixes this flaw, we recommend taking these steps to protect your Mac.

We strongly recommend that all users use the latest version of OS X.

OS 10.11 El Capitan is great. Apple did a good job of addressing many of the performance and stability issues that were plaguing 10.10, and since it’s a free upgrade you really don’t have much of an excuse for not using it. Especially if you want to keep your Mac safe and secure.

Release Notes

Here’s what’s new in our minor version update:

  • Security
    • Improved Plausible Deniability by quietly mounting folders (hides some Console messages)
    • Updated Sparkle (even though we use HTTPS) just to be on the safe side due to a vulnerability.
  • Improvements!
    • Use HTTPS for newsletter registration during setup.
  • Bug fixes
    • (3.6.4) Fixed “error decrypting database” on 10.10 (introduced in 3.6.3).
    • (3.6.5) Fixed Sparkle checking for updates too frequently (thanks Sabri!)
  • Misc.
    • Dropped support for 10.7, 10.8, and 10.9 because all of these operating systems are insecure (details in blog release notes for this version).

The signature for Espionage.dmg is here and also here (pubkey here). The SHA256 of the main binary is also noted below.

Enjoy! ūüėÄ

$ openssl dgst -sha256
SHA256( 36bc10690789acea932f57f1d6b485247e92194dc2a79ad6f66dd6fbd1fd334d

P.S. Espionage 3.6.2 will still remain available for download here for those who insist on playing Russian Roulette with their security.

Apologies! Sky Kinda Falling + Protecting Yourself From Sparklegate

This is a followup to yesterday’s post: Sky Not Falling: Sparklegate Not As Bad As It Could Be

After trying and failing to reproduce Sparklegate, I arrived at the conclusion that Gatekeeper and Quarantine did in fact protect OS X users from the Remote Code Execution (RCE) attack.

What I Missed

Radek, the discoverer of the vulnerability, insisted that I was mistaken and that Gatekeeper really did get bypassed. So today I attempted to reproduce the attack using a fresh account on a different machine.

It turns out, if you’ve ever opened Firefox, you are not vulnerable (to the FTP version of the attack), even if Firefox is not running and you’ve manually set the Finder as the default FTP handler.

Resetting the protocol handler via duti -s ftp  has no effect for some reason. Firefox will still launch in response to the attack and the FTP handler is magically reset back to Firefox!

However: if you’ve never run Firefox on your account, then you are vulnerable (and you should pay attention even if you have used Firefox).

How To Protect Yourself From Sparklegate

Sparklegate is a fundamental flaw in OS X, not Sparkle. It is a flaw in Finder (foremost) and WebView (second most). You almost certainly have several apps that are vulnerable to this attack, and even if every app updates its Sparkle framework there still might be others that are vulnerable.

So here are 3 ways to protect yourself from getting owned, and I recommend you do all of them:

1: Download Firefox (if necessary) and run it once on every account

Firefox users are saved by a “bug” (that I hope never gets fixed).

2: Use the `duti` command

The duti utility mentioned in my previous post can prevent this attack by changing the default app that handles a protocol.

If necessary, install Homebrew, and in a terminal window run these commands:

brew install duti
duti -s org.mozilla.firefox ftp
duti -s afp
duti -s smb

If Firefox is not installed you’ll need to change org.mozilla.firefox to¬† like the others. I recommend Firefox because unlike Safari it does not auto-mount anything and it’s a great browser in its own right.

Just in case there are other protocols that could be used in this attack, you may also want to:

3: Use Little Snitch (or similar) to disable LAN & Finder connections

Open Little Snitch Configuration and make sure that you are looking at All Rules. Use the search field to search for Finder and delete any rules that appear in the search results.

Next, clear the search field and scroll to the top. Uncheck the rules that allow “Any Process” to make outgoing connections to the local network and click “Disable Anyway” when prompted:

Screen Shot 2016-02-01 at 7.35.00 PM copy

Doing this will mean that you will get prompted more frequently. Prompts will happen when, for example, iTunes tries to sync with your iPhone over Wifi, or if you try to access a network volume, or for other reasons. Generally you’ll want to allow them unless they mention something about “ftp” or “smb” or “afp” and you aren’t trying to access a network volume.

Something like this might appear if you’re being attacked via FTP, but it’s not necessarily the only prompt to watch out for:

Screen Shot 2016-02-01 at 7.34.03PM

Click Deny in such instances to prevent the attack. You’ll then be greeted with an error like this:

Screen Shot 2016-02-01 at 7.34.33 PM

Finally, Make Sure Gatekeeper Is Enabled

While Gatekeeper won’t protect users who have not done at least one of the things above, it will provide additional protection in case the AFP or SMB protocols are used:

  1. Open System Preferences
  2. Go to Security & Privacy
  3. Make sure that “Allow apps downloaded from:” is *NOT* set to “Anywhere”

If you must open an unsigned app while Gatekeeper is on (not recommended unless you know what you’re doing): right-click on the app and choose “Open” from the contextual menu.


This is a devastating vulnerability that affects many OS X users. Since both WebView and the Finder are at fault, the attack goes beyond apps that haven’t updated their Sparkle framework.

Until Apple fixes this problem, you can protect yourself by doing at least one of the three things mentioned above, and preferably all of them.

Thanks to Radek for insisting that I had missed something and for discovering this vulnerability. Thanks also to Simone Margaritelli for making it simple to use the exploit, for without that I would have been hard-pressed to learn how to defend against it.

Apple told me they are aware of this problem. I hope they’re able to fix it ASAP!

You can follow me and Espionage on twitter.

(UPDATED) Sky Not KINDA Falling: Sparklegate Not As Bad As It Could Be

UPDATE February 1, 2016: It turns out some users are vulnerable to this attack. Read this followup post!

Sparklegate is the term I’ve coined for the recent discovery that, allegedly, every OS X machine out there is vulnerable to RCE (remote-code-execution) attacks because the widely used Sparkle framework, along with OS X’s standard WebView component, allow webpages to mount FTP volumes and run arbitrary programs on your computer.

The first report of this insane vulnerability restricted itself to the use of a terminal settings file to achieve this feat. Shortly after followed a second post, this time alleging that any executable could be run without need for the intermediate step of a .terminal file. This second post also came with a proof-of-concept exploit that anyone can use to attack people with.

The fix that’s suggested in the original post is for app developers to serve their update feeds over HTTPS and to update to the latest version of Sparkle in case that’s not enough. Espionage already checks for updates over HTTPS and therefore it is not particularly affected by this issue, but there is still the very remote chance that someone could obtain a legitimate-yet-fraudulent HTTPS certificate and conduct this attack. Also, the idea that this attack is even possible suggests¬†a severe failing on Apple’s part, one that affects not just apps that use Sparkle but any app with a WebView (and every OS X user has at least several such apps).

So I decided to look into this further and attempt to reproduce the attack. Here’s what I found:

Cannot Reproduce (Mostly)

I ran Simone Margaritelli’s bettercap with the osxsparkle.rb module and tried to reproduce both of the alleged scenarios: attack-by-terminal-settings and attack-by-arbitrary-executable.

For the attack-by-arbitrary-executable I tried out /bin/ls:

sudo bettercap -L -X --no-spoofing --no-discovery --proxy --proxy-module ./osxsparkle.rb --sparkle-rce-file /bin/ls

In order to MITM yourself locally, you must also set your system-wide HTTP proxy settings to the LAN IP and port that’s shown in the output from bettercap. So I did that and then proceeded to Check for Updates in VLC.

Indeed, there was a flurry of activity, but something unexpected happened. Instead of being shown a terminal window with the output of `ls` I was taken to Firefox and a web page with this directory listing:Firefox showing /bin/ls inside of its FTP viewer

Well that’s not very threatening.

So I realized that apparently I was immediately, without going further, seemingly immune to this attack just because Firefox was somehow the default handler for ftp:// URLs.

OK, I thought, what happens if we remove Firefox as the handler?

After some digging I discovered a handy tool called duti (available via Homebrew). Setting the handler to didn’t work, but setting it to did. Here’s what happened when I tried it again with Safari as the default FTP handler:


Excellent! Just as I would expect, Quarantine prevents the file from automatically executing. Although it is a bit disturbing that Safari chooses to automount an FTP volume instead of handling the protocol itself (like Firefox), still no RCE.

Maybe the terminal settings file will bypass Quarantine and Gatekeeper (as the original post alleges)?

sudo bettercap -L -X --no-spoofing --no-discovery --proxy --proxy-module ./osxsparkle.rb --sparkle-rce-file ./settings.terminal



Blocked by Gatekeeper.

Conclusion (& Precautionary Steps To Mitigate)

At least in my attempts to reproduce this vulnerability, it seems both Quarantine and Gatekeeper, together, prevent both signed and unsigned applications from being automatically run without the user’s consent.

To be clear, this is still a problem for several reasons:

  • Just because a random webpage loads shouldn’t mean that Safari (or the Finder) auto-mounts or auto-launches anything! That’s just crazy! Thank goodness for Gatekeeper and Quarantine because without them this would have been a total and complete long-lasting catastrophe. So make sure you haven’t disabled either of them!
  • As the original report indicates, this attack could still be used to exhaust a system’s memory because the way XML is handled is broken. Apps that check for updates over HTTP and haven’t updated to the latest version of Sparkle are still vulnerable to this.

How To Mitigate

Developers should update their apps and take care to:

  1. Make sure they’re using at least Sparkle 1.13.1 and preferably a later version. Until a later version is released I would recommend being cautious and building the Sparkle framework yourself from source (the Makefile makes this easy).
  2. Who knows what other crazy surprises like this are lurking undiscovered, so make sure your appcast is using HTTPS in addition to Sparkle’s built-in DSA signature verification.
  3. Sparkle should require both HTTPS and the DSA check from here on out. Now that HTTPS certs are free, no more excuses.

Users can simply download, install, and run Firefox (it’s a feature not a bug :P!).

To be certain that Firefox is the default handler for FTP you can use Homebrew to `brew install duti` and then:

duti -s org.mozilla.firefox ftp

However, there are other protocols besides FTP that could be used (like smb), so even better would be to install Little Snitch and make sure that there are no permanent rules allowing the Finder to make outgoing connections. Thus, if you get a prompt asking you to allow the Finder to connect to something (and you didn’t do anything to initiate), block it.

We will still release a minor update to Espionage with an updated Sparkle just to be extra safe.

The good news though is that as long as your Gatekeeper & Quarantine settings haven’t been modified, Sparklegate should not harm you (as long as you don’t blindly click “Yes” to things), and users can still take precautionary steps (like Little Snitch) to protect themselves even in the worst case where Gatekeeper and Quarantine fail.

Finally, a request to Apple: please fix that whole visiting-a-webpage-automounting-&-autolaunching thing. I’ve opened rdar://24428066 for this.

You can follow me and Espionage on twitter.

[Job] Design focused Cocoa developer for Espionage 3

Espionage is a highly rated personal data encryption app for Mac OS X.

It currently follows a “source code available” policy, but we think the right thing to do is to completely open source the product.

However, this comes with two significant challenges:

  1. If we open source Espionage improperly, there is an extremely significant risk that it will face the same fate as TrueCrypt. More important than open sourcing the app is ensuring its health. A dead, unsupported app is useful to few, whether or not it’s open source.
  2. We do not have control or ownership of one of the most critical underlying technologies: Apple’s encrypted sparsebundles. Therefore, we cannot open source that aspect of Espionage.

Your Mission, Should You Choose To Accept It

We’re looking for an excellent Cocoa developer who is also interested in solving the problem of funding beneficial, open source¬†software, without resorting to advertisements or other nuisances.

You’ll work with us to open source the application in a way that is sustainable. This will involve making creative modifications and improvements to the UI, and novel cryptocurrency¬†concepts.

Initially, we will simply focus on addressing Challenge #1 above. Later on we can move to Challenge #2.


  • You have at least 2 years of experience working with Cocoa and Objective-C (or you are a genius who doesn’t need 2 years of experience).
  • You speak English well.
  • You’ve downloaded and played around with Espionage.
  • You have experience designing simple, elegant, and intuitive interfaces with Cocoa.
  • Ability to use GPG, or willingness to learn (GPGTools makes it simple).

Nice to Have

  • Interest/experience with infosec related topics.

We do not care about

  • Your educational background.
  • Your physical location, race, color, ethnicity, nationality, sexual orientation, gender identity/expression, religious beliefs, age (except as required by law), marital status, disability, or veteran‚Äôs status.


Send your resumé, along with the answer to the questions below to:

contact at taoeffect dot com

  1. Why we should hire you.
  2. What interests you about this project.
  3. Samples of your previous work (can be a link to a portfolio, GitHub project, etc.).
  4. Whether or not you have (or plan to obtain) a security clearance, and if so, why.

Espionage 3.6.2 Released!

Espionage 3.6.2 delivers an important security fix to address a plausible deniability issue with folders that were set to auto-lock, and it also brings important improvements and bug fixes:

  • Security
    • The path for folders set to auto-lock was leaked in previous versions, compromising their plausible deniability (PD). If you require PD for those folders make sure to change the mountpoint for the affected folders after updating to 3.6.2! If you have any questions about this please contact us.
  • Improvements!
    • If a folder fails to lock, Espionage will now tell you the application(s) that’s preventing it from locking.
  • Bug fixes
    • Fixed crash on renaming a folder.
    • Fixed issue where many critical notifications would be posted if a folder failed to auto-lock due to open item.
  • Misc.
    • Added Cynthia to credits for Tagalog localization.
  • Known Issue(s)
    • High CPU usage can occur if a folder gets auto-locked in a user-account that you’re not logged into (via Apple’s Fast User Switching feature).

How to change the “mountpoint” for a folder

The¬†mountpoint is the location of your encrypted folder. It’s called a mountpoint because that’s the location where the decrypted data is “mounted” when the folder is unlocked. It’s a weird technical word… we didn’t come up with it. ūüėõ

Remember that you only need to do this for folders that have auto-lock enabled (and only if you care about having plausible deniability for those folders).

Step 1: Click on the ‘i’ (info) icon for the folder to go to the folder details

Step 2:¬†Click on the mountpoint and “Choose…” another location

In the Open Panel that appears, pick a new location for the folder. That’s it!

The signature for Espionage.dmg is here and also here. The SHA256 of the main binary is also noted below.

Enjoy! ūüėÄ

$ openssl dgst -sha256
SHA256( 5be6da8addd208fc80b07873d591602b15f85aa756e1fd9e2d44052e046547bd

2014 Apple iMessages security update

A few days ago I made the following tweet:

I’d like to apologize for the wording of that, as it could have been written in a more accurate¬†way.

To help clear up any confusion, I spent the past day or so diving¬†into the nitty-gritty details of Apple’s iOS Security Guide from October 2014. Big thanks to Nate Cardozo of EFF for linking me to it.

The tweet I should have made instead is:

While Apple’s iMessages are¬†designed to be “end-to-end encrypted”, Apple can¬†still read them (if they wanted to).

That is not news. On October 17th, 2013, Quarkslab published iMessage Privacy, where they stated (correctly) that:

Apple can read your iMessages if they choose to, or if they are required to do so by a government order.

This is because Apple owns and operates the infrastructure that distributes the public keys between phones. At any point in time they are capable of giving out a public key of their invention (not belonging to the intended recipient), and decrypting/re-encrypting your messages as you send them to your friends and family.

A separate and more concerning issue was pointed out by Ars Technica a few months prior: if you enable iCloud backups, Apple will encrypt your data with keys that they generate themselves instead of using¬†a key that’s based on your password (which they do not know). This is why¬†Ashkan Soltani¬†was able to restore his iMessages onto a¬†completely different iPhone after resetting his iCloud password and answering Apple’s iForgot security questions.

Update July 27, 2015: A third issue, perhaps the most severe, is¬† Apple’s use of weak encryption, only 1280-bits!

Has anything changed since then?

After reviewing Apple’s 2014 October iOS Security Guide, unless I am misreading something, the answer appears to be:¬†Nope.

Below are some choice screenshots from my annotated copy.

iMessages security (in transit)

Here Apple describes how their IDS and APN services act as MITM between users for the purpose of public key exchange and message delivery. As long¬†as these services are honest, the communication actually is end-to-end encrypted. There’s nothing in the protocol forcing Apple to be honest, however.

iMessages security (when backed up to iCloud)

On the matter of iCloud backups, we have the following (for the infosec crowd; skip below if you find it overwhelming):

Screen Shot 2014-11-08 at 9.41.52 PM

Screen Shot 2014-11-08 at 9.42.43 PM

This gobbledygook says that for iCloud backups data like iMessages¬†gets encrypted with¬†Apple’s keys (not yours), while¬†keychain entries (wifi passwords, credit cards, iMessage private¬†keys¬†[not messages], etc.) are stored in a way that (allegedly) Apple cannot read because it’s tied to a password (a “UID”) that Apple creates for each phone upon manufacture (but claims to not know).¬†The iMessage keys are used for the so-called “end-to-end” encryption when sending data between phones. They are not used to encrypt the messages stored on the phone, nor the messages stored in iCloud.

Conclusion & Recommendations

It should be emphasized that Apple has gone to noble lengths to protect your data.

The technical shortcomings described above do not imply¬†any sort of intentional failure or sneakiness¬†on Apple’s part. IMHO, Apple has done fairly well (within the confines of a centralized system) when it comes to balancing¬†communications security with easy of use. The award for “the best” job still goes to the Signal/TextSecure team. Apple’s iCloud backups, however, should be encrypted with the user’s keys, not Apple’s (at the very least this should be an option). Nate points out that Apple provides a way for users to¬†delete old iCloud backups.

To address the rest of the¬†shortcomings, we suggest that Apple (and other companies) explore decentralized key distribution mechanisms (like okTurtles’ DNSChain). Such mechanisms don’t require fingerprint verification between users and therefore would preserve¬†the fantastic user experience that Apple is known for, while simultaneously protecting both Apple’s users and Apple itself from forms of coercion (like National Security Letters) that destroy Apple’s “end-to-end” encryption.

Apple should also be¬†commended¬†for the steps they’ve taken to be more transparent about the security of their systems. I enjoyed reading their iOS Security Guide and felt they did a¬†fantastic job with it. Props to the team that made that happen! ūüôā

A final remark: if Apple is to receive any criticism, it shouldn’t be for any technical shortcomings, but instead for the following¬†misleading¬†marketing claim on their website:


My thanks to Nate Cardozo, Simon de la Rouviere, Filipe Beato, and Bob for reviewing this post.

Espionage 3.6.1 Released! Yosemite Compatible.

Espionage is Yosemite ready. ūüôā

  • New!
    • Added crash reporting mechanism (QuincyKit).
  • Improvements!
    • Large folders should unlock faster now (size check is now done asynchronously)
  • Bug fixes!
    • OS X 10.10 Yosemite compatibility.
    • Fixed problem causing NSLockError messages in console.
    • Use built-in notifications by default (they display more text than OS X’s or Growl’s).
    • Espionage’s “Window Mode” window would appear would it shouldn’t.
    • Quit button shouldn’t show on the very first TESetupAssisant.
    • No longer show “Buy Now” in license preferences when registered.

The signature for Espionage.dmg is here and also here. The SHA256 of the main binary is also noted below.

Enjoy! ūüėÄ

$ openssl dgst -sha256
SHA256( 64ccef4205db3d32f38f656b1a02bd6a0f6905680e2a3434680c4ea982954eaa

Major Advancements in Deniable Encryption Arrive in Espionage 3.6

Four months ago, we previewed Major improvements to plausible deniability in Espionage 3.6. Today we’re delivering those improvements, and many more!

Overview of Significant Features

1. Plausible Deniability

Espionage 3.6 enhances the deniable encryption of previous versions by creating a random number of convincing fake encrypted disk images and a random number of fake Folder Sets (a Folder Set is a group of encrypted folders protected by a master password. You can have as many of these as you want, each having a unique password).

Fake disk images and fake Folder Sets have the potential to make it virtually impossible to tell whether a user has shown you all of their encrypted data. The fake data looks just like the real data, and we’ve even taken pains to ensure that all of the files inside of the fake disk images have random (and convincing) timestamps on them.

Update October 7, 2014: However, as of this release, the timestamps on the fake disk images are not sufficient to fool all infosec professionals. We are researching methods that will fool infosec researchers while still being respectful of our user’s backup systems (like Apple’s Time Machine, SpiderOak, etc.). Users might end up having to choose between super-convincing deniability and having to backup fake data periodically. We thank Steve Weis, Collin Anderson, and the [LiberationTech] community for pointing out that we should have made this clear here, and apologize for not having done so originally.

After updating to 3.6, existing users are encouraged to verify that all their folders unlock without problems, and then delete the old database backups in this folder:

~/Library/Application Support/com.taoeffect.Espionage3/Backups/

Copy and paste that path into the dialog that appears when you choose Go to Folder… from the Finder’s¬†Go menu:

Go to Folder...
We recommend deleting these old database backups because they can give away which copies of your database are filled with fake folder sets and which aren’t (because of the file size difference). The super-paranoid might also want to clear out their system’s log files after the update.

Why do we care about such features? Because encrypting data isn’t enough to protect you from all threats, as this XKCD so elegantly illustrates:

2. Partial support for TEN new languages (to-be-finished soon!)

Remember our Pootle blog post and call for translators? Well, their hard work is being previewed in this release with the addition of ten new languages (in addition to English, Spanish, and Brazilian Portuguese):

  • Arabic
  • Chinese (Simplified)
  • Czech
  • French
  • German
  • Italian
  • Japanese
  • Korean
  • Russian
  • Tagalog

We expect to release another update with completed translations for the languages above in the next update (or soon after it).

And much much more!

This release involved almost the same the level of effort as a major release, but we’re releasing it as a free update for all Espionage 3 users.

Explore the complete list of changes:

  • New Features!
    • Fake folder sets and fake disk images to mask how many you really have.
    • Holding Shift when unlocking folder opens it (plus preference to make default behavior)
    • Set the default image disk location via Preferences.
    • Double-click license to register Espionage (although we don’t want to encourage double-clicking email attachments, too many weren’t reading the instructions).
  • Security Enhancements!
  • Updated Localizations!
    • Updated:
      • Spanish, Brazillian Portuguese
    • Partial (to-be-finished) support for:
      • Arabic, Chinese (Simplified), Czech, French, German, Italian, Japanese, Korean, Russian, Tagalog
    • Want your language here? Get in touch!
  • Improvements!
    • Multiple monitor support.
    • No longer brings up the scary OS X prompt for Contacts access during install (users must now manually type email to subscribe to newsletter).
    • Updated Sparkle to 1.7.1.
    • Close Espionage window when Escape key is pressed.
    • Quit if database newer than what Espionage expects.
    • Encrypted folders on Desktop stay visible when unlocked.
    • Better architecture for handling of disk images on external drives.
    • All XIBs upgraded to Xcode 5.
    • Sparkle updates from to avoid scaring Little Snitch users.
  • Bug fixes!
    • Crash in OS X 10.7 resizing the disk image.
    • Fixed potential crashes in certain error-handling situations.
    • Multiple Screen in OS X 10.9
    • Autounlock now properly updated for folders that were forcibly removed from the database (via the contextual menu).
    • Disk image’s password is now saved in the same folder as the disk image when restoration fails (instead of always on the Desktop).
    • When using Window mode, open Espionage window when Dock icon is clicked
    • In folder list, filter by folder name instead of folder path
    • Removed misplaced warning when sparsebundle is imported from Desktop
    • Fixed email validator in newsletter setup assistant.
    • Better error handling and error messages during encryption and decryption.
    • Autounlock dialog staying open too long.
    • Removed deprecated API use (and therefore the Console messages).
    • Misceallaneous fixes and improvements. Over 100 tickets closed in this release!

And as promised, we’ll be signing all our releases. The signature for Espionage.dmg is here and also here. Also,¬† starting in 3.6, Sparkle will verify updates using a pinned 4096-bit DSA key. The SHA256 of the main binary is also noted below.

Enjoy! ūüėÄ

% openssl dgst -sha256
SHA256( 2d1c3ffdf129060f00729893b20db26b34bcc56d8197889720cbe191b4d38081