Enable AES-256 Encryption for TW

Developers
1

I would suggest that while discussion about security takes place, we also update the defaults for the encryption librarycused by tw to use 256 bit aes ccm.

and, if we really wanted to go a step further, I believe there is a javascript version of argon2 that could also be embedded into TW to allow for secure passwords.

It was something ai was curious about for a while, in regards to creating a TW password manager of sorts, similar to how KeePass generates an encrypted file.

Justcmy first thoughts on the subject ^^

addendum, if you want a secure method of syoring multiple TW you could also use veracrypt, however this isn’t someyhing I would expect kost users to need to use.

also, when using encrypt individual tiddlers, you can treat both the password and the title as passwords to the text.
because both are required to decrypt the document, it allows you to have a two factor password structure.

New Privacy and Security Documentation
2

See: Set AES strength to 256 bit by pmario · Pull Request #8249 · TiddlyWiki/TiddlyWiki5 · GitHub

2 Likes
3

ah, I knew I remembered discussing that!

though I am curious as to why its still a pull request and wasnt implemented in a new tw version. was there an issue with updating it? (I do not use github for very much, so please forgive me if I’m missing a step :sweat_smile:)

I read through the thread and it appears that github issue #6330 is not delaying it, as it uas been closed.

4

If I am understanding @pmario correctly, #6330 introduced a new error concerning importing encrypted wikis.

5

I think there is a misunderstanding what multi-factor authorization means. At the moment there are 4 different factors, which are commonly used.

  1. Knowledge – Something we need to know – eg: password
  2. Possession – Something we need to have – eg: authenticator key created by an app or usb-dongle
  3. Inherent – Something which is unique to a person – eg: fingerprint
  4. Location – We have to prove our location – eg: hard wired connection with laptop

If we need to know (1) the password and we need to know (1) the title. – It is only 1 factor. Like adding the password+title into a longer PW.

This long PW will be very tricky to be remembered. Since TW has no “recovery” option (which would need a server). So if the PW is lost – The data is lost.

IMO a 2-factor auth for a single file wiki will be tricky, without new code.

6

Oh, when I was talking about two factor password structure, I wasn’t referring to mutli-factor authentication. I meant it in the sense that you have two parts to make up for the password to unlock your tiddler. like a chest with two locks on it.

I suppose I should have used different wording instead of using ‘factor’ in it :sweat_smile:

As far as implementing 2FA into TiddlyWiki… I’m not sure I see a practical need for it that wouldn’t be too cumbersome to setup. At least not for a plain SPA version. Maybe it could be done using node.js, but I’m not familiar enough with the node version to comment on that.

7

We are way OT now. I’ll move the AES 256 posts into a new thread, so New Privacy and Security Documentation can stay on topic.

8

The problem is a bit tricky and it has been quite some time since I did the tests.

So I did test again in more detail

First things first

Every encrypted TW version can be decrypted. So opening an encrypted file should not be a problem.

Issue with importing an encrypted file wiki

There has been a change in v5.2.0, that broke “import” decryption in v5.2.0 and v5.2.1. So TW v5.2.0 and v5.2.1 are a bit bugged.

The problem was fixed in v5.2.2

There are 2 questions we have to answer for the status quo AES128

  1. Can newer TW versions import encrypted wikis created with old eg: v5.1.0? (backwards compatibility)
  2. Can “old” wikis import encrypted wikis created with TW v5.3.5? (forward compatibility)

Add 1) I did test import to latest version first. As can be seen by the test, there are exactly 3 issues with backwards compatibility, where is “broken”.

Encrypted with: v5.1.0  import to v5.3.5 -> works
Encrypted with: v5.1.23 import to v5.3.5 -> works
Encrypted with: v5.2.0  import to v5.3.5 -> works
Encrypted with: v5.2.1  import to v5.3.5 -> works
Encrypted with: v5.2.2  import to v5.3.5 -> works

Encrypted with: v5.1.0  import to v5.3.0 -> works
Encrypted with: v5.1.23 import to v5.3.0 -> works
Encrypted with: v5.2.0  import to v5.3.0 -> works
Encrypted with: v5.2.1  import to v5.3.0 -> works
Encrypted with: v5.2.2  import to v5.3.0 -> works

Encrypted with: v5.1.0  import to v5.2.0 -> works
Encrypted with: v5.1.23 import to v5.2.0 -> works
Encrypted with: v5.2.0  import to v5.2.0 -> **broken**

Encrypted with: v5.1.0   import to v5.2.1 -> works
Encrypted with: v5.1.23  import to v5.2.1 -> works
Encrypted with: v5.2.0   import to v5.2.1 -> **broken**
Encrypted with: v5.2.1   import to v5.2.1 -> **broken**

Encrypted with: v5.1.0  import to v5.2.2 -> works
Encrypted with: v5.1.23 import to v5.2.2 -> works
Encrypted with: v5.2.0  import to v5.2.2 -> works
Encrypted with: v5.2.1  import to v5.2.2 -> works
Encrypted with: v5.2.2  import to v5.2.2 -> works

Add 2) As seen by the following tests there is limited forward compatibility.

Files encrypted with:

  • v5.3.x can be imported down to v5.2.2
  • v5.2.x can be imported down to v5.2.2
  • v5.1.x can be imported down to v5.1.1
Encrypted with: v5.3.5  import to v5.2.2 -> works

Encrypted with: v5.3.5  import to v5.2.1 -> **incompatible**
Encrypted with: v5.3.5  import to v5.2.0 -> **incompatible**
Encrypted with: v5.3.5  import to v5.1.23 -> **incompatible**

Encrypted with: v5.2.0  import to v5.1.23 -> **incompatible**

Encrypted with: v5.1.23  import to v5.1.1 -> works
Encrypted with: v5.1.23  import to v5.1.0 -> **no feedback - does not work ??**

That’s the status quo with AES128 encryption.

Tests for AES256 will follow in a new post.

Hope that makes sense.
-m