Idrive Forgot Encryption Key

[Klacee Sawatzky]

Encryptionis the process of encoding messages or information in such a way that it cannot be accessed without the key used to encode it. IDrive encrypts the files included in your backup set before the data is sent to your destination and it stores the data in encrypted format on your servers. Data encryption, combined with a secure private encryption key, prevents unauthorized access to your information.

IDrive backups are encoded with Advanced Encryption Standard (AES) 256-bit encryption algorithm. The Advanced Encryption Standard or AES is used by the U.S. government to protect classified information and is implemented in software and hardware throughout the world to encrypt sensitive data.

Default Encryption: When you install the IDrive application and choose 'Default Encryption', an encryption key is securely generated for your account. This key will be automatically used to encrypt all your data on transmission and storage.

Private Key Encryption: When you install the IDrive application and choose 'Private Key Encryption', you need to provide an encryption key of your choice. This key will be used to encrypt all the data on transmission and storage. Without this key, users cannot recover the data. This means, if the user loses the Private Key Encryption, then the data cannot be restored and our Technical Support cannot assist with recovery. It is thus recommended that the user archives this key safely to backup and restore data.

Yes. On resetting your private encryption key, all the data from your account will be permanently deleted. So, reset the private key only in case you have forgotten the key or want to upgrade security for your account.

Yes. Enabling the 'Private Key Encryption' option affects ALL of the computers on your account. Setting the Private Encryption Key on one computer sets the same Private Encryption Key for all your computers. You need to enter this Private Encryption Key on all the computers in your account.

There is absolutely no way for IDrive to recover your Private Encryption Key. If you forget or lose your Private Encryption Key, either you have to create a new account or need to opt for resetting your Private Encryption Key. However, on resetting your Private Encryption Key, all the data from your account will be permanently deleted as it cannot be decoded.

Your data resides on RAID-protected storage devices. In addition, we recommend that you keep a local backup of your data, as online backup should be a complementary solution to local backup and not be the ONLY solution for disaster recovery. To secure your local backup, IDrive supports encrypted local backups with Private Key Encryption option.

The information we collect from you is only for the purpose of providing you a backup service and communicating with you about the backup services we provide. For more information, read our complete Privacy Policy.

Hi, i've been saving my data from idriveE2 to move to other provider, also backing up to 2x HDDs. On idrive all was unencrypted, for the other provider, and HDDs i use the same crypt remote. both copies made directly from idrivee2.

So idrivee2-> 1fichier using encryption, idrivee2-> hdd using same encryption, hdd > other hdd using same encryption (this is when i've noticed the errors, also tried to open the same files from the 1fichier, and there same problem).

Some very important files seem to be corrupted on both, same files.

When copying from idriveE2 there wasn't any error shown by rclone, but now when i try to open them from the other provider, or the HDDs, i can't.

The strange thing is, this corruption happens mostly with mkv (matroska) files, but next to these mkv files, the mp4 and other files are playable, independent from size.

But also there are mov files corrupted, some restic backup files, and a 36 gbyte raw disk clone file (hogymeglegyen20210508_2004.ksgp).

But still the copy from HDD to HDD have the errors above, while as i mentioned same crypt used, also exactly the same HDD with same exFAT FS.

I've saw that the very long filenames which are ok on the first HDD, causing the usual too long filename errors (Failed to copy: The filename, directory name, or volume label syntax is incorrect. because of exFAT 255 limit) on copying to the second HDD.

Its strange because everything is the same, also checked the encrypted file and folder names, those are the same too, so the encryption is surely the same, with same lenght filenames, and same lenght paths.

I don't think that will help, as i wrote those files are ok if i open them with rclone mount, but not if i do rclone copy/sync/serve webdav, so the file itself is correct.

But i'll try once the copies are done.

BTW what "Checks" counter means on sync/copy? I'm copying, syncing from an idrive bucket that contains 192000 objects, the target even less (which are from the idrive), yet the "Checks" count on copy is at 500000 and counting.

BTW i thought rclone copy and sync checks each uploaded file, and flags the copy "done" only when the hashes matching, that's why the progress stands at 100% for long time for bigger files. But it seems it isn't as running cryptcheck shows multiple files with differing hashes

But the differing hash files are not the same ones that are erroring on copy from hdd to identical hdd, with same folder structure, same fs, same encryption, while the files are correct on the source.

For hdd backups it seems i should use veracrypt (for platform compatibility, as LUKS not really supported on win) encrypted partition, with NTFS file system in it (its not much slower than exfat on linux), and rclone crypt will be only used for cloud storage.

You are using default base32 files' names encoding - it leads to encrypted names to be much longer than originals but works on any filesystem and cloud storage - it uses basic ASCII characters and does not care about their case.

It tells you that base32768isOK = true meaning that all needed characters are supported. In addition maxFileLength for 2 byte unicode chars is the same as for 1 byte characters. Both together indicate that on this filesystem I can use filename_encoding = base32768 and save much longer names that with default base32. In practice max name length can be assumed in this case the same as in unencrypted file system.

how base32768 encoding works? I think the first byte value identifies the encoding like in base64, so adding the encoding parameter to read back the files isn't needed, but still it would be easier and nicer to be able to set the default encoding for the crypt remote.

What happens if i set filename_encoding = base32768 for a crypt remote that has filenames in default (base32) and do a copy, or sync? It will add the newly copied files with base32768 and leave others, or will convert all filenames to base32768?

Files and directories with different then set in config encoding won't be readable. You can create new remote with different encoding and move all content from old remote. As long as both are within the same remote and you use the same password(s) for both crypts then only names will be re-encoded - content stays the same so all operation is fast.

But there is another problem, not with the length of filenames: there are some files that are can't be uploaded to 1fichier through my crypt remote, as always ends with Failed to copy: upload response not found copy/sync/mount all the same.

Always the same files, while nothing special with those. Just few megabytes, the name have only ASCII chars, but even if i rename to totally random names like "fsdgdgsdgsdgsdghwgwe.mp3", or "2324.mp3" same happens.

I've tried uploading to 1fichier without crypt, it works. Mounted physical drive too with the crypt, and the "upload" there worked too, so only happens when i try to upload to 1fichier with crypt.

Edit: OMG changing ID3 metadata didnt solved it, but now after shortening the filename it's uploaded! BUT there are other files there with even longer filenames than the original

BUT if i upload the file with short name, and then rename to the original name in the mount,it works

By registering for an IDrive account you or the entity you represent ("you" and "your") agree to be bound by these Terms of Service (the "Terms"), which govern your access to and use of the IDrive Service (the "Service") offered by IDrive Inc. ("we", "us" or "our"). Some applications of the Service may implement open source code released under the GNU General Public License ("GPL"). Please carefully read the GPL as well as our Service Level Agreement and Privacy Policy, which are incorporated into these Terms.

If you are registering for the Service on behalf of an organization, you are agreeing to these Terms for that organization and promising that you have the authority to bind that organization to these Terms. In that case, "you" and "your" will refer to that organization.

It is important to note that the functionality of the Service is time-dependent and these Terms represent the functionality as of now. It is possible that earlier versions of the Service do not support all the functionalities as described below. Please reference the Windows Notes and Mac Notes for previous account versions.

You agree to provide us with accurate and complete information when you create an IDrive Account (your "Account"). In order to prevent unauthorized access to your Account, you agree to keep your password and other Account details confidential and not share them with anyone else.

You, as the Account holder, are solely responsible for access to, content in or sharing and use of your Account. We are not liable for any loss or damage arising from any access to, content in, or sharing and use of your Account. If you believe there has been unauthorized access to your Account, you must notify pri...@idrive.com immediately.

3a8082e126