Forums temporarily locked down! Please read!

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - tzugo

Pages: [1]
Espionage 3 / Re: Folder Sets and Plausible Deniability
« on: March 20, 2014, 11:22:20 PM »
Hey, that's great news. Way to go! I also just read today's blog entry of yours about this topic.  :)

And thank you for pointing out the union mounts to me — I didn't know the Mac had them, too (they do still exist). Very useful.

Keep up the good work,

PS: Are you going to encrypt the Folder Action scripts along with the Folder Sets database in the upcoming or a future version of Espionage? If one uses a Folder Action script to further obfuscate one's sparsebundles that code needs protection, too, and the best and safest place I can think of should be the encrypted Folder Set definition...

Espionage 3 / Re: Folder Sets and Plausible Deniability
« on: September 22, 2013, 09:17:44 AM »
However, there's also an alternative approach that doesn't require changing the "database" (DB) format. We could simply fill DB with a random number of folder sets that contain a random number folders. Would that equivalently address your concern?

Yes, that is in fact a good idea, an even better one than my own.

So only the problem of the too-easy-to-find and too-difficult-to-deny-plausibly encrypted sparsebundles is left. I agree that sparsebundles are a very nice and clever invention with a lot going for them, not only regarding backups. It's just that one would need to hide them better. I envision putting a sparsebundle directory in the middle of a big Aperture library, with its telltale files (Info.plist, Info.bckup) removed and the notorius file and directory names (.sparsebundle suffix, bands, tokens) obscured. Yes, this could be accomplished through folder actions.¹

I agree that PGP/GPG sucks big time because of its usage concept, I avoid it for that reason, too. I also agree that Espionage should continue to be very easy to use, but it should also make it easy for everyone to do more sophisticated stuff. Perhaps folder actions are really the proper way to go. Please just make sure that any script which is executed as part of a folder action is also encrypted along with the database part that defines the folder set. I.e. not only the list of mounts and actions should only be visible with the proper master key, also the "contents" of the action script(s) itself should be safely hidden. I guess this might bring Espionage a big step forward regarding advanced usage scenarios. Or does Espionage already work that way? (Haven't checked folder actions in detail yet.)

¹) Does OS X support the concept of "loopback mounts"? It would be cool to have all the .sparsebundle support files, i.e. everything except the contents of the bands directory, in a small fixed-size encrypted image which is mounted and then the bands directory (which bears some other name and is hidden somewhere between totally unrelated stuff) is mounted into it, yielding a complete sparsebundle again which can then be mounted in turn. Or perhaps a softlink instead of a loopback mount would already do?!

Espionage 3 / Re: Secure Cloud Idea
« on: September 21, 2013, 10:24:10 PM »
Another possibility is reverse engineering sparsebundles and making them cross-platform. Some work on this has already been done by others.

That's of course a nice approach, too.

Re: 1PW, that whole world is quite different from what Espionage does.

I know, just wanted to point out that they found a really nice and clever way to address this particular problem. Having the whole logic and crypto stuff which is needed to access the data "anytime, anywhere" implemented in JavaScript is plain cool. I use this option rarely, but if I need to, I am extremely glad it's there. But I just brought this up as an inspiring example, it is clear to me that you cannot easily go the same route as what you are doing is very different.

FileVault, in my opinion, is somewhat lacking.

Yes, but I wasn't intending to claim that Espionage is no longer needed now that FileVault is there, on the contrary actually.

My point is this: Before FileVault 2, everybody travelling with a laptop was basically forced to use some third party encryption solution such as Espionage, since everybody has private data which they need to protect e.g. in case their device is stolen. A solution catering for this broad user base and use case must be easy to understand and use, which Espionage is and was IMO (yes, I see from the forums that there still are people that have problems understanding it, but that's partly a problem of educating them well enough).

Now that FileVault 2 is there, this base is covered,¹ so I assume people will turn to Espionage to "go some extra mile", i.e. they don't just strive for privacy, but they want safe and secure storage of important data. Data which they can neither afford to lose access to nor afford for it to become disclosed. The "no disclosure" part might be handled by Espionage quite well already, but do I see room for improvement on the "loss of access" front.  ;)

¹) Heck, the great thing about FileVault 2 on my MacBooks plus my multiple, distributed, and encrypted Time Machine backup USB drives is that I don't need to worry losing any of them anymore. Every single piece of hardware is disposable and the data is safe against failure, loss and theft. If something breaks or gets lost, I buy it anew. Espionage exists to solve a very different problem.

Espionage 3 / Re: Folder Sets and Plausible Deniability
« on: September 21, 2013, 09:39:00 PM »
We have to prioritize what features we implement, and disguising sparsebundles as movie files, while a very interesting idea, would be difficult to get right, and simply doesn't increase the value of Espionage enough to justify the effort we'd have to put into it.

Well, it is of course up to you to decide in which direction you want to bring Espionage forward. I liked it when version 3 introduced support for the important concept of "plausible deniability" and — in the assumption that you feel strongly about it, too — wanted to point out that there is room for improvement, should you wish to go this route. If your plans for Espionage are merely to deliver "convenient encryption for the masses", than that is fine for me, too. I know that I can, and perhaps should, continue "to roll my own" regarding strong encryption and steganography; I come from a Linux background and have been doing such kind of things on the command line for years. But I also very much enjoy tools like Espionage which have a nice UI and are pleasurable and convenient to use, and — not only now a few months after the uncovering of PRISM etc. — there should be a strong niche for programs like Espionage if they are committed to go some extra mile.

It's certainly possible for a highly skilled adversary (e.g. some evil-geek at the NSA) to find out that there is more than one folder set, but that doesn't mean much.

I'm afraid no "evil geek" is needed — we should assume the "relevant parties" to have a list of known software for the various operation systems and a little checklist about what to watch out for if e.g. the app Espionage is found on a suspect's system, and if there is evidence that the suspect is using multiple folder sets, they just might continue to torture him until all of them are revealed, right?

It should be easy to make the presence or absence of multiple folder sets completely undetectable: Just create a big file of, say, 1 megabyte, for Espionage to keep its settings which is initialized with random bytes. This file shall be separated in, say, 32 logical chunks — slots — of 32 kilobytes each. Whenever the user creates a folder set, he must select a slot number and a new master key. Espionage will then put its administrative data into the chunk of the file at offset 32kB*slot_number, encrypted with the new master key (which will cause this part of the file to still contain data that looks totally random as it only gains any meaning if the proper key is used to decrypt it). Whenever a key is entered to unlock Espionage, it will iterate thorugh all slots and try decrypt each with the key; if this succeeds for a slot, the config data (folder set information) to use is found.

The idea of disguising them as other types of files is interesting, however it comes with its own issues. Sparsebundles have files within them that have a sequence of bits that say, "I'm a sparsebundle!". So, in our example of the "evil-NSA geek", if they really wanted to get you, they'd be able to search the entire drive looking for that exact pattern of bits, and they'd find them.

Sure, but I am not suggesting a simplistic approach here. What e.g. if you used fixed-size encrypted disk images instead of sparsebundles, without any recognizable headers (i.e. a plain encrypted byte stream), and just put these in the middle of a 25 gigabyte Blu-Ray rip?¹ Sure, this movie would be damaged and no longer play correctly, but it should be hard to tell — for anyone who is lucky enough to detect it at all! — whether this "damage" originates from some hardware or software fault or whether this is important encrypted information, right?

Well, I do not want to persuade you into going somewhere you don't want to go with Espionage, but I think you have a little gem here with a lot of potential...

¹) This used to be easy to accomplish on Linux with the various kinds of loopback block devices, I assume there should be similar ways on OS X.

Espionage 3 / Re: Secure Cloud Idea
« on: September 21, 2013, 04:53:58 PM »
greg wrote:
Right now Espionage 3 has far fewer liabilities compared to to Espionage 2. It relies on very little external code that has the potential to break or lose support.

Espionage 3 has one huge liability and this is the reliance on Apple's disk image and encryption framework. Well, this reliance is deliberate, and every user of Espionage knows about it (well, they better should!), but many people would perhaps prefer a solution that does not tie their important secret data¹ to one operating system.

I like the way 1Password ensures that the encrypted data can be read on basically any system using just a web browser!

Perhaps EncFS could lead Espionage into a possibly brighter - 'cause cross platform - future?!

¹) And I argue that many people will not bother using tools like Espionage for any not-so-important stuff anymore since the introduction of full disk encryption by Apple since Lion, FileVault 2, solves a big enough part of their privacy problems already.

Espionage 3 / Folder Sets and Plausible Deniability
« on: September 21, 2013, 04:27:18 PM »
Dear Tao Effects team,

I'd like to know more about the "plausible deniability" which is provided through folder sets.

If I understand correctly, the idea goes like this: If someone pushes me to unlock my secret data, I enter the Espionage 3 master password of a folder set which does only contain some "unimportant" encrypted folders, i.e. a folder set which I set up only for this very purpose of disclosing it in case I am forced to disclose "something". The stuff which I really want to hide will then go in one or more additional folder sets.

But how are folder sets stored internally? How do you make sure that the "oppressor" is not able to find out that more than one folder set exists?

Thank you,

PS: IMO the fact that the encrypted sparsebundles themselves can be easily found (e.g. with "find / -name *.sparsebundle" in a window) is already quite a big threat to the "plausibility of the deniability" so to speak. I encourage you to proceed into this direction with a future version of Espionage, think about hiding encrypted images inside of 1080p movie files etc.  8)

Pages: [1]