gocryptfs
gocryptfs copied to clipboard
rfjakob
Feature Request: Fully-deterministic AES-SIV mode
Hello, great work and amazing performance from my tests so far!
In cppcryptfs documentation this is mentioned:
"Note: when you mount a filesystem using AES256-SIV in forward mode, any new encryption is done non-deterministcally (as is the case with gocryptfs)."
Is this really the case and if it is, why is it so? In order to avoid copy pasting the same thing here I'll link to the issue there: https://github.com/bailey27/cppcryptfs/issues/15
Hi there, thanks for the report. A few things:
-
Are you aware that reverse mode is read only? I didn't understand your synchronisation scheme completely, just wanted to make sure this does not bite you.
-
Determinism: every 4kb ciphertext block has a 16 byte nonce header. aes-siv does not strictly need a nonce, but i wanted to keep the file format the same as for aes-gcm. In aes-siv forward mode, a random value is stored there, because it improves security somewhat. But I agree that this should be configurable or even off by default.
Yes I do understand the read-only part. I am only doing one-way sync of those directories (they contain c++ sources I am actively working on plus a few other things that can't really be encrypted on the local copy). All I want in my scheme is for them to be backed up and encrypted on the remote untrusted location (gdrive) and available to the local network so I can pull copies. Most of them are repositories on my own gitlab server so this serves mostly as an always accessible backup in case something is wrong with the gitlab server and temporary backup of changes that have not been commited to git yet. If I need to manually replace a file there as part of some repair operation, it would be nice if the sync program did not detect different files and try to upload again.
Since we're discussing this however would writable reverse be possible at any point? Is there any technical reason on why reverse is ro? Write support would greatly boost what you can do with syncing etc.
I think it makes sense to have aes-siv deterministic in forward mode as well. I'll change that in v1.4.
Read-write is technically feasible, it's just not implemented. Having the mount read-only simplifies the code considerably, and for backups you usually want read-only access.
I have started thinking about and working on this. In reverse mode, the file initialisation vector (makes sure that identical files in different directories encrypt differently) is based on the path to the file. Reverse mode is read-only and this works fine.
However, in forward mode, files (and directories) can be renamed. Files are not re-encrypted when they are renamed because this is not feasible for arbitrarily large files and directory structures. They keep their initialisation vector. So this means you get different ciphertext from these two ways to create a text file:
Direct:
echo hello > 1.txt
Rename:
echo hello > 2.txt
mv 2.txt 1.txt
Which is pretty darn unexpected for a user. Given this problem, I'm no longer sure this is a good idea.
Hmrr. This is tricky indeed. It also means that writable reverse is also not possible in the future as well unless the implementation changes. Crypto algos and implementations are far from my strong point. Is there any particular reason why identical files in different locations should contain different ciphertext? Does it provide an extrapolation-style attack vector? I would assume not considering the file is identical in the first place. Excuse my inadequate knowledge on the subject :) Perhaps if the goal is to eventually provide a full reverse (R/W) functionality etc, the implementation should be built around the limitations.
It's hard to judge the effect of making identical files identifiable, this will also depend on what kind data is stored. However, this is information we have not been leaking before, so I'm hesitant to change SIV mode to work like that.
Well considering the only real use for SIV is the reverse mode and, as far as I've read in the reverse mode issue, it was implemented just to provide this functionality, I see no reason why it should not behave differently. Also considering it does not provide any benefit to security and the performance is 50% slower, on average, the only reason you would set it up is reverse. With this in mind, it may as well be used to provide a fully functional R/W reverse model. But it's your choice of course. :)
EDIT: Otherwise write reverse is not possible and it will remain a encfs-only feature.
I think the way to go is adding a command-line flag that disables all randomness (in forward mode) and dependency on the path (in reverse mode) when encrypting. I don't think I'll implement it myself, but I'll accept pull requests.
Hi
I found this open issue when trying to better understand the AES-SIV mode in forward mode. First of all, I'm trying to answer this question: What is the real use-case for the current implementation of the -aessiv flag?
Actually, when studying the issue #151 , I thought that that the -aessiv flag would create the .diriv files in forward mode the same way they are created in reverse mode, ie.: deterministically from the path of the folder. This would help to avoid the problem described in that issue, where two computers, synced over the internet, create the same folder, but with different .diriv files, so one's overwrites the other...
Don't you think it would be interesting to implement the deterministic .diriv file generation in -aessiv mode? It would help mitigate the problem described in that ticket. However, if we rename a folder, we may keep the existing .diriv file, otherwise we would incur in the expensive hierarchical renaming of all sub-folders, as in EncFS... (that's why I used "to mitigate" instead of "to solve" the issue :), we are just trying our best to avoid the problem). At least, it shall be implemented in the fully-deterministic aessiv mode.
This way, we could recommend the users in that situation to use the -aessiv flag to mitigate that problem... Do you think it is worth the effort? And I come back to my first question: What is the use-case for the current implementation of the -aessiv flag?
Best !
In gocryptfs all options that can be set in the config file are available as command-line options, too. You need that so you can mount a reverse-filesystem without a config file, using -masterkey. So that's the primary use case.
The second use case is when you don't trust AES-GCM. AES-SIV is slower but stronger, because it is robust against nonce reuse.
Syncthing requires two files in a shared folder in order to sync. ".stfolder" and a writable file ".ignore" (will work without .sttignore and this isn't needed if syncthing encrypted files since what would one want to ignore?). Many other real time sync solutions require at least some kind of file in a directory being synced. Reverse mode utilization is limited as a result. Rsync is great but not real time.
Agree with keeping code simple. Could a feature be added were a custom file could be added to an otherwise read only reverse volume? If could get an .stfolder into a reverse folder could utilize reverse mode with Syncthing. A "Syncthing" option that adds a ".stfolder" to an otherwise read-only reverse volume while keeping code simple would be great. If this can be added other similar options could be just as easily added for other programs as necessary/ upon request, assuming that this method would be far simpler than making reverse mode writable.
Isn't the simple solution to the .stlfolder problem to add that file to the parent directory?
If add ".stfolder" to a reverse mode parent directory it will not be seen as ".stfolder." It will be seen as the encrypted file name of ".stfolder."
No i meant the parent dir of where reverse mode is mounted
On Mon, May 28, 2018, 19:10 schnappijedi [email protected] wrote:
If add ".stfolder" to a reverse mode parent directory it will not be seen as ".stfolder." It will be seen as the encrypted file name of ".stfolder."
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rfjakob/gocryptfs/issues/108#issuecomment-392572254, or mute the thread https://github.com/notifications/unsubscribe-auth/AARgf0S0ZdzupzxKXLWuKX3yWb_EjWYUks5t3C-GgaJpZM4Nhdjf .
That is a good idea. Must have been how did it before because could not remember how accomplished previously. However this time using on Windows.
cppcryptfs appears to allow mounting without using a drive letter. Still, largely depending on the amount of code required, might still advocate for a dedicated "Syncthing" option for reverse volumes in order to simplify process for some people.
Was incorrect. cppcryptfs is not able to mount a reverse volume to an empty folder in reverse mode. https://github.com/bailey27/cppcryptfs/issues/22
Some version of this feature would be helpful for further functionality, for example as proposed in #510.
