Decrypting Data without odrive?



Is it possible to decrypt the the files stored in the cloud without ODrive? For example, if I download an encrypted file to a computer without ODrive, can I decrypt it somehow? I tried decrypting the filename with a AES-256 Decryptor using my passphrase but it doesn’t work.

De/Encryption without odrive client
De/Encryption without odrive client
Odrive Agent/CLI Troubleshooting, Feedback, and Questions



Sounds good, but it can’t be done programmatically somehow? Isn’t it just using AES-256 encryption with a passphrase so any AES decryption program could decrypt it? This would be useful as open source tools that exist now for all platforms (Android, Windows, Mac, etc) could decrypt the files and file names.


@odrive3 Thankfully odrive uses a more robust encryption process than a simple passphrase. See the FAQs towards the bottom of this page.


With no external decryption methods available, I worry what could happen to my encrypted backups if odrive suddenly became unavailable. We need thorough documentation of the encryption. A robust standalone tool for that purpose would be even nicer. Glad the odrive team is looking into releasing one.


I’m glad you guys are working on a standalone client. But, being a curious developer myself, I decided I’d like to try writing my own little script for decryption based on your description here,, in the “What is the encryption process” section. That appeared to give basically all the detail necessary. However, a quick test reveals that something is missing. I encrypted a simple 893 byte text file and looked at the size difference between the encrypted file and the plain text file. They only have a 12 byte difference. If the stored file has the salt + IV + cipher text AND the plaintext had the SHA256 hash appended prior to encryption I would expect the file size to have grown by 96 bytes (32 bytes for each of the salt, hash, and IV) Since you’re using CBC mode I guess the last block would have to be padded, but that would only be 3 bytes meaning the final file should actually be 99 bytes larger.

Anyway, what I’m wondering is if you left anything out of that description. E.g., is the plaintext compressed first? Or the plaintext + hash compressed?

Anyway, I’ll play around with it more. Just curious though. Seems like a standalone app should be easy assuming it’s basically just what you’ve described. Unless you’ve got your block chunking in there too…though I believe you already had example scripts for decoding that available in the forums.

PS: The only reason I’m even interested in doing this beyond curiosity is because I’m trying to script moving a bunch of my files from non-encrypted storage to encrypted storage. But, your CLI based linux app doesn’t support encryption yet. :stuck_out_tongue:


I’m guessing the salts are stored with odrive so we can’t create an decryptor that actually works with our odrive files right? Even if the missing bytes were accounted for.


According to their description at least, the salt is stored with the file. The salt isn’t secret so there’s no need for them to store the salt separately. It’s purpose is just to prevent dictionary attacks on a poorly chosen password by having the key generated from your password and a random salt. Similar to what an IV does for very regular data. It’s common to store the IV with the cipher text. A salt would commonly be stored with a hashed password though that doesn’t apply in this case. But, you’d need it for decryption since it has to be combined with a given password to generate the actual encryption key.


Oh. One thing I totally didn’t think about. The filename looks like a long base64 encoded string. Decoded it’s 51 bytes and the original filename was only 20 characters long. That’s only 31 bytes extra though so that couldn’t be the salt or IV. Unless the decoder I’m using didn’t work properly. :stuck_out_tongue:


The encrypted file name is a url-safe base64 encoded string that consists of:
internal encryption version (1 byte)
salt (8 bytes)
iv (16 bytes)
ciphertext (AES-CBC encrypted (filename + 4 bytes + additional padding to get to a multiple of 16 bytes))


Perfect, I think that’s all I need. I forgot that AES block size is always 128 bit regardless of key size. Thanks. Assuming I get it working, I’ll post a script for anyone that’s interested.


I would recommend holding off, as there is actually a bit more needed to do this properly. I’ll see if there is something I can produce that at least provide a bare-bones implementation of decryption for Encryptor files.


Ok. I’m still playing around with it in my spare time anyway. Although not knowing the # of iterations for PBKDF2 might also be a problem. Also, not being as familiar with Python is a pain in the butt so I’ll switch to Java where I’m more comfortable with the crypto API. :stuck_out_tongue:


Any news on that topic? Such a tool would be interesting for me, too.


I’ve unfortunately not had time to look into it further myself. I was trying it in python, but have done very little python dev so was not real familiar with the encryption libraries and hadn’t had luck getting it to work. But, encryption libs are usually finicky on a given platform so I was planning on making a simple java app to do it instead since I’m very familiar with the crypto libs in java. I still plan on it…it’s just that whole time thing. :slight_smile:

Not sure if Tony has had a chance to look into it more.


Sorry guys. This is still on our to-do list…


Hey there,

Thanks for odrive, I do like it so far. In fact, I just got a premium account. But please make sure this gets added soon. This is something I would think should come with paying $$. Or I should say, if it isn’t added sooner than later I’ll have to reconsider the payment as above comments have remarked - in case anything does happen with odrive, I would be able to recover my own data. Via python/ruby/openssl/other stock command line tool/etc. This is pretty crucial for a encryption/decryption feature…



I would also like to give this a ‘up vote’. I think I will hold off paying for premium until such a time, as its a bit useless being able to encrypt your files when you cant decrypt them again (for example something unexpected happened).

Please let me know if any progress is made.



@Tony, has there been any update regarding the standalone client? Seems like it’s in pretty high demand.


This is planned, but still outstanding.

If the concern is that the odrive app will stop working and your files will somehow be stuck without a way to decrypt them, I can promise you that this will not happen. There will always be a working way to decrypt your files. Currently that is the odrive desktop app. We plan to add the standalone utility, Agent, mobile, and web to that, in the future.

De/Encryption without odrive client
De/Encryption without odrive client