For what it's worth, I've started using Cryptomator to encrypt and decrypt my files on the client before sending them to a cloud storage provider. It isn't a replacement for oDrive, but:
- It's cross platform, so I can use it on my Windows, Mac, and Linux machines (yes, I use all three). (Mobile support is limited to a few select cloud storage providers.)
- It's open source.
- They've documented their security architecture so you know exactly how your data is encrypted, even if they hadn't provided the source code. (Are you taking notes, oDrive?)
The fact that oDrive is closed source and unwilling to reveal their encryption process is a security risk. They are asking their users to put full trust in in their software without providing enough reason for that trust.
I recently ran into a similar issue with a software called ThingWorx. They have an encryption API that claims to use a 224 bit key with AES-128 (which is impossible), and it turns out they were only using a key and IV with a strength of 49 and 53.5 bits, respectively.
Until oDrive releases their complete security architecture with steps to decrypt, or until they release their source code, do not trust their encryption. We have no way of knowing whether they have a backdoor to encrypt our data.
As @Tony stated, they've released some information in another forum post, but it is still partial and not enough to perform a full decryption.
Based on that post, I've begun work on a decryption function that can act as a springboard for writing a full decryption client. You can find it at https://github.com/jordanbtucker/odrive-decrypt.
All that being said, oDrive is probably using security best practices, and probably doesn't have a backdoor to our encrypted data, however, we can't be sure. oDrive's best move is to be open about their encryption process.