# 202203270003 Licat on Obsidian Sync Security ## Description [Chat](https://discord.com/channels/686053708261228577/900870622631063552/957458208639844403) between `Licat` and `symbolic` (Obsidian Member's Group Discord) on Obsidian Sync's cryptography protocols, [[2022-03-26]]. ## Notes - [Obsidian Help on Sync Encryption](https://help.obsidian.md/Obsidian+Sync/Security+and+privacy#What+encryption+do+you+use) - IVs are always generated fresh from a cryptographic source and included start of data block. - [[Obsidian]] sync uses [SubtleCrypto Web API](https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto) for E2EE. - File size is potentially leaky - [EteSync/Etebase](https://github.com/etesync) consulted on sync design ## Conversation 2022-03-26 9:38 PM symb0lic: Is there any documentation on the cryptography design and implementation for Sync? This is something I've seen others ask about on the forums and I haven't been able to find more info anywhere. It would be very reassuring to know what is encrypted and what isn't. For example, taking a peak at the Network tab in Developer Tools, I see there's some potential leakage of information regarding file size (it is transmitted plaintext) and uniqueness of content and path (they always end up with the same hash). It would make me sleep better at night to have a better idea of what data is and isn't recoverable, and how AES-GCM is used for better assurance that key-IV-plaintext triples aren't ever repeated (which would be a major failure condition under AES-GCM). 9:44 PM Licat: [There's a help page for this](https://help.obsidian.md/Obsidian+Sync/Security+and+privacy#What+encryption+do+you+use). ==IVs are always freshly generated from a cryptographic source and they are included in the data block at the beginning==. ==We use the SubtleCrypto web API implementation for the E2EE==. ==File size is potentially leaky But there isn't much we can do there unless we always add random padding== 9:57 PM symb0lic: Ah I had missed this, thanks @Licat! Appreciate the extra info as well. If you can, could you also please elaborate on what exactly is hashed when note content is updated or created? If I create file A with the content "test", I see the message sent for file creation with a hash and then a binary message sent with the encrypted data block after. If I create file B with the same content, "test", I don't see a new data block being sent and only a message for file creation with the same hash. My only remaining concern here is if that hash could be leaky as well -- like if it is just hashing file contents? Are these hashes at least unique to the keyHash or a salt of some kind? Concern would be plaintext recovery via a table of known hash values (e.g., encrypt "test" in another vault, data gets compromised, and I see the two hashes match) 9:58 PM Licat: ==The hash is key'd by the key itself (not the passcode) to make them cross-request stable, that is correct== 9:59 PM symb0lic: Ah fantastic, so ==H(key||contents)==? 9:59 PM Licat: IIRC yes It's been over a year since I touched the sync algo 😅 10:00 PM symb0lic: No worries! I'm not trying to grill you or anything haha, just asking because I work with crypto, I know it's really hard, and I'm always just sliiightly paranoid. So it really would only leak uniqueness of note contents under the same key. Okay. I could live with that 🙂 10:01 PM Licat: I don't work with crypto normally but it's definitely hard to get right. I've received a lot of help from an expert when the E2EE implementation was made though, let me find the credentials Do you know ==EteSync/EteBase==? 10:02 PM symb0lic: I do! 10:02 PM Licat: ==I had gotten most of my help from Tom/Tasn from EteSync like over a year ago== ^b5e6cb 10:02 PM symb0lic: Oh that's reassuring to hear! I've never worked with them, but they seem like a sharp team 10:03 PM Licat: He pointed out a lot of problems with my early implementation before Sync was even shipped to users 10:03 PM symb0lic: Major kudos for getting professional guidance. Most companies I work with professionally don't, and end up screwing up their crypto implementations. Sometimes catastrophically 10:03 PM Licat: Thank you! 10:04 PM symb0lic: No problem, and thank you for answering my questions! Really helps me feel more confident that my data is safe 10:04 PM Licat: Glad it helps ❤️