Just a question I’d like clarity on. Like @Mark_S I get frustrated by the increasing scale of managing credentials needed on the net. For years I used stand-alone programs to do it. But they make things complicated (platform specific).
So I’m thinking to have an encrypted TW for that in a stand-alone, offline browser.
But before I do that can you confirm if it would be a very secure method?
Many thanks for any comments
TT
The Encryption docs links to the doc tiddler Stanford JavaScript Crypto Library which states
The Stanford Javascript Crypto Library is a project by the Stanford Computer Security Lab to build a secure, powerful, fast, small, easy-to-use, cross-browser library for cryptography in Javascript.
Thanks Mat. I did find one comment about the Stanford Javascript Crypto Library on Hacker News I thought possibly relevant to how I intend to use it …
As with anything - the result is only as secure as transmission and execution - ... | Hacker News… — so isolation is the only guarantee. If you’re truly paranoid - run without network connectivity and transmit through physical media.
Yes, but those docs say:
SJCL is secure. It uses the industry-standard AES algorithm at 128, 192 or 256 bits; the
So, which bit setting used with TW?
My original concern, and I suppose it was a false memory, was that an earlier version of TW used 56 bit encryption.
Also, there can be a difference between the encryption engine and implementation. Like having a dead-bolt on a balsa wood door. Security can be very complicated. Most products that depend on security have some sort of public or private testing, sometimes with rewards for discovery of weaknesses. Obviously that’s not an option here.
My feeling is that I wouldn’t want to use it as a password manager, but it’s good enough for journals, contacts, appointments where I wouldn’t want (for instance) Google drive snooping around inside for marketing info.
That is on-point. On promo and on fact.
IF I were promoting Encryption for TW whose flag signals are …
Encryption Options are Baked In (man that is a cool feature!);
Encryption is 256bit (“using the baked-in standard Stanford crypto library”) … (very good to know that; whatever it means)
In short: “Encryption” might be a promo point? And the number of “bits”, whatever they are matter?
WHAT key level is the default (128, 192 or 256)?
Just asking for a promo friend.
TT
I did a little digging, TiddlyWiki uses the SJSC Library and does not pass any configuration (as far as I could tell). Therefor it uses the SJSC defaults.
Unfortunatly, the SJSC documentation does not disclose what those defaults are. So I took it on myself to run a sample through the Demo using just default values and the result was:
{
"iv": "+Idg4aGgkQ7gc/FTSzpAOQ==",
"v": 1,
"iter": 1000,
"ks": 128,
"ts": 64,
"mode": "ccm",
"adata": "",
"cipher": "aes",
"salt": "AEqd6WKMDHQ=",
"ct": "dy1cYfjiCZskVuwv0bM="
}
This looks like the default is: AES 128 in CCM mode. I’d say that is pretty good! IIRC this is the same default for Mac Encrypted Disk Images.
Now if you wanted I don’t think it would be too difficult to modify the TiddlyWiki source to increase that to 256 but even then I don’t think it would matter too much. The difference between 128 and 256 AES focused attach vectors is like comparing the NSA to China or Russia. You would need a pretty dedicated government agency targeting your TiddlyWiki specifically to make any cracking attempts plausible.
That all said, the true weakness is not in the cipher but in the password I have stored passwords in an encrypted TiddlyWiki with confidence because I was sure to choose a strong password—same is true when I use Vim’s built in blowfish encryption.
If you pick a very lengthy and hard to guess passphrase as your encrypted TiddlyWiki password I think that would be far well enough to be secure for almost all attach vectors up to any highly motivated and narrowly focused government cracking your specific wiki. Again, unless you are Edward Snowden you might not have to worry about that.
Checkout this handy tool to get an idea for password length and its direct effect on cracking strength.
Great post! Thanks for taking the time to lay out the issues so well.
IF there were a FAQ for TW that asked …
Q: How does Encryption in TW work?
Refer to Query: How secure is the inbuilt encryption option in TW? - #6 by sukima
Your notes would work well.
Your links too helped me resolve on password strength/length. Both those resource pages were ace … I did Gibson’s Haystack. Length matters …
That is easy to remember as “G’s3Kx”
I think that would be enough to deter @Mark_S from stalking me? 
Hah! I’m working on a quantum computer in the basement. I’ve already got a couple of hydrogen atoms.
A couple of hydrogen atoms are walking down the street and bump into each other.
One hydrogen atom asks, “Are you OK?”
The other replies, “No, I lost an electron.”
The first then asks, “Are you sure?”
To which the other replies, “Yeah… I’m positive.”
Out of curiousity, has anyone already changed the code to aes 256? I’m planning to try, and wanted to ask before poking at the ( frankly very complicated) code.
I don’t know but I searched for 256 in $:/library/sjcl.js and its there.
Going off of what sukima pointed out and what I’ve compared, is that the option to use AES 256 is baked into the minified version, but needs to be selected, as TW is using the default settings, which defaults to AES 128
I’m just not sure how to pass configurations to change it to 256, unfortunately.
I believe I have found the specific code that is needed to be changed.
Normally you would choose specific settings, if I understand this correctly, but you can edit the minified library itself to change the default values from CCM AES 128 to something else.
In my case, I have adjusted it to 256.
And after saving a copy of my sandbox wiki, nothing broke when inputting my password so… success?
I’m only a novice when it comes to JS, and even less experienced with Cryptography.
(which, can we take a second to admire how frickin cool this looks with the colored syntax? I just wanna put it on record that I had a certified nerd moment as I felt like one of those overly dramaticized ‘L33T hackerz’ hollywood loves to paint them as, while I was reading through all of this.)
There are settings that can be used. No need to change the minified code!
That’s good to hear, though… which settings, specifically?
Also, why is the default level set to AES 128?
Were they just imported over when the entire minified code was implemented, or possibly chosen to reduce decryption time in larger TW?
I did not read the screenshots in your other post. You actually did find the right place to change the defaults 
The TW code does not allow any parameter changes at the moment. @jeremyruston We would need to implement that possibility or also “patch” the library to use 256 bit as a default?
Because the library is old. The “whitepaper” as described at the homepage was published in 2009. It gives an overview about the decisions they made and why.
According to wikipedia AES 256 seems to be “quantum resistent”, while AES 128 is not. – So it may be time to use “stronger” defaults.
I’m not sure if I do understand this question, but TW5 development started at about 2012 or earlier. So at this time computers where significantly slower and had much less memory. The defaults where sensible.
hope that makes sense
Every bit made sense to me 
I’d love to see a tiddler that can be created where you could set your encryption options, such as if you want to change the amount, or from ccm to any others, but I’m not sure if thats feasible without a change to the core being needed.
Sidenote, abit topic adjacent, but if considerations are being made for the encyption js, maybe discussion for inclusion of openpgp could be brought up?
The idea of being able to generate pgp keys in a tiddlywiki sounds, well to put it bluntly- really cool haha
Edit: seems like I wasnt the first to bring up PGP, unfortunately the discussions about it are way above my skill level 
