The release of the Restic 0.18 backup system has been announced, allowing for the storage of backups in encrypted form in a versioned repository with deduplication support. The system is initially designed for environments that are not trusted, ensuring that if a backup falls into the wrong hands, the system remains uncompromised. Flexible rules can be defined for including and excluding files and directories when creating a backup (the rules format resembles rsync or gitignore). It supports operation on Linux, macOS, Windows, and BSD systems. The project code is written in Go and is distributed under the BSD license. <\/p>\n
Backups can be stored in local file systems, on external server<\/a> with access via SFTP\/SSH or HTTP REST, on cloud services like Amazon S3, OpenStack Swift, BackBlaze B2, Microsoft Azure Blob Storage, and Google Cloud Storage, as well as in any storage systems for which rclone backends are available. For storage, the developing project rest server can also be utilized, providing higher performance compared to other backends and capable of operating in a read-only mode that prevents deletion or modification of backups in the event of a compromise of the source server and access to the encryption keys. <\/p>\n The system supports snapshots that reflect the state of the directory hierarchy at different points in time (snapshots are automatically created for each backup). Snapshots can be copied between different repositories. To save bandwidth during the backup creation process, only changed data is copied. A snapshot with a backup can be mounted as a virtual partition (mounting is done using FUSE). Additionally, commands are provided for analyzing changes and selectively extracting files. <\/p>\n The backup storage in Restic manipulates not complete files but blocks of variable sizes, chosen using Rabin fingerprints. Information is stored in reference to content rather than file names (data-related names and objects are defined at the block metadata level). To save space in storage and avoid unnecessary data duplication, deduplication is performed. <\/p>\n Information on external servers is stored in an encrypted format \u2014 SHA-256 hashes are used for checksums and deduplication, AES-256-CTR is used for encryption, and authentication codes based on Poly1305-AES are used to ensure integrity. Verification of backup integrity through checksums and authentication codes is available to confirm that file integrity has not been compromised. <\/p>\n In the new version, the possibility of a (PDF) attack that determines the presence of certain files in the encrypted backup storage has been eliminated. This attack allows the identification of whether a specific file exists in the encrypted backup by gaining access to the storage or through network traffic analysis of the backups. For example, the attack could be carried out by a server administrator where backups are stored, an internet service provider, or intelligence agencies that have gained access to server<\/a> or the traffic. The goal of the attack could be to investigate a data leak, in which case the agencies could assess the presence of documents of interest in the backup storage. <\/p>\n To exploit the vulnerability, the attacker must manage to include their data in the victim's backup or know that a file they are aware of is present in the backup. If the backup contains a file known to the attacker (for example, some standard system or multimedia content), then by accessing the encrypted storage, the attacker can determine if other files of interest are also present. <\/p>\n The method is based on the fact that due to the characteristics of content compression, the parameters of the blocks used when fragmenting the content can be identified. It is sufficient to identify three encrypted blocks containing data known to the attacker to determine such parameters. <\/p>\n The vulnerability is not specific to Restic and affects other backup systems using block data splitting techniques such as CDC (Content-Defined Chunking), like BorgBackup, Tarsnap, Bupstash, and Duplicacy. In Tarsnap, the problem was fixed in the 1.0.41 update, and work is underway for BorgBackup to include a fix in the borg 2 branch. The last change in Bupstash was made 2 years ago, and in Duplicacy \u2014 4 months ago. <\/p>\n It is also noted that in systems using deduplication, if there is a possibility to add your files to the backup, it can be easier to determine the presence of interesting files indirectly. After adding the file under review, you can evaluate the change in storage size \u2014 if the file already exists in storage, its re-addition will not lead to a significant increase in size due to deduplication. <\/p>\n In addition to addressing the vulnerability in Restic 0.18, several new features have also been introduced: <\/p>\n\n