Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Twinkle Notes: Cross-platform encrypted notes app

github.com

Post reply on HN
Print view View original

31–40 of 52 posts

Re: Twinkle Notes: Cross-platform encrypted notes app

#31

Post by trulyrandom »

CiPHPerCoder wrote: post #12

> end-to-end encrypted https://github.com/twinkle-labs/twinkle-notes/blob/45206f9d6... For AES in CBC mode, IVs have two requirements: 1. They must never repeat. 2. They must be unpredictable. Generating them from a SHA256 hash of some low-entropy data is not a good practice. https://paragonie.com/blog/2016/05/how-generate-secure-rando... Furthermore, not authenticating your ciphertext means padding oracle attacks ca…

3. They should be authenticated.

To OP, I would suggest using secretstream from libsodium, which abstracts all these problems away for you.

Re: Twinkle Notes: Cross-platform encrypted notes app

#32

Post by CiPHPerCoder »

trulyrandom wrote: post #31
CiPHPerCoder wrote: post #12

> end-to-end encrypted https://github.com/twinkle-labs/twinkle-notes/blob/45206f9d6... For AES in CBC mode, IVs have two requirements: 1. They must never repeat. 2. They must be unpredictable. Generating them from a SHA256 hash of some low-entropy data is not a good practice. https://paragonie.com/blog/2016/05/how-generate-secure-rando... Furthermore, not authenticating your ciphertext means padding oracle attacks ca…

3. They should be authenticated. To OP, I would suggest using secretstream from libsodium, which abstracts all these problems away for you.

> 3. They should be authenticated.

I covered that:

> Furthermore, not authenticating your ciphertext means padding oracle attacks can be launched against the app.

The list above was just the requirements for the initialization vector, not the list of problems with the code.

Re: Twinkle Notes: Cross-platform encrypted notes app

#33

Post by lawl »

CiPHPerCoder wrote: post #19
kebman wrote: post #17

Earlier quoted context omitted.

What do you think about NaCl for a project like this?

Libsodium (a fork of NaCl) is preferable to NaCl. JS: https://www.npmjs.com/package/sodium-plus (I wrote this one.) Lisp: https://github.com/orthecreedence/cl-sodium Java (Android): https://github.com/terl/lazysodium-android Other bindings: https://libsodium.gitbook.io/doc/bindings_for_other_language...

> Libsodium (a fork of NaCl) is preferable to NaCl.

Can you elaborate on this? Quickly looking over your libsodium based sodium-plus it doesn't seem like it has been audited. (I know libsodium itself had an audit)

Where as for example tweetnacl-js [0] has been audited.

That's not meant to take a dump on your project, but I just don't understand why it is better, or preferable.

[0]: https://github.com/dchest/tweetnacl-js#audits

Re: Twinkle Notes: Cross-platform encrypted notes app

#34

Post by twknotes »

leppr wrote: post #7

Just wanted to say I love this business model of providing a free open source app, with convenient secure syncing being the paid option. The trade-offs for a user who's committed to not paying for the premium features are mainly about convenience and security (having to maintain a fork, and missing out on automatic security updates), which ressembles those they would have to make by pirating a closed-source app. Righ…

We are definitely using AGPL because, for the paranoid, they should be able to build their own binaries and distribute to their friends.

Re: Twinkle Notes: Cross-platform encrypted notes app

#36

Post by jwtorres »

CiPHPerCoder wrote: post #29
jwtorres wrote: post #23

Earlier quoted context omitted.

Can you cite some source for why the SHA256 of changing data isn't sufficiently random to be used as the IV?

https://web.cs.ucdavis.edu/~rogaway/papers/sym-enc.pdf See the section about "CBC with Counters". The consequence of the security proof by Rogaway, et al. for CBC mode is that IVs must be unique AND unpredictable for CBC mode to be secure*. SHA256 is a deterministic pseudorandom function if you know all of the inputs. By studying the source code, we can see what gets fed into the SHA256 inputs. The cost to brute forc…

>"See the section about "CBC with Counters"."

That section is talking about using an incrementing counter as the IV--it doesn't say anything about a PRNG being a bad choice (in this case, the PRNG being a SHA256).

>"By studying the source code, we can see what gets fed into the SHA256 inputs. The cost to brute force all possible inputs is definitely much lower than 2^128, therefore it weakens the IND security of the AES-CBC scheme."

Are you talking about brute forcing the IV? The IV is not a secret to anyone--it's usually appended to the cipher text.

Re: Twinkle Notes: Cross-platform encrypted notes app

#37

Post by CiPHPerCoder »

jwtorres wrote: post #36
CiPHPerCoder wrote: post #29

Earlier quoted context omitted.

https://web.cs.ucdavis.edu/~rogaway/papers/sym-enc.pdf See the section about "CBC with Counters". The consequence of the security proof by Rogaway, et al. for CBC mode is that IVs must be unique AND unpredictable for CBC mode to be secure*. SHA256 is a deterministic pseudorandom function if you know all of the inputs. By studying the source code, we can see what gets fed into the SHA256 inputs. The cost to brute forc…

>"See the section about "CBC with Counters"." That section is talking about using an incrementing counter as the IV--it doesn't say anything about a PRNG being a bad choice (in this case, the PRNG being a SHA256). >"By studying the source code, we can see what gets fed into the SHA256 inputs. The cost to brute force all possible inputs is definitely much lower than 2^128, therefore it weakens the IND security of the…

> That section is talking about using an incrementing counter as the IV--it doesn't say anything about a PRNG being a bad choice (in this case, the PRNG being a SHA256).

Let's try this again.

You have two types of inputs that APIs refer to as "IVs".

Nonces: Must never repeat.

Initialization vectors: Must never repeat AND must be unpredictable.

Counters are acceptable for nonces. When an academic cryptographer says in a security proof that a counter doesn't suffice for the security of a scheme, what they're really saying is that you're in the latter category (must be unpredictable too) rather than the former (where predictable is okay as long as it never repeats).

If it can be predictable, it can be a counter. If it can't be a counter, it must be unpredictable.

The correct way to get an unpredictable IV is to use a CSPRNG.

SHA256(some predictable low-entropy inputs) fails to meet the bar for unpredictability.

> Are you talking about brute forcing the IV? The IV is not a secret to anyone--it's usually appended to the cipher text.

IVs aren't secret, but given the security proof I linked, IVs cannot be predictable. They must be unpredictable.

Re: Twinkle Notes: Cross-platform encrypted notes app

#38

Post by c0ffe »

vzaliva wrote: post #16

I was in search of a good cross-platform notes app. Like Evernote, but preferably free with the open data format. I concluded that for me, personally, emacs org-mode with notes files stored in the Dropbox folder turns out to be an optimal solution. YMMV.

I agree: plain text is after all, easier to manage.

Personally, I've used Joplin [0] some months ago, and Im using QOwnNotes [1] now. Both are open source, cross platform, and can synchronize with Nextcloud. QOwnNotes may feel a bit faster since its written in Qt/C++ (Joplin is an Electron app).

However, I still find hard to write tables in Markdown manually.

[0]: https://joplinapp.org

[1]: https://www.qownnotes.org

Re: Twinkle Notes: Cross-platform encrypted notes app

#39

Post by kixiQu »

vzaliva wrote: post #16

I was in search of a good cross-platform notes app. Like Evernote, but preferably free with the open data format. I concluded that for me, personally, emacs org-mode with notes files stored in the Dropbox folder turns out to be an optimal solution. YMMV.

Joplin's (https://joplinapp.org/) whole shtick is basically being "open source evernote" in case anyone's wondering (can import from them and all).

Personally I'm having a good time with Tiddlywiki with a markdown plugin and nice context-of-backlinks setup (inspired by roamresearch.com )

Re: Twinkle Notes: Cross-platform encrypted notes app

#40

Post by CiPHPerCoder »

lawl wrote: post #33
CiPHPerCoder wrote: post #19

Earlier quoted context omitted.

Libsodium (a fork of NaCl) is preferable to NaCl. JS: https://www.npmjs.com/package/sodium-plus (I wrote this one.) Lisp: https://github.com/orthecreedence/cl-sodium Java (Android): https://github.com/terl/lazysodium-android Other bindings: https://libsodium.gitbook.io/doc/bindings_for_other_language...

> Libsodium (a fork of NaCl) is preferable to NaCl. Can you elaborate on this? Quickly looking over your libsodium based sodium-plus it doesn't seem like it has been audited. (I know libsodium itself had an audit) Where as for example tweetnacl-js [0] has been audited. That's not meant to take a dump on your project, but I just don't understand why it is better, or preferable. [0]: https://github.com/dchest/tweetnacl…

NaCl is djb abandonware. Libsodium is actively maintained.

Libsodium offers Argon2 password hashing and key stretching, XChaCha20-Poly1305 AEAD constructions, BLAKE2b generic hashing, SipHash-2-4 for collision-resistant hash tables, etc.

Most people who say "use NaCl" really mean "use NaCl/libsodium".

Regarding my project: sodium-plus will wrap sodium-native (a thin Node wrapper to libsodium proper, which has been audited) if it is installed. To date, libsodium.js has not. Therefore, if you care about public code audits, you can use audited libsodium with sodium-plus just by installing sodium-native alongside it.

Post reply on HN