Hi all:
Just thinking loudly on this schema:
Data > Restic > gocryptfs reverse encryption
Since all software has vulnerabilities or weaknesses, and gocryptfs gives the opportunity to encrypt on fly with FUSE with no space required for it.
I’m just thinking if make sense a +b systems or maybe its worst in terms of possible conflicts… etc…
Thanks
This is a double-edged sword, isn’t it? I mean, yes, you have two layers in case the security of one gets broken, but at the same time, you also have two layers that could have bugs causing data loss.
Aside from that, multiple layers of encryption are often useful because they’re protecting against different issues - using TLS connections to transfer already-encrypted files, for instance. (This is also why it can make sense to use both block-level encryption and filesystem-level encryption.)
Thanks. Make sense, specially if there is no impact in terms of performance and disk space in my case. To be honest, probably it’s completely paranoid. I’m not worried about being compromised on my data, but just thinking loudly about a good best practice.
I’m thinking on double file encryption. I don’t think it will create any kind of collision, corrupt data or something like that.
I saw some password managers that uses double encryption layers.
Any other opinion?
Thanks
That if someone wants your data, they’ll probably get it by other and simpler means than breaking restic’s encryption 
Heck, I’ve been party to a scheme where “backup” revolved around spreading thousands of copies of a large encrypted archive everywhere, relying on the fact that the information inside wasn’t accessible without breaking the encryption.
Mind you, the real opponent in that case already had the data, so it’s a bit of a special case.
Jaja…well… you’re right. Adversaries will not have the data without breaking the encryption.
Here is a good example about what I was trying to explain.
I was thinking of use gocryptfs and…
A good example of needing to be careful: this is a course paper, which does not claim a practical attack on scrypt, like the blog post seems to imply. What’s more, this sort of cache timing attack relies on certain details of how the microprocessor is implemented - the same subsystems Spectre attacks. In essence, if someone is in a position to pull this attack off, they can also just simply read the password out of memory with no further cryptanalysis needed. (Isn’t computer security a fun field?)
Incidentally, restic also uses scrypt for its key derivation, so if there was a problem here, it would apply to both layers.
Yep… agreed. Without having the background for creating a valid opinion I always think on the attack model, and I don’t see how this can affect on a common situation on which we leave I.E our data on Gdrive encrypted without any other info related to it.
I saw that (not restic afaik) some “brothers” to restic, gocryptfs. I.E, leaves a hidden config file on encrypted output that is in clear text. It clearly output the program and version responsible of the encrytion, method …etc…
Is not this kind of info a potential useful leak for the adversaries?
Everything is potentially a useful leak for the adversary. That’s why security systems need to have a well-defined threat model. Most good threat models assume the adversary knows every implementation detail except the keys, and thus identifying information of this sort is acceptable. restic does not leave anything quite that obvious, but the structure of a repository is fairly identifiable. If it wasn’t, restic wouldn’t be able to identify a repository.
ok thanks. Well. I think then is safe restic + gocryptfs and adds value. Maybe I’ll use another layer instead of gocryptfs… duplicity I.E
That comic has a point, but it’s gotten to the point where it feels like people have forgotten that there actually are circumstances where the opponents aren’t able to resort to direct violence quite so easily.
Case in point, we’re using restic rather than just uploading files in plain text. 
Note that WireGuard implements this same concept. In addition to using the mandatory asymmetric ECDH-based encryption, you can additionally layer on symmetric ChaCha20 encryption. Using both protects from a vulnerability discovered in the other.
This is also why it’s common for system administrators to set up a “bastion host” for SSH access to internal servers. One has to pass SSH connections through the bastion as a “jump host.” The bastion is typically configured with an entirely different Linux distro and a different version of OpenSSH than the rest of the servers behind it. The theory is that past vulnerabilities have tended to be very specific to a distro or to a point release of OpenSSH, so the odds of both the bastion host and the servers behind it being vulnerable to the same exploit is very low.
This thread is becoming very long. Can someone please mark an appropriate answer as the solution?
Thanks all for your responses. I think make sense use double encryption but I was not able to see anyone that actually implements it. We need to over use 2 different encryption layers, that usually forces to use 2x backup space. Since I can afford it, its bit complex to perform. Encfs/gocryptfs sounds promising but there is no way to define multiple source folders. I’ll give a try to duplicaty or borg.
do you think the meme you highlighted has ever happened, in reality? Do you know any cases? Just curious.
The problem is that you wouldn’t hear about those cases. If the opponents aren’t constrained by law and willing to resort to violence like that, they would presumably also take measures to ensure you wouldn’t talk about it.
There are examples of law enforcement - which in some places does have restraints on the use of force - using harassment and threats against people with encrypted devices they can’t get into, however. So there is definitely evidence thugs will use that method rather than giving up. (Or going to the NSA.)
