Decrypt through cli

[andreasgou]

Is there a way to decrypt (in the opposite way)?

[robinmoisson]

Hi, not at the moment as it's not really the main use case. The idea is to produce a standalone html file that can be unlocked by a human through a browser easily.

If you want to encrypt and decrypt files directly from the cli you probably should use a classic encrypting tool, openssl for example (https://wiki.openssl.org/index.php/Enc#Basic_Usage).

Let me know if you have a different use case in mind.

[andreasgou]

I use a personal TiddlyWiki to keep my stuff in one place and structured, various business and personal resources, TODOs, links, account info and passwords, even lyrics and recipes.

The wiki is just a single html file and that proved really helpful for many years now. However, security was always an issue. Your solution is simple and solves me a lot of headaches of being breached since I carry this file quite often to other computers.

However, the wiki is updated continuously, that's the purpose after all. So there is the need to decrypt the file before creating or updating content and then lock it again. You also want to keep track of changes and compare versions, that's another reason you'd want them to be decrypted.

Only if I had decryption as handy as encryption is, I wouldn't need to keep the open version at all.

[sigvaldm]

I second this. Doing CLI decryption would be useful, since that would allow me putting encrypted files with various stuff in an open repository (not that I would use it for banking details, but still).

[infracritical]

I strongly disagree. Any method of undoing something that can be done offers an attack vector for someone compromising your code. IMHO, similar to other forms of hashing, the 'encryption' method should be one-way ONLY. Keep a copy of your source code near 'n dear to you. Having the ability to decrypt what you've encrypted defeats the whole purpose of utilizing this software tool.

[sigvaldm]

Dear @infracritical, I am wondering if we're talking about the same thing. I do not advocate using two-way encryption for password comparisons, as is often done on dynamic sites. I want to be able to decrypt the contents of the webpage from the CLI, and not only from the web browser. My understanding is that StatiCrypt uses AES encryption, which is not a one-way hashing algorithm, but a two-way symmetric algorithm. If it were not already possible to decrypt, how would it be possible to display the contents in the browser after typing the password?

[sigvaldm]

@andreasgou: My use case is similar to yours. I store not-so-sensitive information behind StatiCrypt encryption. I'd like to keep it version-controlled, but encrypted, and just locally decrypt the pages while working on them. One solution that worked for me is based on @robinmoisson's suggestion of using the openssl command line utility. I have made a script that encrypts selected web-pages using both openssl and StatiCrypt, such that one file is generated from each. Another script decrypts the web-page from the openssl file, which I can use when modifying it. I use the same encryption for openssl as StatiCrypt (AES) to make sure the level of security matches.

On another account (pun intended): I'm not sure I would keep account info and passwords behind StatiCrypt. I would use dedicated software for that (for instance LastPass).

[RignonNoel]

I strongly disagree. Any method of undoing something that can be done offers an attack vector for someone compromising your code. IMHO, similar to other forms of hashing, the 'encryption' method should be one-way ONLY. Keep a copy of your source code near 'n dear to you. Having the ability to decrypt what you've encrypted defeats the whole purpose of utilizing this software tool.

For me this reasoning match the definition of security by obscurity.

This tool is a tool of encryption, if it was one-way it would have used hashing technology but it's not at all the purpose of the project. Having a decryption tool for an encryption method is a requirement since it's a part of the flow, here you can already decrypt everything with the little .js code or even via the demo website.

Having the decrypt method directly in the CLI will just make things more easier:

• Users will be able to implement new way to use it
• It will make it more obvious for users that it's an ENCRYPTION method and so that it's completly doable to decrypt it (making it more secure by allowing people to better understand the tool)

[robinmoisson]

Thank you all for sharing thoughts on this.

I agree in some cases it could be pretty convenient to have one simple repo with encrypted files, have an ignored .env file with the password (once #134 is here), be able to run npm run decrypt to decrypt all files in place, edit them, run npm run encrypt to encrypt them all and commit & push.

My only concern is how to get the encrypted data from the encrypted html. The only solution I see is searching for the strings var encryptedMsg = "..." and var salt = "..." and extracting it from those. The thing is:

• it might break for people using a custom template. Maybe we can add a comment just above those variables to tell to not rename them, and have that in the --decrypt flag description as well.
• it might break if we inline code from elsewhere that might use the same variable names for something different. Maybe changing the name of the variables to something really unique could be enough.

The other solution I see would be storing the encrypted data in a metadata file next to each encrypted html file but that feels way too cumbersome just for enabling this specific use case.

(Feedback or ideas are welcome, feel free to share if you want.)

[robinmoisson]

StatiCrypt v3 brought more control over the password_template and I could add a way to decrypt through the CLI - you just need to add the --decrypt flag and StatiCrypt will run in decrypt mode. The README has been updated and this is now supported in 3.3.0.

Thank you for the thoughts and suggestions!