No encryption in node.js client-server mode

[valpackett]

When used as a single HTML file, TiddlyWiki5 allows content to be encrypted using the Stanford JavaScript Crypto Library.

But why not when used with the node server?

[Jermolene]

Hi @myfreeweb

But why not when used with the node server?

I implemented the single file encryption quite early on because it has architectural implications for the way that TiddlyWiki boots up in the browser. Adding encryption of individual tiddler files to Node.js is much more straight forward, and only hasn't been done because there hasn't been any demand. I suspect that there would be better performance by using an encrypted volume to store the tiddler files in any case.

[valpackett]

But using an encrypted volume is not good enough. Data has to be encrypted before it leaves the browser.

[Jermolene]

Data has to be encrypted before it leaves the browser.

We can use SSL for that? Or are you interested in scenarios where the user doesn't trust the operator of the server?

[valpackett]

Yes. Well, the operator must be trusted to deliver the correct (non-malicious) JavaScript, but disk+transport encryption is not end-to-end. Disk encryption is only a last resort thing.

[pmario]

@Jermolene may be labelled: improvement or feature request?

[Jermolene]

See also #310 "Is it possible to encrypt a single tiddler?"

[mgliewe]

i would second that.

while transport encryption ist fine, there are scenarios where the datastore just isnt secure enough.

for instance, i would like to use a tiddler to keep a log of due admin tasks on a live server. once someone breaks in, i wouldnt like to give the intruder hints what other systems i work on, might be involved or what tasks or strategies are planed in the future.

maybe you could give some basic directions where and what to look for in the source, to try to implement this feature by myself?

[sukima]

No offense but if your concerned about hacking attempts on the disk stirage then placing sensitive data on a server like that is irresposible. For the scenario you describe trusting a Javascript crypti library to perform the job of both disk encryption and SSL seems wrong. Save sesitive data as a single html tiddlywiki instead on an encrypted drive. Not on some public server.

[tobibeer]

Save sesitive data as a single html tiddlywiki instead on an encrypted drive. Not on some public server.

I'd very much agree.

[mgliewe]

Save sesitive data as a single html tiddlywiki instead on an encrypted drive. Not on some public server.

basicly you're totally right. but i'm not talking using a tiddly as secret key store or alike; its more thought as of a collaboration tool for the team.

for instance, i'm working on about 20 different customers a year, each having their own infrastructure; each installation has its issues, timelines etal. right now, we're mis-using gitlab issues and snippets, and local textfiles and saved emails to keep track on how to handle the various systems.

handing over tasks to other team members tend to have a little bit communication overhead.

this ist internal, crucial information, but not neccessarly 'sensitive' as in a 'giving out credentials' .

For the scenario you describe trusting a Javascript crypti library to perform the job of both disk encryption and SSL seems wrong

i'm aware of the implications of that, though that's not entirely a javascript problem but rather a 'trusted source of code' scenario.. javascript itself is nowerdays very well equiped to perform strong encryption, although there are lot of more sidechannel attacks on javascript as there are on native code.

whatever, i discoverd that using the tiddlyspot plugin will fit to my use case es decribed in http://tiddlywiki.com/#:%5B%5BSaving%20on%20a%20PHP%20Server%5D%5D

[tobibeer]

Still begs the question: Why the need to put it at the server directly?

[mgliewe]

no need.

how i understood the tiddles, its all about not depending on foreign infrastructure.. you got the tiddly, you own it.

[crypdick]

I host my TW5 on Github Pages (like this guy (repo)). It would be nice if to make it so that some stranger would need a password to decrypt my wiki, as well as have the files on the Github repo be encrypted. I like the fact that I can work on TW locally, it generates .tid files, I push those modified .tid files to my Github repo and Travis CI automatically generates the website from the tid files. It would be nice if the .tid files were encrypted from end-to-end.

[jdubbbb]

With the encrypted single html file option seemingly going away with FF57 blocking support for TiddlyFox's functionality, easy full encryption for TiddlyWiki on node.js seems a lot more important.

Or are you interested in scenarios where the user doesn't trust the operator of the server?

I use my TiddlyWiki at work and don't necessarily trust every single IT person that walks in the door or is planning to leave the company. Corporate security software that scans workstations these days is also very invasive and could potentially leak data.

[Jermolene]

Hi @jdubbbb the encryption available in the single file edition of TiddlyWiki is independent of TiddlyFox, and works with all the other methods for saving changes. It doesn't work under Node.js in the sense of allowing one to have encrypted tiddler files but there's no reason why we couldn't add that feature. In the meantime, my recommendation would be to use a separate file encryption solution (eg FileVault on OS X) when working with the Node.js configuration.

[sukima]

@crypdick

as well as have the files on the Github repo be encrypted.

You've just defeated the point of GitHub and version control You've crippled it to nothing more then free web hosting. The kind of encryption your asking for is way out of scope for TiddlyWiki. Use disk encryption on a private server or alternative hosting where the drives are encrypted. No other web server stores their data like that it is not scale-able.

I think what is better in the case of encrypting TiddlyWiki is to use it as a single file wiki with a password. That way you are no longer dependent on other tools to manage it and you can store it on a free hosting provider like DropBox.

[sukima]

@jdubbbb

I use my TiddlyWiki at work and don't necessarily trust every single IT person that walks in the door or is planning to leave the company. Corporate security software that scans workstations these days is also very invasive and could potentially leak data.

In these case I've simply used a single file TiddlyWiki which uses the Stamford crypto lib (password) and hosted it on DropBox. Node has nothing special in this use case.

[fkohrt]

As of 2020, end-to-end encryption for applications that are shipped via the browser is not a rarity, notable examples include:

• document collaboration: CryptPad
• pastebin: PrivateBin
• communication: Element (Matrix)
• file sharing: Nextcloud, Lufi, Firefox Send, Up1
• polling: Croodle
• note-taking: Turtl
• password manager: Bitwarden, clipperz

I believe TiddlyWiki would fit nicely in this list, given the advantages:

• increased protection against mass surveillance (e. g. scraping server storage)
• increased protection against accidental (but not deliberate) exposure to server operator
• increased protection against "honest but curious" server operators by making it (psychologically) harder to access protected information
• plausible deniability regarding the content for the server operator

[sukima]

I re-read this thread and I have to say I think there is a conceptual breakdown between how TiddlyWiki works and the expectations on how others think it should work. TiddlyWiki first and foremost is a personal wiki. The fact that it can be hosted in a variety of ways is tangential to its core concepts. Saving a file on a drive encrypted is equivalent to a password encrypted zip file. Securing ease dropping from browser to the node version is HTTPS. Securing the node data files is disk encryption. Each level has a well tested and viable solution that is out of scope for what TiddlyWiki does.

I will compare this to FireFox Send (as that is the only system in that list that I am familiar with) encrypts in the browser for the sole fact that the users need not trust Mozilla (a third party intermediary). Unlike TiddlyWiki where there is not usually a third party.

I think what needs to happen here is to carefully articulate the threat vectors you encounter in your setup so that a viable solution can be developed. So far I know of the following:

• At rest discovery with Single File mode — Use builtin SJCL password feature
• In transit discovery with Single File mode — Same as above, use SJCL password feature
• At rest discovery with Node mode — Use disk encryption
• In transit discovery with Node mode — Use an HTTPS proxy
• In transit and at rest discovery of Node version hosted on an untrusted third party host — Don't do this; it is a bad security posture — but if you insist you can use the encrypt single tiddler plugin

In any case besides the convenience of the Single File mode SJCL password feature the security of TiddlyWiki itself is out of scope for what TiddlyWiki is. IMHO I feel that if such a feature were required that it be built on a layer above/around TiddlyWiki core as a separate project.

Finally, to put this into perspective if I were to posture my security on say a Tor Hidden Service. To gain greatest distribution and plausible deniability I would likely edit my wiki locally in Node on a secure computer with Disk encryption. When ready to publish to the public I would use TiddlyWiki to build a single file HTML with the SCJL password enabled and host that single file on a Tor Hidden Service different then my development machine. In this way I gain all the advantages described and it fits within the verticals that TiddlyWiki itself focuses on.

[fkohrt]

I re-read this thread and I have to say I think there is a conceptual breakdown between how TiddlyWiki works and the expectations on how others think it should work.

I believe I see what you mean, TiddlyWiki is not meant to be an enterprise product, simultaneously accessed by thousands. In this regard some entries in the list may be misleading, still for others I can imagine that TiddlyWiki is quite similar concerning on what scale they are deployed (take clipperz or Turtl, for example). And while you may be familiar with the "flagship" public instances, all of the above are also meant to be self-hosted and a large tail may actually serve a very limited amount of people per instance. The list is really about how E2EE has gained traction and is valued. (Besides from that, I don't regard such breakdowns valid points on their own, putting technology to use in creative ways may be a very fruitful undertaking.)

I think what needs to happen here is to carefully articulate the threat vectors you encounter in your setup so that a viable solution can be developed.

A sound threat modelling is surely something that should come first for people who are seriously concerned about keeping information private. At some stage non-audited solutions should be avoided, let alone Javascript and browsers. But if we can offer a solid protection to people before they actually should level-up to paranoid, why veto when dealing with most private content?

Encryption at rest is great when the computer is turned off, but on a machine that is constantly connected to the internet – which a computer running the Node.js version very likely is – the protection it offers is limited at best. Besides, if you don't own your hardware or rent a root server, you never get to set up disk encryption. And the difference in effort between setting up disk encryption and a mere command line switch makes the latter even more worth it.

If the current solution for increased security is to not use the application (Node.js version) or use deficient yet effortful measures (full disk encryption) users would definitively benefit from the proposed feature.

[fkohrt]

I do see the point however that a maintainable codebase is something worth on its own, especially when developing time is limited and one has to set priorities.

[pmario]

With TW version 5.1.22 the node syncer has been completely rewritten and there is the local storage plugin in the core now.

The main assumption of the idea is, that you trust your client device and your browser!!

• So the idea is, that decrypted tiddlers are written to the the local storage only.
• If a "sync encrypted" is requested, there needs to be some "user interaction"
  • eg: type encryption PW 2 times.
• single file tiddlers are encrypted
• encrypted tids are saved to server
• local store will be cleared

just an idea

[Jermolene]

I think the easiest way to use TiddlyWiki with a server with end-to-end encryption is to use the native encryption support, and save to the server as a single HTML file via a single TiddlySpot-style POST over HTTPS, instead of syncing individual tiddlers. The setup is nice and simple, and easy to verify.