Add implementation of unified vault format (UVF).#16623
Add implementation of unified vault format (UVF).#16623
Conversation
4730d93 to
13bfc8d
Compare
…dency to cryptofs (incompatible with cryptolib uvfdraft).
029b2e5 to
ac3512d
Compare
cryptomator/src/main/java/ch/cyberduck/core/cryptomator/AbstractVault.java
Outdated
Show resolved
Hide resolved
| if(new SimplePathPredicate(home).test(directory)) { | ||
| // TODO hard-coded to initial seed in UVFVault | ||
| directoryIdHash = filenameCryptor.hashDirectoryId(id); | ||
| } | ||
| else { | ||
| directoryIdHash = vault.getCryptor().fileNameCryptor(loadRevision(session, directory)).hashDirectoryId(id); | ||
| } |
There was a problem hiding this comment.
@ylangisc what's the best approach - should we cache the revisions per directory along with its ID?
| // TODO still fails as test data from org.cryptomator.cryptolib.v3.UVFIntegrationTest uses latestSeed when creating dir.uvf, hard-coded in current implementation for subdir in DirectoryMetadata subDirMetadata = dirContentCryptor.newDirectoryMetadata();) | ||
| final AttributedList<Path> list = storage.getFeature(ListService.class).list(new Path("/cyberduckbucket/subdir", EnumSet.of(AbstractPath.Type.directory, AbstractPath.Type.placeholder, AbstractPath.Type.decrypted)).withAttributes(subdir), new DisabledListProgressListener()); | ||
| assertEquals(1, list.size()); |
There was a problem hiding this comment.
@ylangisc with the loadRevision workaround, the encryption part of the subdir works and the raw folder is listed remotely, but then fails in AbstractVault.decrypt when attemptyting to decrypt the file name, probably due to the file name decryptor statically linked to the initial revision. Need to continue there.
| final Path metadataFile = new Path(metadataParent, vault.getDirectoryMetadataFilename(), EnumSet.of(Path.Type.file, Path.Type.encrypted)); | ||
| final byte[] ciphertext = new ContentReader(session).readBytes(metadataFile); | ||
| // https://github.com/encryption-alliance/unified-vault-format/blob/develop/file%20name%20encryption/AES-SIV-512-B64URL.md#format-of-diruvf-and-symlinkuvf | ||
| // TODO can we not use org.cryptomator.cryptolib.v3.DirectoryContentCryptorImpl.decryptDirectoryMetadata()? DirectoryMetadataImpl is not visible and DirectoryMetadata is empty interface, so we cannot access dirId attribute. |
There was a problem hiding this comment.
@overheadhunter how can we use cryptolib API to read UVf metadata file?
There was a problem hiding this comment.
Use DirectoryMetadataImpl#cast.
There was a problem hiding this comment.
You mean the dir.uvf file? I considered it an implementation detail that should not be public.
|
|
||
| @Override | ||
| public Path create(final Session<?> session, final String region, final VaultCredentials credentials) throws BackgroundException { | ||
| throw new UnsupportedOperationException(); |
|
Superseded by #17173 |
Resolves #16642.
Depends on 1.
Footnotes
https://github.com/iterate-ch/cryptolib/pull/10 ↩