2
$\begingroup$

Obsidian.md claims

End-to-end encryption means that the data is encrypted from the moment it leaves your device, and can only be decrypted using your encryption key once it's back on one of your devices.

We can't read your data. Neither can any potential eavesdroppers, such as your internet service provider.

In the rare case of a complete server breach, your data remains encrypted—no one can decrypt your files without knowing your password.

However as per their blog article, symmetric encryption AES-256-GCM is used, with a key hash derived from the user's password / salt using scrypt, and two recent alternative server implementations [4] [5] show that the derived key hash is transmitted to the Obsidian's servers by the app during vault creation (among a few other calls), and stored in their database.

So if a symmetric encryption algorithm is used, and both the end-user user and Obsidian's server know the symmetric key, how come they wouldn't be able to decrypt the data?

Improve this question
$\endgroup$
2
  • $\begingroup$ The question really is about what the Obsidian client-side and server-side code is doing, which from the functional description could allow the server to decrypt, or not (eg. for the later: it could be that from the user password it is derived a scrypt hash divided into an encryption key for AES-256-GCM, and a pseudo-password then handled by the server as a standard password would be, for access control purposes). I'm not sure it's best asked here. security-SE? reverseengineering-SE? $\endgroup$
    – fgrieu ♦
    Commented Sep 3, 2023 at 16:19
  • $\begingroup$ I'd imagine the derived key being sent to the server is to access what they call a "vault", and /not/ the key which was used to encrypt the file content, cf. it being in vicinity of code concerned with handling vaults in both your linked implementations. These 'vaults' are likely just some form of organizational structure (e.g. shared directories) within which end-to-end encrypted files are stored. $\endgroup$
    – Morrolan
    Commented Sep 4, 2023 at 9:19

2 Answers 2

Reset to default
1
$\begingroup$

The source code to which the question links is in this repository. The README says:

Reverse engineered obsidian sync server (NOT OFFICIAL).

This repository is quite active, and the developers have been engaging with questions from people fairly consistently.

Therefore, as @fgrieu said, the best course of action is to just ask the developers directly about this. That is: can they confirm that this an accurate implementation of the functionality they learned from reverse-engineering? Did they implement a feature to help with key recovery in case the local machine is lost?

We can only speculate here as to why their implementation is as it is, asking them directly is probably the best course of action besides performing an independent reverse engineering of Obsidian sync.

Improve this answer
$\endgroup$
1
$\begingroup$

Nice question! Firstly, answering it directly: So if a symmetric encryption algorithm is used, and both the end-user user and Obsidian's server know the symmetric key, how come they wouldn't be able to decrypt the data?

Yes, then server-side can decrypt the data.

But variable $\texttt{keyhash}$ (from files vault.py and vault.go) is the SHA-256 hash of the output from the scrypt PBKDF. So, I think that in general - it is working as it should, because server got access not to the secret key used in symmetric encryption, but to the SHA-256 of that secret key.

The source code clarifying it, is placed here: scrypt.go. There are two functions: $\texttt{getKey}$ and $\texttt{MakeKeyHash}$. The first one calculates scrypt output from the password and salt, and the second one calculates SHA-256 hash of the first one. The same case is with the server-side function $\texttt{get_keyhash}$ form file utils.py.

If they ever uses password on the server side (here) it's out of scope, because it's the so-called by them managed encryption: Obsidian Help - Security and privacy.

As it comes to the security analysis of the Obsidian E2EE Sync, your question has raised an important issue - because in my opinion vendors should always publish as much as they can of the technical description of the forms in which secret/private keys are stored or transported. Hence, Obsidian should clearly point out in their documentation, that they are storing (only) SHA-256 hash of the secret derived from user's password (because that is probably what they do, as the repository with reversed sync service suggests).

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.