[sasas]

From the link:

> AES-256 is a military-grade encryption specification that's widely used in for example online banking.

The term “military grade” is meaningless and if anything raises a red flag (at least to me). What would be more useful is a detailed spec on the implementation.

Are the crypto routines implemented in house or has a well tested library been used? If in house, had there been an external code audit done? What were the results ?

[s0ulphire]

The data is successfully encrypted before it's sent (which you can verify with wireshark). What exactly are your concerns, given that the data isn't encrypted locally in the first place? And seriously with the question...what do you think is more likely, that the tiny team of 6 invested a ton of time reinventing the wheel with a custom in-house AES implementation, OR that they used any of the readily available and extremely well tested libraries? SMH

[sasas]

Your response indicates you may have limited knowledge on the topic.

> what do you think is more likely, that the tiny team of 6 invested a ton of time reinventing the wheel with a custom in-house AES implementation

AES is a cryptographic primitive. No one ever implements their own. What developers implement is the cryptographic system - the block cipher mode, initialisation vectors, rounds, salting etc. It all very easy to get this wrong. Their site does state they use GCM cipher mode which is the right choice (say over ECB, CBC…)

> which you can verify with wireshark

Viewing encrypted material in a packet capture is meaningless and provides zero assurances

> What exactly are your concerns, given that the data isn't encrypted locally in the first place?

The encrypted data in their cloud solution is adequately protected.

Companies that take end to end encryption seriously will generally provide details on how they went about their cryptographic system.

For example, is the encryption key derived from the password? If so what is the key derivation function? How many rounds didn’t get select? These are generally the responsibility of the developer to responsibly choose.

[jcul]

Small nit: I'd guess it is not that easy to verify this in wireshark.

I'm not an obsidian user or familiar with the code base, so could be wrong here.

The data is probably encrypted with AES before being sent (the E2E bit), though probably there is some metadata unencrypted.

When the data is actually sent, the entire thing would likely be encrypted again with TLS while it is in transit. This means, for example, your ISP cannot see the unencrypted metadata or the encrypted data.

So if you open a capture in wireshark then you would likely see this. Of course it is possible to decrypt the TLS to check the underlying data is encrypted, but it is not trivial for most people.

An easier way to see what it is doing may be to run ltrace on it and check what it is writing to the sockets. Or gdb, break on the SSL write function and inspect the registers to see what is being written.

e.g. gdb --args wget "https://www.google.com"

    b SSL_write
    r
    x/s $rsi

    > "GET / HTTP/1.1\r\nHost: www.google.com\r\nUser-Agent: Wget/1.21.3\r\nAccept: */*\r\nAccept-Encoding: identity\r\nConnection: Keep-Alive\r\n\r\n"

Though it would just tell you if the data looks encrypted, not much else.

For example they could use a super secure key, or the "1234" for everyone, just looking at the data probably wouldn't tell you this.

[s0ulphire]

Sorry that's my bad, I meant *Fiddler not wireshark. Fiddler makes it a piece of cake to decrypt the extra tls, leaving you with just the encrypted data you were sending.

[joethei]

We did not implement the crypto part ourselves. We use the SuptleCrypto Web API implementation and a library called scrypt (this one: https://github.com/ricmoo/scrypt-js).

We also had someone from the EteSync/EteBase project take a look at the code before Obsidian Sync was released.

[sasas]

Thanks for taking the time to respond. As SuptleCrypto's states themselves:

> Warning: This API provides a number of low-level cryptographic primitives. It's very easy to misuse them, and the pitfalls involved can be very subtle. Even assuming you use the basic cryptographic functions correctly, secure key management and overall security system design are extremely hard to get right, and are generally the domain of specialist security experts.

Errors in security system design and implementation can make the security of the system completely ineffective.

Given the potential volume of people's personal data that might be stored, this is certainly an area you would want to get right.