I wonder if it would be possible to enhance crypto in TW by using ed25519 key pairs crypto?
Then “keylocker” could use public keys to address private key owners only
This library is providing it
https://git.duniter.org/libs/g1lib.js
I wonder if anyone could help me “make it a plugin”
I don’t remember exactly but I think I recall there was talk at one point to consider LibSodium as it can compile to WASM. However the SJSC lib has the advantage of being small-(ish) and convenient to be included as core within the HTML. I think that lib sodium was a bit too heavy to be part of the base size of TW.
One of the issues is that any crypto code must be separate from tiddlers or plugins as it is needed for bootstraping the TW system (in the same way the core code is).
Sure a different crypto lib could be used to replace the SJSC lib though doing so I think might be an exercise for someone willing to fork their own modified version as SJSC is just so convenient for the official TW code base.
The advantage of the built in crypto library is, that it is completely self contained, with no external dependencies.
Your suggested library seems to have 8 external dependencies: https://git.duniter.org/libs/g1lib.js/-/blob/main/package.json#L41. Several of them have other dependencies.
Only 1 package has some info about 3rd party auditing. I don’t see, why a crypto library needs node-fetch as a dependency, which in turn have plenty more dependencies … node-fetch is for networking and imo has nothing to offer for a crypto library.
If it is “compiled” and minified, how big is it the whole stuff?
I personally wouldn’t touch it.
I don’t know the exact size, but for “browser only” packaging is without dependencies
https://git.duniter.org/libs/g1lib.js/-/blob/main/npm/package.json
This discussion is parallelized with G1lib maintainer
Issues: https://git.duniter.org/libs/g1lib.js/-/issues/8#note_34098
Could there be an advantage having the encryption and decryption as seperate plugins?.
It seems there may be cases where one would selectively install and de-install these components, made very easy with bookmarklets.
Thanks to this “double thread” it appears that a minified version exists (67kB)
https://unpkg.com/g1lib@3.4.2/browser/crypto.mjs
Now I need to “retro engineer” the “action locker” button
and understand how to “plug” g1lib.
Not to make a big mess, Is there any system “$:/” path I should know?
@jeremyruston
or anyone else may be knowing who has introduced the actual “crypto layer”?
I’d be pleased to discuss with
hmmm, Just because something is packaged for a browser doesn’t mean, that it’s dependency free. It only means it is 1 file, which contains all the code.
Where the code comes from is important. If it is spread over more than 1 repository, it “has” dependencies. … It’s OK to spread the code.
BUT for a crypto library, that you need to trust, it’s needed to be able to completely understand the code and how it is built, not just include a minified js file and trust it.
Since I can’t read French, I can’t read the other discussion. So I’m out.
I’m very new to TW and, looking for verification of signed contents in TW, just found this topic about ed25519 
Would be any chance to see something like GitHub - openpgpjs/openpgpjs: OpenPGP implementation for JavaScript integrated in TW ?
I’m not as js guy and won’t be very helpful but getting PGP in TW does sound good for you ?
Hi @aya and welcome to the community.
Integrating PGP-like functionality in TW is an interesting idea, but it does raise some difficult questions. In particular, if TW is the means for performing the crypto operations and for reporting the results it is very hard to ensure that an adversary had not interfered with the wiki (perhaps reporting the results of the data integrity checks wrongly). In its usual forms, TiddlyWiki is inherently hackable – there’s nothing to stop somebody from opening the HTML file in an editor and making any modifications they like. So, any integrity assurance emitted by TiddlyWiki would not be trustworthy.
One solution to the conundrum is for the crypto operations to be performed by an external tool that can be independently verified on its own, such as the PGP suite.
When stored in IPFS, only the one “having the key” can publish a new “TW state”.
Using “End to End encryption” allow each TW owner to address a tidller to another…
If one store it’s “secretkey” (g1lib or pgp) locally or globally encrypted with actual password system, then “crypto codec layer” would be available only if the right password is provided.
We are opening a crowdfunding to promote and build a collective IPFS TW indexed storage portal.
Hi @papiche
First, I’m a big fan of IPFS, and convinced its unique properties enables some interesting new use cases for communities on the web. Bunker BOX looks like great work in that regard.
I may well be misunderstanding the scope of your question. I tend to look at questions from the perspective of the core and the desire for universality. I understood the discussion to be about signing content within a TW so that it can be cryptographically verified.
What I meant about being inherently hackable is that there are a large class of theoretical threat models where a TiddlyWiki can be taken over by an adversary. For example, social engineering might be used to induce somebody to install an innocent looking plugin that has nefarious hidden functionality. For most of us, in everyday life, the risks are negligible. But tools that verify integrity must have a high standard of proof. It’s not my area, but I think that there are philosophical limits here: one cannot trust what an untrusted entity asserts. A trusted entity is needed to start a chain of trust.
I imagine that in your application the chain of trust might well be rooted in the guarantees that IPFS itself provides. It’s particularly hard to reconcile the integrity requirements with the provision of editing functionality to a human user.
Disclaimer: I’m working with @papiche 
This is where IPFS comes in the game, playing with tiddlys and tiddlers in IPFS offers an underlying layer of data integrity.
The main idea behind @papiche project is to join all crypto apps in ed25519.
I wrote some crapy code to extract ed25519 keys from gpg and convert them between G1 (base58) or IPFS (b58mh) formats.
Having ed25519 sign, verify, encrypt, decrypt operations capabilities in a TW would be awesome 
Edit: Something like https://tweetnacl.js.org/ ? or built in crypto library could already provides that through openssl support ?
When we could use “ed25519” key to “cipher or sign” “tiddlers fields values”, and “tiddlers”, it makes tiddlers being able to have a private or group diffusion among TW.
You’re right, any one could suffer a “code injection” or “hijacking” of it’s TW. But user is mainly responsible of it, mainly because of sweeping to copy an untrusted tiddler
That’s why, once the one TW, one Key, one People is an interesting feature established in the application.
This is the main trouble in a “peer to peer” application spreading, such App having no central point are empty rooms showing it’s magic only when users and data enters in it and make the keys interact (sewing blockchains from all)
I think, and are working on it.
TW is a great platform to demonstrate how ‘crypto’ could shape our ‘cyber-exchanges’ in “a crypto friends TW world”.
Now let’s see if G1Lib or GPG will be activated first.
We made a “dependency free” release of G1Lib.js available in IPFS
https://ipfs.asycn.io/ipfs/QmUyJLvdgJbmACtJ3YzaDCCBg3pthDE7SRqtYJTaRqWmio/crypto.mjs
In case anyone wish to make use of it https://git.duniter.org/tools/gsper/-/blob/master/public/dunikey.js) in TW 