On: Show HN: Obsidian Canvas – An infinite space for y...

[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 → s0ulphire]

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 → s0ulphire]

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 → jcul]

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.