4 ms·

> end-to-end encrypted https://github.com/twinkle-labs/twinkle-notes/blob/45206f9d61899a934c65db85f49a705730046fad/site-lisp/lib/space-list.l#L53-L66 https://g

> end-to-end encrypted https://github.com/twinkle-labs/twinkle-notes/blob/45206f9d61899a934c65db85f49a705730046fad/site-lisp/lib/space-list.l#L53-L66 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-random-numbers-in-various-programming-languages#commonlisp-csprng https://paragonie.com/blog/2016/05/how-generate-secure-rando... Furthermore, not authenticating your ciphertext means padding oracle attacks can be launched against the app. https://robertheaton.com/2013/07/29/padding-oracle-attack/ https://robertheaton.com/2013/07/29/padding-oracle-attack/

kebman 7y ago
What do you think about NaCl for a project like this?
- CiPHPerCoder 7y ago
  Libsodium (a fork of NaCl) is preferable to NaCl. JS: https://www.npmjs.com/package/sodium-plus https://www.npmjs.com/package/sodium-plus (I wrote this one.) Lisp: https://github.com/orthecreedence/cl-sodium https://github.com/orthecreedence/cl-sodium Java (Android): https://github.com/terl/lazysodium-android https://github.com/terl/lazysodium-android Other bindings: https://libsodium.gitbook.io/doc/bindings_for_other_languages https://libsodium.gitbook.io/doc/bindings_for_other_language...
  - lawl 7y ago
    > 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 https://github.com/dchest/tweetnacl-js#audits
    - CiPHPerCoder 7y ago
      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.
jwtorres 7y ago
Can you cite some source for why the SHA256 of changing data isn't sufficiently random to be used as the IV?
- CiPHPerCoder 7y ago
  https://web.cs.ucdavis.edu/~rogaway/papers/sym-enc.pdf 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 force all possible inputs is definitely much lower than 2^128, therefore it weakens the IND security of the AES-CBC scheme. CBC security only provides indistinguishability. It isn't secure against adaptive chosen-ciphertext attacks.
  - jwtorres 7y ago
    >"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.
    - CiPHPerCoder 7y ago
      > 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.
twknotes 7y ago
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/8ad7d9d0b544f4027ec1c7fa16d4780ee7695a2f/site-lisp/lib/space-storage.l#L264 https://github.com/twinkle-labs/twinkle-notes/blob/8ad7d9d0b... > They must be unpredictable I am wondering if that is necessary, because the hacker can't perform those attacks without the user's actively using the app at the same time. From what I learned, the attacking process requires the presence of key somewhere. If the attacker can get on user's device while one is using it, then it's almost a hopeless situation. Please educate me if I am wrong.
- CiPHPerCoder 7y ago
  > > 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 (initialization vector). Since they have different security requirements, we refer to them differently. Unfortunately, some cryptography libraries just name the parameter IV.
  - metalliqaz 7y ago
    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.
    - CiPHPerCoder 7y ago
      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.
trulyrandom 7y ago
3. They should be authenticated. To OP, I would suggest using secretstream from libsodium, which abstracts all these problems away for you.
- CiPHPerCoder 7y ago
  > 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.
  - trulyrandom 7y ago
    Right, but I was specifically talking about authenticating the IV.

kebman 7y ago

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

CiPHPerCoder 7y ago
Libsodium (a fork of NaCl) is preferable to NaCl. JS: https://www.npmjs.com/package/sodium-plus https://www.npmjs.com/package/sodium-plus (I wrote this one.) Lisp: https://github.com/orthecreedence/cl-sodium https://github.com/orthecreedence/cl-sodium Java (Android): https://github.com/terl/lazysodium-android https://github.com/terl/lazysodium-android Other bindings: https://libsodium.gitbook.io/doc/bindings_for_other_languages https://libsodium.gitbook.io/doc/bindings_for_other_language...
- lawl 7y ago
  > 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 https://github.com/dchest/tweetnacl-js#audits
  - CiPHPerCoder 7y ago
    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.

jwtorres 7y ago

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

CiPHPerCoder 7y ago
https://web.cs.ucdavis.edu/~rogaway/papers/sym-enc.pdf 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 force all possible inputs is definitely much lower than 2^128, therefore it weakens the IND security of the AES-CBC scheme. CBC security only provides indistinguishability. It isn't secure against adaptive chosen-ciphertext attacks.
- jwtorres 7y ago
  >"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.
  - CiPHPerCoder 7y ago
    > 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.

twknotes 7y ago

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/8ad7d9d0b544f4027ec1c7fa16d4780ee7695a2f/site-lisp/lib/space-storage.l#L264 https://github.com/twinkle-labs/twinkle-notes/blob/8ad7d9d0b... > They must be unpredictable I am wondering if that is necessary, because the hacker can't perform those attacks without the user's actively using the app at the same time. From what I learned, the attacking process requires the presence of key somewhere. If the attacker can get on user's device while one is using it, then it's almost a hopeless situation. Please educate me if I am wrong.

CiPHPerCoder 7y ago
> > 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 (initialization vector). Since they have different security requirements, we refer to them differently. Unfortunately, some cryptography libraries just name the parameter IV.
- metalliqaz 7y ago
  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.
  - CiPHPerCoder 7y ago
    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.

trulyrandom 7y ago

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

CiPHPerCoder 7y ago
> 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.
- trulyrandom 7y ago
  Right, but I was specifically talking about authenticating the IV.