[Bug]: Multikey Encryption Breaks When Upgrading from NC26 to NC27 about server

[AndyScherzinger]

Also Looping in @artonge

[derschiw]

Sorry for the late response.
Did you try it with an markdown / image file? We believe that some files are either in the cache or unencrypted thumbnails. But the timestamps in the key files and encrypted files differ. Also you will see that the download will fail.

However we just reproduced it with .mp4 and .pdf files locally in a fresh install. It breaks as expected.

Sorry we didn't realize that before... I updated the Steps to reproduce.

[kesselb]

fyi @AndyScherzinger @sorbaugh @come-nc

[kesselb]

I cannot tell if related but noticed that end_to_end_encryption is listed in app_install_overwrite.

E2E and SSE are not compatible and cannot be used at the same time afaik, because they both use the encrypted column in oc_filecache.

[derschiw]

@kesselb when starting the cloud we tried E2EE but then disabled the app (years ago) without having any problems so far. So i guess this is not related.

[artonge]

I failed to reproduce.
@derschiw I tried to move a file out of the shared folder, both from the emitter and the recipient.
When doing it from the recipient account, the fileKey is deleted, but the file can still be opened. Anything I am missing?

[m-vz]

I was just able to reproduce the error on a fresh instance with the updated steps @derschiw posted.

Moved all default files into a folder on NC26 and shared that. Upgrade to NC27. After moving the folder without editing the files, none of them can be opened anymore.

This seems like a serious problem to me...

[1H0]

I was also able to reproduce this issue with the steps provided by @derschiw.

I also moved all the preexisting files in a folder on NC26 and shared it with a user. I then upgraded to NC27 and added another user to that same folder, which then made files in it inacessible to all participants.

[derschiw]

Are there any news on that? Were you able to reproduce it? This bug still keeps breaking all files from our customers and we can't do something against it. So, help would be very much appreciated!

[artonge]

I was able to reproduce by adding a recipient after the update. @come-nc:

When adding a new recipient, we trigger

server/apps/encryption/lib/Crypto/Encryption.php

Lines 412 to 455 in 5bc8329

	public function update($path, $uid, array $accessList) {
	if (empty($accessList)) {
	if (isset(self::$rememberVersion[$path])) {
	$this->keyManager->setVersion($path, self::$rememberVersion[$path], new View());
	unset(self::$rememberVersion[$path]);
	}
	return false;
	}
	$fileKey = $this->keyManager->getFileKey($path, $uid, null);
	if (!empty($fileKey)) {
	$publicKeys = [];
	if ($this->useMasterPassword === true) {
	$publicKeys[$this->keyManager->getMasterKeyId()] = $this->keyManager->getPublicMasterKey();
	} else {
	foreach ($accessList['users'] as $user) {
	try {
	$publicKeys[$user] = $this->keyManager->getPublicKey($user);
	} catch (PublicKeyMissingException $e) {
	$this->logger->warning('Could not encrypt file for ' . $user . ': ' . $e->getMessage());
	}
	}
	}
	$publicKeys = $this->keyManager->addSystemKeys($accessList, $publicKeys, $this->getOwner($path));
	$shareKeys = $this->crypt->multiKeyEncrypt($fileKey, $publicKeys);
	$this->keyManager->deleteAllFileKeys($path);
	foreach ($shareKeys as $uid => $keyFile) {
	$this->keyManager->setShareKey($path, $uid, $keyFile);
	}
	} else {
	$this->logger->debug('no file key found, we assume that the file "{file}" is not encrypted',
	['file' => $path, 'app' => 'encryption']);
	return false;
	}
	return true;
	}

Which:

1. Generate $shareKeys for each recipient
2. deleteAllFileKeys, including fileKey
3. setShareKey for each recipient, but not fileKey

The issue is with n°2

server/lib/private/Encryption/Keys/Storage.php

Lines 187 to 191 in 5bc8329

	public function deleteAllFileKeys($path) {
	$keyDir = $this->getFileKeyDir('', $path);
	return !$this->view->file_exists($keyDir) || $this->view->deleteAll($keyDir);
	}

Which will remove the fileKey which is not added again by n°3.

Draft level solutions ideas:

1. Temporary save fileKey in update, and rewrite it after deleteAllFileKeys`.
2. Or update deleteAllFileKeys to not delete fileKey. But that would be unexpected and might lead to other issues.
3. Use detect if using legacy file key and use multiKeyEncryptLegacy instead of multiKeyEncrypt?
4. Or something else? What were we doing previously?

What do you think?

[come-nc]

I think it is on purpose that the fileKey is removed, because it should be embedded in the generated shareKeys once legacy encryption is not used anymore.
Maybe the problem here is that the useLegacyFileKey is not set to false in the header when this update happens?

I remember this was complicated because rewriting header means rewriting the file.