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.