netheril96 / securefs Goto Github PK

I didn't see a way of displaying the application's current version like securefs -v or securefs version.

Couple of questions:

1. Did I just miss this somewhere?
2. Is there anything in the current code that ties the version to the git tag?
3. Would you be open to a pull request for a version command?

Thanks in advance!

Can I suggest to introduce an info option like encfsctl does, stating for a filesystem what format was used ,created by which version and also some info about encryption settings used.
I appreciate that some of the information can be found in the .json file, however I guess such an option would add more transparency eg. on the formats (see prev. post) and also generally.

Thanks
[edit : could also be useful for frontends like Sirikali (->properties) in which this currently works for eCryptFS]

This observation is more a question to gain a deeper understanding than an issue :
Case 1:
I'm usually compiling&running securefs in lmde2 on a physical machine (AMD FX CPU).
Then I did a backup of the above OS using fsarchiver.
The backup was then "installed" on a laptop (i5 m520 CPU) in a virtual machine (vbox, host OS Ubuntu).
Both CPUs have the same hardware features (securefs version)
Securefs unlike other programs no longer works but fails with 'invalid machine command' - in order to get it running I need to compile it again in the VM and copy to /usr/local/bin.

Case 2: I also noticed that I can't just on the same physical machine copy the compiled securefs say from lmde2 to Ubuntu although it's both 64-bit architecture.

With regard to case 2, I was thinking that this is further to different libs installed, but I'm clueless why this is happening in case 1, the compiled executable seems to be tailored to the individual architecture.

So, the question is can there sth be specified to compile a more "generally" working securefs . executable.

Thanks

Hi, thank you for the great software. I wanted to ask some very simple questions as a user of this product which if you find helpful can put up in a wiki for others. I am not very well versed in Cryptography, so maybe some questions are already answered in README.

• Does having config file separately stored from the content helps against attackers(newbie version of #9 i think)? How much(its ok if you can only give your opinion on this)
• How much damage will occur if I lose some files in encrypted folder. My take: as it is block level encryption and have no information about files, this can impact some files depending on how those files were structured on file system.
• How compressing the encrypted content affects the content? Which compression tech/algo can be used safely?
• Can I(in future versions maybe) tell the (max or min)size of blocks to be generated? Let's say I want to generate files less than 1Mb.

Again, thanks for the awesome software 😄

Hello,

this is a fascinating project and implementation, but I've just wasted two hours setting it up and debugging an issue for what turned out to be something that was by design. As it turns out, securefs does not fit my use case.

In README.md, "efficient cloud synchronization" is advertised.

I had assumed that I was able to use securefs with synchronized directories such as Dropbox or iCloud Drive on multiple machines at once (because that's what cloud sync is primarily used for.) However, I only later found out that, by design, this is not possible. The comparison to encfs, where this use case is possible, does not mention the issue either.

I'm raising this ticket to kindly ask you to add a big and obvious note to README.md mentioning how and why the user must take care of ensuring that the encrypted storage is never written to simultaneously by multiple machines, or data may go missing.

1. Execute securefs create C:\Vault
2. Execute securefs mount C:\Vault Z:
3. Create C:\love.txt and put Love is all you need in. Note its size is 20 bytes.
4. Copy love.txt to Z:\ and see how Windows reports its size has become 64 bytes.

Expected: Z:\love.txt must match the size of c:\love.txt, i.e. 20 bytes.

Checksums of both files, however, match, nevertheless it’s quite confusing to the eye.

Issue

Creating a symbolic link on a NTFS drive gives this error: getattr path=/link.txt encounters exception securefs::VFSException (code=5): Input/output error

System

• OS: Fedora 26
• latest version (commit 2596467)

Steps to reproduce

1. Create a format 4 filesystem on a NTFS drive
2. Mount the filesystem somewhere
3. cd %mount_point%
4. touch empty.txt
5. ln -s empty.txt link.txt (Error)

How to fix it

I did some initial digging and it looks like buf->st_size is greater than the extracted link size.

Solution: Replace != buf->st_size with <= 0 and resize the string will fix this issue, because we want to determine the link size.

Well, I don't know why the buffer size is greater than the extracted link size.

Edit: Created PR #44 for a fix.

I just saw this on onethingwell. It looks interesting. Would you mind comparing it to eCryptfs? Of course, eCryptfs is not a FUSE filesystem, but other than that, they seem comparable.

Of particular interest is performance. For example, eCryptfs makes listing files in large directories quite slow, because it has to read the first part of each file (IIRC, to get the file's decrypted size). There is no cache other than the kernel's page cache. If securefs could help mitigate this problem while maintaining security and performance, it would be a big improvement.

https://paste.debian.net/440992/

Compared to EncFS, securefs has advantages. However, it's only available on Linux and OS X right now.

Feature request: Port to Windows

Is it possible to move the .securefs.json file after having created a securefs?

Additionally, could the user reference the .securefs.json file from virtually anywhere? Say that I moved to a different computer with my securefs based in the cloud. Would it still be possible to access the directory from the new computer where the .securefs.json is in a different file path?

Issue solved:

Solution is to use command as follows:
securefs mount --config "PATH to .securefs.json" "data_dir" "mount_path"

In the mentioned version,trying to unlock a volume with a wrong password while running in the foreground produces the below output:

[mtz@ink ~]$ securefs mount 0000 www
Password: 
[Error] [0x7f66ebf62740] [2017-02-09 11:23:11.159756216 UTC]    Invalid password
[mtz@ink ~]$

trying to do the same above but running securefs in the background produces the following output

[mtz@ink ~]$ securefs  mount -b 0000 www
Password: 
[Warning] [0x7f2d1b534740] [2017-02-09 11:23:39.994541890 UTC]    securefs is about to enter background without a log file. You won't be able to inspect what goes wrong. You can remount with option --log instead.
[mtz@ink ~]$ 

The difference is that the Invalid password string is no longer there and this confuses sirikali because securefs now does not behave the way it expects.

.This bug is a minor bug compared to cryptkeeper bug as discussed here[1] and it makes me uneasy.

It will very much appreciated if you could document how external tools like SiriKali should interface with securefs and have tests that make sure the interface does not change.

A C based library API will also welcomed.

[1] tomm/cryptkeeper#23

Compilation and execution went fine, however when I try to drag and drop any file to the mounted FS, I get a "not enough free space" error, and I end up with eth zero sized file.
I can create folder without problem though.

Currently settings and encryption key is stored in .securefs.json which is located in the folder with all the encrypted data.
Would it be possible to add an option to specify the path for the settings file so that it could be stored on some external media separate from encrypted data or in separate folder that is not synced with the cloud?
In this setup the mount command for example could look like:
securefs mount --config /mnt/external/.securefs.json ~/Secret ~/Mount

Win7 x64, SecureFS 0.8.1, WinFsp 2017.2 B2

Various file managers exist. Some of them (e.g. Windows explorer, Unreal commander, FAR) reserve space before copying files, others (e.g. Multi commander) start copying right away. All show excellent performance when dealing with normal disks. Now let’s copy to an encrypted disk. If the file is large enough, there are a huge delay (~1 min for 1.5 GiB file) and a low transfer speed (~10 MiB/s) in the first case, whereas neither delay nor slowdown is noticed in the second case.

To illustrate the issue I used Double commander, which Copy dialogue allows to reserve space or not.

Being not a developer, but a mere user, I can only assume the issue is related to a premature attempt to encrypt space being reserved with no actual data in it. Well, you are in a better position to judge.

The common pattern with these FUSE based projects that encrypt folders is to run in the background by default with an option to run in foreground to override the default.

What was the reason for deciding to run the project in the foreground and with no option to run in the background?

Glad that you published a Win version, as I've no option to complie this myself, (therefore cannot test the x86 version). After having installed Winfsp RC2 and VC++15 I was able to create via securefs c a data dir without issues - fine. Mounting however doesn't work, securefs m j:\datadir w: still ends with a complaint that it mount path must be a drive letter. Has anything like that been reported already to you ? Would you assume it's more an Winfsp problem ?
Thanks
[edit : Win 7 x64 Ultimate]

SiriKali 1.2.4[1] was just released and it now works in OSX giving OSX users a GUI solution to manage their securefs volumes.

SiriKali always worked in linux.

Note: securefs application must be installed for this to work.

[1] https://github.com/mhogomchungu/sirikali/releases/tag/1.2.4

Building of 0.7.3 fails on Debian based LMDE2 whilst 0.7.2 does perfectly.
No issues on Ubuntu 16.04.
Is there any library which needs to be installed in addition ?
Thanks
I enclose the last lines plus attached make output.

/temp/securefs-0.7.3/sources/lite_fs.cpp:475:1: error: expected ‘}’ at end of input
CMakeFiles/securefs-static.dir/build.make:54: recipe for target 'CMakeFiles/securefs-static.dir/sources/lite_fs.cpp.o' failed
make[2]: *** [CMakeFiles/securefs-static.dir/sources/lite_fs.cpp.o] Error 1
CMakeFiles/Makefile2:96: recipe for target 'CMakeFiles/securefs-static.dir/all' failed
make[1]: *** [CMakeFiles/securefs-static.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2

073.txt

After upgrading OS to 10.12.3, securefs started working. But now it doesn't show files in mounted directory.

1. I created secure folder securefs create Asd
2. I've mounted it securefs mount -v Asd Qwe
3. cp image.jpg Qwe/image.jpg
4. ls -la Qwe/, it's empty
5. ls -la Asd/, I see that new file is created

Same with directories. But sometimes after re-mounting I see files in mounted dir Qwe.

$ securefs version
securefs 0.7.2
Crypto++ 5.65
osxfuse 3.5.6

Hardware features available:
SSE2: true
SSE3: true
SSE4: true
AES-NI: true
CLMUL: true

If the underlying filesystem supports xattr, so will sucurefs

• The name of Apple's operating system is macOS, not OS X (this changed with 10.12)
• You can install osxfuse with homebrew with brew cask install osxfuse (instead of using the osxfuse website). This fits better with using brew to install securefs.
• Securefs is no longer in homebrew/fuse (deprecated), the command to install it is now brew install securefs.

Hi there! I am the author of gocryptfs and have just now seen your post at https://news.ycombinator.com/item?id=10846320 . Nice to see another project working in that area :)

Anyway, of course I immediately wanted to try it out and hit this compile error (followed by lots of similar messages, but I am only posting the first one for brevity):

cpu.h: In function ‘__m128i _mm_clmulepi64_si128(__m128i, __m128i, int)’:
cpu.h:51:1: error: redefinition of ‘__m128i _mm_clmulepi64_si128(__m128i, __m128i, int)’
 _mm_clmulepi64_si128 (__m128i a, __m128i b, const int i)
 ^
In file included from /usr/lib/gcc/x86_64-redhat-linux/5.3.1/include/x86intrin.h:43:0,
                 from /usr/include/c++/5.3.1/x86_64-redhat-linux/bits/opt_random.h:33,
                 from /usr/include/c++/5.3.1/random:50,
                 from /usr/include/c++/5.3.1/bits/stl_algo.h:66,
                 from /usr/include/c++/5.3.1/algorithm:62,
                 from stdcpp.h:18,
                 from cryptlib.h:83,
                 from iterhash.h:4,
                 from vmac.h:4,
                 from vmac.cpp:5:
/usr/lib/gcc/x86_64-redhat-linux/5.3.1/include/wmmintrin.h:116:1: note: ‘__m128i _mm_clmulepi64_si128(__m128i, __m128i, int)’ previously defined here
 _mm_clmulepi64_si128 (__m128i __X, __m128i __Y, const int __I)
 ^

This is on a recent Fedora 23 with g++ (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2)

Best regards,
Jakob

So, I saw this commit 351cb13, will be affecting the file encryption by not writing at the end of the file.

1. Is there an ETA on when the next Windows compilation will be released? or at least a guide on how to compile it ourselves since Travis doesn't compile Windows builds. I got a bunch of huge files that have the delay mentioned whenever I try to transfer.

2. Will the encryption change affect already existing files? AKA Will new files be uploaded/written because of this?

When storing very large files (> 1 GB), the .meta files tend to be multiple megabytes of storage. When altering the block-size, I can manage to substantially lower the .meta file size at the cost of some transfer speed. I was wondering why such large .meta files are created by this design.

When I was examining the design docs, I noticed this schema for storing the metadata for the file. Other file encryption options like Cryptomator, have substantially less overhead in external file creation, maxing out at a kilobyte.

The reason I bring this up is because these files make streaming or navigating directories very difficult. In this situation, I am mounting a secureFS volume ontop of Google Drive File Stream's mount. After uploading and clearing the local cache of the encrypted volume, every time I remount, the .meta files are redownloaded. This means that large volumes of large files will result in a massive local cache. I got around this by manipulating the block-size to much higher values, but I am unsure of the security vulnerabilities this may be creating. Is there any way to keep the original 4kb block encryption, but also keep the size of the .meta file reasonably small?

can this use in windows?

OS: Windows 7 x64

Try mount:

securefs m D:\Data_Crypt_SFS D:\Data\

[Error] [0000000000003EA4] [2018-01-19 09:52:44.869302300 UTC]    The mount point
must be a drive path, such as Z:

But I think it's possible. encfs4win can do it. (command: "encfs.exe d:\Data_Crypt\ d:\Data")

Currently securefs just crashes causing users to think the problem is with SiriKali instead of securefs.

Hi,

I have been looking for a solution to encrypt my dropbox files and found securefs which looks most promising to me. Are there users who use securefs with Dropbox for daily use?

I am trying to use a securefs to encrypt some of my data on ownCloud / dropbox.
I created a encrypted directory on my work machine using securefs create ~/private, yet when trying to mount it from my home machine I get an error after putting my password:

Config file private/.securefs.json does not
exist. Perhaps you forget to run create command first?

What do I have to do to access the encrypted folder on another machine? It looks like that owncloud did not sync the json file.
Any help highly appreciated!

C:\Qt\5.9.3\mingw53_32>"C:/Users/<USER>/bin/securefs.exe" info "C:/Users/<USER>/Desktop/.securefs.json"
[Error] [0000000000000E68] [2018-03-17 07:41:03.918719100 UTC]    The path C:/Users/<USER>/Desktop/.securefs.json/.securefs.json does not exist. Perhaps you are pointing to the wrong data directory?

C:\Qt\5.9.3\mingw53_32>

The above options works fine on the linux version of securefs

As the heading say,when mounting a volume in windows,the process stays on the foreground instead of going to the background.

Example output is below,the output says the process is going to a background but it does not. While on the foreground,the process can be unmounted by sending "ctrl+c" key combo, how is the volume supposed to be unmounted in windows when it finally goes to the background?

C:\Qt\5.9.3\mingw53_32>securefs.exe mount -b  -o rw -o fsname=securefs@"C:/vault" -o subtype=securefs "C:/vault" "Z:"
Password:
[Warning] [0000000000000EC8] [2017-11-28 21:58:37.215888200 UTC]    securefs is about to enter background without a log file. You won't be able to inspect what goes wrong. You can remount with option --log instead.
The service securefs has been started.
The service securefs has been stopped.

C:\Qt\5.9.3\mingw53_32>

I ran sudo securefs m ./secfs /Volumes/GMBSDATA, and this seemed to work. After exiting, the directory /Volumes/GMBSDATA could not be removed with sudo rm -rf even. Non-root actions just say /Volumes/GMBSDATA/: Permission denied (ls just says : : Permission denied), while sudo rm -rf says rm: /Volumes/GMBSDATA/: Device not configured. Other commands just say cmdname: /Volumes/GMBSDATA/: Device not configured. I would try removing it in finder (on a mac), but it does not show up in finder for some odd reason. A full reboot does not remove this directory entry either. Attempting to sudo cd /Volumes/GMBSDATA does not show any error and exits clean (exit status=0), but does not actually modify the pwd nor change the directory.

The output of ls -la pertaining to the directory:
drwx------ 1 root wheel 0 31 Dec 1969 GMBSDATA

I got the above directory destroyed eventually with diskutil, for some reason it thought it was a device rather than a mount point. After that, I tried again, and mounted it as a directory that I could read and stuff, but I dont know how to unmount it. Killing command doesnt work, only reboot seems to work

I figured out the problem, on Mac OS, you CANNOT try to mount into any subdirectory of /Volumes. I am not sure the exact reason, but it does not seem to be a problem with securefs itself, rather OSXFUSE. Using sudo with securefs allowed it to create an access directories within /Volumes, but for some reason does not actually work as expected. See osxfuse/osxfuse#306. According to this, there is a workaround that can be implemented on the FS side (osxfuse/sshfs#27). This would likely be platform specific code, as it is only needed for OSXFUSE, so I am not sure if that would be acceptable or not, but if this is not implemented, I feel a statement should be added to the README about mounting to /Volumes/ not working on Mac OS.

When you obfuscate the directry structure, it makes sense to do the same with the file size.
IMO it's the only feature missing from securefs.

Hi, securefs create Name worked perfectly. But mounting didn't work. I've installed fusefs.

Error

$ securefs mount Asd Qwe
Password:
dyld: lazy symbol binding failed: Symbol not found: _clock_gettime
  Referenced from: /usr/local/bin/securefs
  Expected in: /usr/lib/libSystem.B.dylib

dyld: Symbol not found: _clock_gettime
  Referenced from: /usr/local/bin/securefs
  Expected in: /usr/lib/libSystem.B.dylib

[1]    19382 trace trap  securefs mount Asd Qwe

version

$ securefs version
securefs 0.7.2
Crypto++ 5.65
osxfuse 3.5.5

Hardware features available:
SSE2: true
SSE3: true
SSE4: true
AES-NI: true
CLMUL: true

I've already tried doing xcode-select --install

$ xcode-select --install
xcode-select: error: command line tools are already installed, use "Software Update" to install updates

Below output is what i observe when i attempt to unlock a securefs volume created with one of the previous versions(i cant remember which one)

[mtz@ink ~]$ securefs mount  ../images/securefs/ sss
Password: 
[Warning] [0x7f1d027bb740] [2017-02-10 15:40:23.523422408 UTC]    Your filesystem is created by a vulnerable version of securefs.
Please immediate migrate your old data to a newly created securefs filesystem,
and remove all traces of old data to avoid information leakage!
Do you wish to continue with mounting? (y/n)[mtz@ink ~]$ 

As you can see,the question is asked by the application returns without waiting for a response. It also returns with zero indicating success when no such thing happened.

The behavior is there too when trying to run securefs as a daemon.

As I tried to open with the latest build a securefs volume made with a previous version on macos Sierra, I get this message:

[Warning] [0x7ffff1c943c0] [2017-02-22 22:36:44.926599000 UTC]    Your filesystem is created by a vulnerable version of securefs.
Please immediate migrate your old data to a newly created securefs filesystem,
and remove all traces of old data to avoid information leakage!

I am unable to enter any input, the message asking for input displays and the app immediately quits, leaving me no chance to answer.

Do you wish to continue with mounting? (y/n)MBPsolid:~ user$

I'm encountering decryption failure in 0.7.1 format 4 (format 2 works with the same files and folders) on Linux/Debian 8 based
Here's the linux (ext3 fs) process :
Basically a /test/test source is created (755) , then mounted to ~/secfs - fine.
One file (doublecmd) copied to ~/secfs. fine. The encrypted content appears as expected in /test/test with approx the same file size - fine I at first sight.
Copying back the file from ~/secfs to plain folder /test/uu (755) fails.
Log file :
[Info] [0x7f770308f700] [2017-02-23 01:30:01.886835802 UTC] init
[Error] [0x7f770208d700] [2017-02-23 01:30:23.194514718 UTC] chmod path=/doublecmd encounters exception securefs::POSIXException (code=95): Die Operation wird nicht unterstützt (chmod /test/test/ENXU72UM4EJARGK2RGFDCIU7HWGZ4C8ZBJ6XSHWC with mode=0100755)
[Error] [0x7f770208d700] [2017-02-23 01:30:56.496889264 UTC] read path=/doublecmd offset=131072 length=131072 encounters exception securefs::LiteMessageVerificationException (code=1): File content has invalid checksum
[Error] [0x7f770308f700] [2017-02-23 01:30:56.496927712 UTC] read path=/doublecmd offset=262144 length=131072 encounters exception CryptoPP::AuthenticatedSymmetricCipher::BadState (code=1): AES/GCM: TruncatedFinal was called before setting key and IV
[Error] [0x7f770308f700] [2017-02-23 01:30:56.499519217 UTC] read path=/doublecmd offset=393216 length=131072 encounters exception securefs::LiteMessageVerificationException (code=1): File content has invalid checksum
[Error] [0x7f770288e700] [2017-02-23 01:30:56.499548316 UTC] read path=/doublecmd offset=262144 length=4096 encounters exception CryptoPP::AuthenticatedSymmetricCipher::BadState (code=1): AES/GCM: TruncatedFinal was called before setting key and IV
[Info] [0x7f77044f6740] [2017-02-23 01:31:19.076682546 UTC] destroy

First thought this was related to access rights, but as I wrote it works using format 2 and also fails using a similar test on an NTFS partition.

The following strange issue has been observed using Win7 SP1 Enterprise ans SecureFS 0.81 (same in 0.80, 0.73) / WinFsp 1.3 (also with WinFsp 1.2).
In essence file format 3 produces strange modification timestamps (creation & last access dates are fine), see below .
I understand that this format stores timestamps, unfortunately I couldn't reproduce this behaviour though on Win7 SP1 Ultimate (works as expected there) nor does the logfile indicate anything (to me)
When for instance copying files to SecureFS folder, one for a half a second sees in explorer the expected filedate before it refreshes and shows blank
I enclose the filesystem itself (password : test / lockfile needs to be deleted first,sorry) and the logfile.
This issue of course can be specific to the setup of the (work) PC but maybe you've got an idea

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten.

h:\Crypt\SecureFS>securefs v
securefs 0.8.1
Crypto++ 5.65
WinFsp 1.3

Hardware features available:
SSE2: true
SSE3: true
SSE4: false
AES-NI: false
CLMUL: false

h:\Crypt\SecureFS>securefs c --format 3 e:\SecureFS
Password:
Again:

h:\Crypt\SecureFS>securefs m e:\SecureFS W: --log b:\log --trace -v
Password:
[Trace] [0000000000001448] [2018-03-06 12:52:18.267997300 UTC] Opening file o
n a NTFS volume
[Verbose] [0000000000001448] [2018-03-06 12:52:18.272997300 UTC] Setting the
password key derivation function to scrypt
[Verbose] [0000000000001448] [2018-03-06 12:52:18.623997300 UTC] Raising the
number of file descriptor limit to 65535
[Verbose] [0000000000001448] [2018-03-06 12:52:18.627997300 UTC] Filesystem p
arameters: format version 3, block size 4096 (bytes), iv size 12 (bytes)
[Verbose] [0000000000001448] [2018-03-06 12:52:18.627997300 UTC] Master key:
253b5cd7eda0ec6ff3cc3b67cf48edc0b3fd70605d0f65c300747682893b0cb5
[Trace] [0000000000001448] [2018-03-06 12:52:18.628997300 UTC] Opening file o
n a NTFS volume
Filesystem mounted successfully
The service securefs has been started.
Filesystem unmounted successfully
The service securefs has been stopped.

w:>dir w:\

log.txt
SecureFS_filesystem.zip

Verzeichnis von w:\

01/01/1601 01:00 16 xxx.txt
01/01/1601 01:00 16 yyy.txt
2 Datei(en), 32 Bytes
0 Verzeichnis(se), 129,510,547,456 Bytes frei

This issue affects the current master branch.

The symptom is that any copy operation using Finder or another Apple-native file UI is stopped with an 'out of disk space' error.

I assume that this is caused by the FUSE-mounted drive showing up as having zero bytes free and total space. Finder appears to use these numbers to prevent starting a file copy operation which is guaranteed to fail.

Creating files via Terminal works as expected.

Any chance to have this added somewhen in the future ?

I tried to mount an encrypted file system using this command:

$ securefs mount ~/Secret ~/Secret

This causes the process to hang, the Terminal with it, and any process trying to list the ~ directory.
Does securefs use the high-level fuse API that returns file path instead of inodes? This may be the reason of the deadlock, causing recursing again and again, but I may be wrong.

Why am i always getting version 0.7.2 ?

I'v run

git clone https://github.com/netheril96/securefs.git
cd securefs
cmake .
sudo make

╭─greg@greg-Inspiron-5767 ~/securefs  ‹master*› 
╰─➤  securefs v
securefs 0.7.2
Crypto++ 5.65
libfuse 29

Hardware features available:
SSE2: true
SSE3: true
SSE4: true
AES-NI: true
CLMUL: true

I did have securefs 0.7.2 already installed. I tried "git pull" from within the dir then "cmake/make" and it wouldn't update so i deleted the whole folder and started again but got the result above.

Thank you.

encfs has a feature, --reverse which is very useful for for making encrypted backups to cloud storage providers.

Is there anything like that here?

Out of curiosity,i decided to check how securefs behaves when a log file can not be created like when its path is on a read on folder and i run the latest git version with the below command

[mtz@ink ~]$ securefs mount --log /eeeee ../images/securefs/ sss/
Password: 
[Info] [0x7f5e1f546740] [2017-02-10 16:46:20.230438609 UTC]    Raising the number of file descriptor limit to 4096
[Info] [0x7f5e1f546740] [2017-02-10 16:46:20.230493117 UTC]    Mounting filesystem stored at ../images/securefs/ onto sss/ with format version: 2

Observations i made are:

1. A text file named .securefs.lock is left behind in the cipher folder preventing subsequent attempt at mounting the volume and the generated error messages are below

[mtz@ink ~]$ 
[mtz@ink ~]$ securefs mount ../images/securefs/ sss/
Password: 
[Info] [0x7fb888dfb740] [2017-02-10 16:49:00.711782088 UTC]    Raising the number of file descriptor limit to 4096
[Info] [0x7fb888dfb740] [2017-02-10 16:49:00.711831413 UTC]    Mounting filesystem stored at ../images/securefs/ onto sss/ with format version: 2
[Error] [0x7fb888dfb740] [2017-02-10 16:49:00.711942629 UTC]    Encountering error File exists (Opening /home/images/securefs/.securefs.lock with flags 0300) when creating the lock file ../images/securefs//.securefs.lock.
Perhaps multiple securefs instances are trying to operate on a single directory.
Close other instances, including on other machines, and try again.
Or remove the lock file manually if you are sure no other instances are holding the lock.

I'd like an option to store ctime and mtime in the the .meta file (or similar) instead of relying on the underlying filesystem for that. The reason for this is that many cloud filesystems don't preserve timestamps properly (or at all).

firstly, greatly appreciated that securefs is , so to say, several formats, cryfs-style and encfs under one hood.
can you however please advise on the full format, it's stated on the website that "To request full format, which is no longer the default, run securefs create --format 2.".
I would have thought that format version 3 should be the most evolved b-tree format ?
I also understand that versions >0.7.0 support reading format 1-3 created by old versions affected by security flaws (with the bug just reported fixed), but therefore e.g version 0.5.4 cannot mount format 3 created by version >=0.7.0 (InvalidArgumentException: Unsupported version 3) - correct ?
So in effect it appears that format 1-3 are now more format subversions like 1.1 etc and in this case would suggest to introduce such kind of numbering.

I know --config can be used to move the json file elsewhere, but I'd like to use securefs to safely store all my passwords, banking information, documents, etc. on a memory card for emergencies or in case my laptop dies.

However, when an attacker, thief, or other adversary finds the memory card, that .json tells him he's dealing with encrypted data, and gives him some useful information (block_size, etc.)

For this reason I'd like to request some kind of obfuscation (let's says something better than xor...) to be added to the data in the json file.

SiriKali can manage securefs volumes using a key and a keyfile since it generates the effective key by itself and then passes on the result to securefs.

The above creates a problem if a user tries to unlock the volume independently of SiriKali and it will be best if securefs also has this ability.

Proposed solutions.

1. An option to use a Key. This already works.
2. An option to use a keyfile.
3. An option to use a combination of a key and a keyfile with the effective key generated with the below formular: key = hmac(sha256,password,keyfile)

ubuntu 16.xx
g++
cmake

way:
cmake .
make
make install
sudo make install

gin@gin-VGN-SR45H-P:~/workspace/securefs$ securefs create ~/ginPlace
Password:
Retype password:
POSIXException: No such file or directory # Opening /home/gin/ginPlace/.securefs.json with flags 0301