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

41–50 of 52 posts

Re: Twinkle Notes: Cross-platform encrypted notes app

#41

Post by metalliqaz »

CiPHPerCoder wrote: post #28
twknotes wrote: post #24

Earlier quoted context omitted.

Thank you for digging into the code. This is why we are going open source. The encryption you are referring to is for encrypting a list of keys for your local notes storage, which is not exactly part of the end-to-end encrypted syncing. Since you have got this far, could you please have a look at: https://github.com/twinkle-labs/twinkle-notes/blob/8ad7d9d0b... > They must be unpredictable I am wondering if that is ne…

> > They must be unpredictable > I am wondering if that is necessary, Yes, it is necessary. The IND security of Cipher Block Chaining (CBC) depends entirely on the IV being from a cryptographically secure random generator. CBC mode requires unique and random IVs. CTR mode requires unique IVs (but can be predictable). That's why we call the CTR input a nonce (number to be used once) and the CBC input an IV (initializa…

Is that distinction between nonce and IV held everywhere in the crypto community? For example, rfc8439 which defines the ChaCha-Poly AEAD does not require an unpredictable input nonce, and indeed calls it a "nonce", but many of the common implementations I've seen use "initialization vector" instead.

Re: Twinkle Notes: Cross-platform encrypted notes app

#42

Post by CiPHPerCoder »

metalliqaz wrote: post #41
CiPHPerCoder wrote: post #28

Earlier quoted context omitted.

> > They must be unpredictable > I am wondering if that is necessary, Yes, it is necessary. The IND security of Cipher Block Chaining (CBC) depends entirely on the IV being from a cryptographically secure random generator. CBC mode requires unique and random IVs. CTR mode requires unique IVs (but can be predictable). That's why we call the CTR input a nonce (number to be used once) and the CBC input an IV (initializa…

Is that distinction between nonce and IV held everywhere in the crypto community? For example, rfc8439 which defines the ChaCha-Poly AEAD does not require an unpredictable input nonce, and indeed calls it a "nonce", but many of the common implementations I've seen use "initialization vector" instead.

Loosely. The majority have given up on the public understanding of nuances and just phone it in with "just don't write crypto".

Because AES-CTR and ChaCha both refer to it as a nonce, and CBC calls it an initialization vector, the IV/nonce distinction does matter. But if you misuse the terms folks will know what you meant to say. Just don't mix it up when it comes time to implement.

Re: Twinkle Notes: Cross-platform encrypted notes app

#43

Post by urlwolf »

c-smile wrote: post #22
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 think that my Sciter.Notes ( https://notes.sciter.com ) will qualify that. Notes are stored in local db yet notebooks in the db can be mapped on file folders (e.g. folder on DropBox containing html files - each note is a single HTML file). The note db file can be protected/encrypted by OS means. Windows/Mac/Linux.

Agreed. Sciter notes is a gem. It's fantastically fast. C-smile, congrats on writing this masterpiece. I wish you best of luck. If you found a biz model to support it and add features, it'd be great. So much low hunging fruit in a world of electron apps and a crowd (HN) that mostly hates them.

Re: Twinkle Notes: Cross-platform encrypted notes app

#44

Post by urlwolf »

Tried it on mint (LTS). uname -a (base) Linux q 5.3.0-28-generic #30~18.04.1-Ubuntu SMP Fri Jan 17 06:14:09 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

I get: /opt/app.twinkle.notes/twinkle (base) dist:/opt/app.twinkle.notes var:/home/q/.config/twinkle dist=/opt/app.twinkle.notes var=/home/q/.config/twinkle * Twinkle Lisp 2020 *

DevTools listening on ws://127.0.0.1:16780/devtools/browser/6d2dd982-a67d-4915-8517-83d4394054a3 error: file '/opt/app.twinkle.notes/lisp/lib/sqlite3.l': position 13622: line 386: invalid number #1: /opt/app.twinkle.notes/lisp/init.l:42: (load "lib/sqlite3.l") [2020-02-05 23:23:09,394950 init#0] finished due to run time error

This is the deb file on your website.

Re: Twinkle Notes: Cross-platform encrypted notes app

#46

Post by LookOutItsABot »

CiPHPerCoder wrote: post #42
metalliqaz wrote: post #41

Earlier quoted context omitted.

Is that distinction between nonce and IV held everywhere in the crypto community? For example, rfc8439 which defines the ChaCha-Poly AEAD does not require an unpredictable input nonce, and indeed calls it a "nonce", but many of the common implementations I've seen use "initialization vector" instead.

Loosely. The majority have given up on the public understanding of nuances and just phone it in with "just don't write crypto". Because AES-CTR and ChaCha both refer to it as a nonce, and CBC calls it an initialization vector, the IV/nonce distinction does matter. But if you misuse the terms folks will know what you meant to say. Just don't mix it up when it comes time to implement.

Please don't ever stop this behavior. I'm just learning much of this in an applicable way and people like you make this not just easier but possible for those of us learning with little outside help.

The father I go down this rabbit hole the more I learn security should be like a religion of security (only one without dogma).

Thanks.

Re: Twinkle Notes: Cross-platform encrypted notes app

#47

Post by twknotes »

urlwolf wrote: post #44

Tried it on mint (LTS). uname -a (base) Linux q 5.3.0-28-generic #30~18.04.1-Ubuntu SMP Fri Jan 17 06:14:09 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux I get: /opt/app.twinkle.notes/twinkle (base) dist:/opt/app.twinkle.notes var:/home/q/.config/twinkle dist=/opt/app.twinkle.notes var=/home/q/.config/twinkle * Twinkle Lisp 2020 * DevTools listening on ws://127.0.0.1:16780/devtools/browser/6d2dd982-a67d-4915-8517-83d439405…

This seems strange. Can't reproduce the problem here. Can you please help to check what's on line 386?

Re: Twinkle Notes: Cross-platform encrypted notes app

#49

Post by trulyrandom »

CiPHPerCoder wrote: post #32
trulyrandom wrote: post #31

Earlier quoted context omitted.

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.

Right, but I was specifically talking about authenticating the IV.

Re: Twinkle Notes: Cross-platform encrypted notes app

#50

Post by wtmt »

twknotes wrote: post #25
wtmt wrote: post #15

A few questions and observations: * If I choose to use this notes app on multiple devices, and am careful enough to be the only person using it and complete any note taking on one device at a time (closing the app properly), I should be able to store and sync the sqlite database on any cloud storage service and wouldn't need the paid sync option, correct? In other words, the sync option makes multiple clients opening…

> store and sync the sqlite database on any cloud storage service It would be quite slow. > a minimum of 1GBm Our servers are quite dumb that if you are hosting your space with us, we need to reserve some storage space for you. That's a fixed cost for us even if you are not effectively using that storage.

Why would a notes database, that’s mostly (or all text) even take up a lot of space and make syncing the entire database slow? If someone is using just a few MBs of data, the speed of syncing that is immaterial.

Your servers not being able to account for smaller storage sizes is a technical limitation that you have built. You can take a look at tarsnap for inspiration on how to account for very small amounts of data. I’m not saying you should account for bytes, but even taking it at a fraction of what you’re currently doing would be better and fairer to paying customers. You would also discourage hoarders who thrive on utilizing a lot more and get subsidized by those who barely store much.

Post reply on HN