Interoperability Cryptomator <> cryptofs

[ylangisc]

Hi, I try to open a cryptomator generated vault with the cryptofs implementation. cryptofs seems to support version 4 only:

Tried to open vault of version 5, but can only handle version 4

Is there any reason for this limitation as the cryptofs impl seems to be quite new and I was excepting it to support the latest vault version?

Supplementary question: Not sure but I have the impression that there is a bunch of duplicate code between cryptomator and cryptofs. Are there any plans to use cryptofs as a base for cryptomator?

- Yves

[overheadhunter]

cryptofs seems to support version 4 only

That's a bug, not a feature ;-)

Supplementary question: Not sure but I have the impression that there is a bunch of duplicate code between cryptomator and cryptofs. Are there any plans to use cryptofs as a base for cryptomator?

That's the plan. CryptoFS will replace lots of modules in Cryptomator, once it is fully tested.

[ylangisc]

We evaluate Cryptomator as an encryption layer for Cyberduck. Currently most of the encryption logic is separated and is part of the CryptoFileSystem implementation. It's not related to any java.nio.file classes. That would give us the possibility to make a FileSystem implementation that is specific for remote files in Cyberduck. With the filesystem cascading we do not have to deal with any encryption logic. We would have to deal with domain objects mapping only.

Your plan to make use of CryptoFS in Cryptomator would mean a tight coupling between crypto logic and java.nio.file. The CryptoFileSystem implementation would be completely removed I guess. Do I understand your plans correctly? If yes, how would you implement a non-nio backing implementation such as a InMemoryCryptoFileSystem or a RemoteCryptoFileSystem for Cyberduck for example?

[overheadhunter]

Well java.nio.* just defines the interfaces, CryptoFS is one implementation, Win & POSIX filesystems bundled with the JVM are different ones and there is also an in-memory implementation. So basically we are about to switch just the interfaces (from our own to NIO) and are still loosely coupled. We even extracted basic cryptographic functions to CryptoLib.

how would you implement a non-nio backing implementation such as a InMemoryCryptoFileSystem

FileSystem inMemoryFs = Jimfs.newFileSystem(Configuration.unix());
CryptoFileSystemProperties cryptoFsProps = CryptoFileSystemProperties.cryptoFileSystemProperties().withPassphrase("correct horse battery staple").build();
FileSystem inMemCryptoFs = CryptoFileSystemProvider.newFileSystem(inMemoryFs.getPath("/pathInsideWrappedFileSystem/"), cryptoFsProps);

But I understand that implementing the full java.nio.* API is a huge task just for talking to remote servers. Are you planning to encrypt file contents independently or do you want Cyberduck to include the full package including key storage, path obfuscation, etc? I guess you already have your own "remote storage" interface in Cyberduck?

[overheadhunter]

Closing this issue, since the "vault version 4" bug has been fixed in e6a2644.