Safe: Free Easy File System Encryption | Hacker News Reader

Safe: Free Easy File System Encryption

getsafe.org

20 pointsrian34 comments

First thought on the Website: Don't do that. Don't force me to go through lengthy animations, just show me your actual content and let me use it like I use the rest of the web.

Second: The 'Learn more' presentation actually says nothing, nevermind that the start page is equally uninformative. Not a single word about techniques used or what makes this service supposedly 'safe' or why I should trust it with my data.

I am highly suspicious of anything claiming to be "safe" or "secure", expecially when it is this dodgy around details. I'd not advise anyone to actually use this for anything sensitive.

EDIT: Just noticed the tiny light-grey 'About' link at the bottom, which gives a little more info. Still, I absolutely dislike the site design.

thanks for the feedback! i don't disagree with you.

i designed the splash page to be very sparse because i wanted to minimize distractions and make it simple to just get started using the app. i figure most people don't like reading as much as they like looking at pictures.

for those who like to read (and have a discerning eye) the "about" link has all the gory details you're looking for.

it was a trade-off and there definitely could be a better result but this is what developed in the end. the splash page may change as more feedback rolls in.

Just to put my +1 here, I think the project looks great and the product itself seems good but that website is not good and is actually quite annoying.

1) No animations. Just get rid of them all.

2) Put a link on the 'Learn More' page that takes you back to the homepage. The 'Learn More' page only contains a link to the download page, no way to click back to homepage.

3) 6 click throughs to read 6 sentences on the About page is annoying. I don't need a single sentence stretched out across an HD screen (feels like I have to take a few steps back to read the massive text without panning my entire head left and right). Have all 6 of those on one long page instead.

4) I didn't even notice the tiny links on the front page at the far bottom left (probably because of how gigantic everything else is). Make those links more prominent and maybe also have those links as part of the footer of every page. The http://www.getsafe.org/about is especially useful and contains most of what I wanted to see.

Safe is a wrapper around EncFS, which (a) potentially leaks a lot of metadata and (b) is a weird combination of CBC and CFB. I'd feel better about Truecrypt.

I would probably think twice before using anything based on EncFS. See this audit for a lot of detail: https://defuse.ca/audits/encfs.htm

Defuse has done quick audits on both EncFS and eCryptfs. Both store their encrypted files in another file system. eCryptfs did substantially better then EncFS

https://defuse.ca/audits/encfs.htm https://defuse.ca/audits/ecryptfs.htm

Truecrypt is a different beast (acts as the basis blob or blockdev for a file system) and has done significantly better on more rigorous audits: https://opencryptoaudit.org/reports/

we're actually in the process of updating encfs to use XTS. also, that particular audit was done quickly and some of the analyses weren't done considering the threat-model that encfs is designed for (so it makes encfs look worse than it really is).

I removed this sentence from my previous comment to parent: From a layman's perspective, I should think the encfs authors came away from that analysis with a feeling of achievement: to have been audited (however quickly) and yet to live.

If the above (grand-parent) is the worst tptacek says about encfs, I would argue that you are in decent shape.

encfs encrypts a-file-at-a-time, right? That's not an XTS use case.

It can be. We want to move away from IV-based encryption primitives to tweak-based primitives for each individual file. This is just so more people understand how it works, especially since now XTS is a recommended standard. Right now we use a custom solution, which made sense in 2004 but now that XTS exists we can switch over.

Wait, XTS is a standard recommended for block-level disk encryption. It's not a recommendation for file encryption. The two problems are similar, but not identical; for instance, block encryption has strict requirements on ciphertext size, and requires the capability to modify ciphertexts instead of just re-encrypting. Are you sure XTS is a good idea for file encryption? Wouldn't a simple AEAD mode do the job just as well, and also provide for file integrity?

As this surfaced, I was chiefly impressed by the fact that encfs was amenable to such a by-and-by[0] audit: the code-base must be at least somewhat legible.

This "auditability" seems to me a strength worth nurturing.

[0] Where "by-and-by" refers to the usual superhuman app-sec standards in which "10 hours" translate into actual, meaningful work.

As glossarian in residence I cannot but expand the above app-sec acronyms:

* CBC - Cipher block chaining: https://en.wikipedia.org/wiki/Cipher_block_chaining#Cipher-b...

* CFB - Cipher feedback: https://en.wikipedia.org/wiki/Block_cipher_modes_of_operatio...

As evinced by the structural similarity of the diagrams in the pages above, the two are very similar; hence tptacek's characterisation of their combination in encfs as "weird", I presume.

* XTS - "XEX-based tweaked-codebook mode with ciphertext stealing": https://en.wikipedia.org/wiki/XEX-TCB-CTS#XEX-based_tweaked-...

I have to more or less hope this is the encryption mode referenced above. NIST recommends an AES cipher to employ with it.

Resolving all acronyms here seems futile (albeit entertaining), thus I will simply rest.

(This is my last unsolicited reply in this thread, I promise.)

Of course, encfs aims to hit a very specific sweet spot with their emphasis on backup-friendly per-file encryption as opposed to Truecrypt's container approach.

Which is begging the question, naturally.

edit: To wit, whether an alternative exists that would satisfy the encfs use case.

What are your thoughts on the "encrypted homedirs" in Ubuntu?

Everyone hearts Truecrypt yet given the media fury caused by the Snowden leaks and the hunt for the real Satoshi Nakamoto, why is there zero attention about the fact that Truecrypt is also anonymously developed?

Huh? There is almost nothing but attention to Truecrypt's anonymous authorship. That's the entire reason Matthew Green organized the iSEC audit.

Sorry, I was commenting on the fact that given what we now know about the NSA's TAO etc, you still feel comfortable with encryption software written by anonymous developers.

You just asked the same question twice. See previous answer.

Truecrypt versus dm-crypt+LUKS?

Although it servers an entirely different purpose, there are a couple of things I would ask: 1) How would one share encrypted files? 2) What happen when user forgot password? 3) What cryptographic algorithm is this using?

Actual issues when I gave it a try: 1) Unmounting the safe is possible but there's no easy way to remount the Safe 2) All the filenames are obfuscated (good and bad). Abilities to search for files, view thumbnails etc., usual filesystem functionalities are affected.

I think it's quite early but it is an intriguing project. Like others, I would love to learn more about the folks behind it as well as the product details.

I wrote a little bit about data security, especially cloud data security a while back: http://vuongnguyen.com/personal-business-cloud-security.html if anyone is interested in my humble opinion.

-V.

I'm not totally up to speed on encryption techniques, but it looks like this makes it somewhat obvious that you have encrypted files on your machine by mapping a new encrypted file 1 for 1 to the files that you're storing.

In this case, wouldn't you lose plausible deniability? If I remember there's a feature in TrueCrypt which allows you to have two passwords, a fake password that you could use if questioned that decrypts a portion of the volume, and the real password that decrypts the entire thing. I maybe conflating two separate things, though.

You're correct. If you want plausible deniability, you should definitely use TrueCrypt. Safe was not meant for this.

Safe is mainly for making it difficult for casual snoopers to view your data. For instance, if your computer or external hard drive gets stolen.

Safe and TrueCrypt form an ecosystem of encryption tools. Safe is a bit more user-friendly but it's for casual use. For special circumstances TrueCrypt is a better tool. Compare butter knife to swiss army knife.

This website doesn't tell me ANYTHING about what Safe actually does. The SVG tour says it "prevents" other people from seeing my data, but given the low competence most products have with regard to security, without details, I am never going to trust it.

Edit: I found this after installing the app: http://www.getsafe.org/about it has a bit more detail.

There's a much easier way to build the same functionality: use encrypted sparse disk images. See the `hdiutil` command line tool.

I used this many years ago to build a Mac app with the exact same functionality, and probably much safer encryption: http://excesapp.com/

How does your app derive a key from the user's password?

It doesn't; I leave it to Apple's code to handle the encryption aspect. That said, I'd imagine that it uses PBKDF2 to derive a key from the password. The content itself is encrypted with AES-256. Here's what `man hdiutil` has to say about it:

    -encryption [AES-128|AES-256]
        As of 10.7, the default algorithm is the AES cipher running in CBC mode
        on 512-byte blocks with a 128-bit key.

Not sure why I'm being downvoted for sharing this. Go figure, HN can be mean sometimes.

That's a good way of doing it. I would have prefered scrypt but PBKDF2 is good enough. (Something changed with HN recently, I get the downvotes too.)

Is this closed-source? What crypto algorithm and library are used? Who are the developers?

The website at getsafe.org has very, very little info for a crypto app. I understand the need to keep the pitch simple for casual users. But the website needs a link to much more detailed info for those of us who know some things about security.

it's free software, more info can be found here: http://www.getsafe.org/about

The home page really ought to link there. (As of this writing, it did not.)

That's an interesting workaround for not having FUSE on Windows - create a WebDAV server and mount it. It looks like it shells out to net.exe which makes me wonder if there's a Win32 API for doing that.

Other options for FUSE-ish things on Windows are CBFS and Dokan.

Why not use an encrypted sparse bundle?

Safe might be a better fit if you need to access your data from Windows as well as Mac OS X. Also Safe is open source so you know what it's actually doing.

If you don't care about cross-platform or open-source then encrypted sparse bundles are great!

Reply on news.ycombinator.com