Hugo: Add post encryption to content

[GoGoGoDoge]

I want to add a post encryption feature to hugo.
Right now there is a work around as proposed by this author in this repo:
https://github.com/Li4n0/hugo_encryptor/blob/master/README.md

It would be nice to integrate this solution into hugo.

[GoGoGoDoge]

It is actually related to #7154
The repo I mentioned above implements in a way to use python with beautiful soup to parse a specific html node and encrypt it on demand.

[moorereason]

First, cryptography is surprisingly hard. Generally speaking, only cryptographers should write crypto solutions.

Second (and perhaps making my first point), the examples linked to above use AES-CBC. AFAIK, CBC encryption is now considered weak due to padding oracle attacks.

Third, the easiest solution would be to use a verified, turn-key solution such as nacl secretbox, but the algorithms used by nacl are not widely supported (by crypto-js or WebCrypto).

Forth, I, for one, don't want to be responsible for maintaining a turn-key solution in Hugo. I'm not a cryptographer. The most I'd be willing to support is a general crypto API via template functions that essentially exposes the Go stdlib API, but even that would be need some careful thinking. Which all feels like a lot of work for a small reward.

I'm interested in the idea of a general crypto API, but I'll have to thinking about it.

@bep, what are your thoughts?

[GoGoGoDoge]

Thank you for the detailed response. This is indeed a lot of work for a small reward. I have to admit that encrypted web page is not a common use case in static website.

[Lednerb]

@GoGoGoDoge pls re-open this issue, I think this is also a valid feature request.

I've found this issue by research for implementing an encrypted post type for a theme.

---

Hugo already supports some encoding / hashing with the base64, hmac and md5 functions, while hmac and md5 will also have a limited number of use-cases.

Third, the easiest solution would be to use a verified, turn-key solution such as nacl secretbox, but the algorithms used by nacl are not widely supported (by crypto-js or WebCrypto).

IMHO a _simple_ symmetric encryption implementation might be built into hugo that uses a well-known standard and should only return the ciphertext without any script tags etc. as the linked hugo_encryptor does.
Background: I want to be able to also support this in the theme with disabled javascript support, so the users should be able to copy the ciphertext and decrypt it in bash / any other program that supports the used standard.

A syntax like the following is imaginable:

{{ encrypt "PASSWORD" .Content }}

---

This is somehow also related to #796 because with the exec possibility an external script / program could be used to archive encryption, but on the other hand, this would be way more complicated because of different operating systems and installed programs on the users' computers.

[moorereason]

@Lednerb,
As I said before, I would only be willing to support nacl secretbox. I'm not interested in supplying a javascript solution around the template functions. I only mentioned javascript and WebCrypto to point out the difficulty in writing a client-side companion piece to go along with nacl secretbox.

Would a nacl secretbox implementation solve your need? It would look something like this, I suppose:

{{ $Password := "change this password to a secret" }}
{{ $enc := secretbox.Seal $Password "hello world" }}

{{ $enc | base64Encode }} ->
rjfsV4uz4m9XV+znsnm/bNfHDkOKrafW0uIi0P2nL/0GskOXc8N08WlRJ3zq+1chMpvN

{{ secretbox.Open $Password $enc }} ->
hello world

I want the implementation to be super-simple and essentially front-end the golang.org/x/crypto/nacl/secretbox API.

[Lednerb]

@moorereason

Would a nacl secretbox implementation solve your need?

This would be totally fine and is the most flexible way of handling this, enabling also the possibility to set the password via frontmatter.

It will also be possible to use a javascript implementation of nacl like tweetncl to craft some interactive decryption on the website etc.

[bep]

We need some:

• Great arguments as to "why this would be useful" -- "I want to encrypt" is not a good argument.
• Use cases
• Is this useful to many?

[GoGoGoDoge]

We need some:

• Great arguments as to "why this would be useful" -- "I want to encrypt" is not a good argument.
• Use cases
• Is this useful to many?

Argument:

1. It is best used under a scenario that author wants to share message as long as readers have a token. And author doesn't mind if readers share the token to others.
2. Avoid search engine caching if the message users want to share is encrypted

Use cases:

1. In my own use case, I store all mail service tracking link (they are public accessible as long as you have the tracking number) with my friends in a hugo static page. I have encrypted those links into a secret message and share token with my friend. I don't really mind if my friend sharing the token to others (i.e. my friend is sharing his tracking link to others)

[Lednerb]

Hey @bep,
I will gladly provide further information on this

We need some:

* Great arguments as to "why this would be useful" -- "I want to encrypt" is not a good argument.
* Use cases
* Is this useful to many?

In my case I'm hacking machines on HackTheBox and want to publish some Write-Ups for machines / challenges. To ensure that only users can read that Write-Up / Walkthrough that have already hacked the machine by themselfs, the content should be encrypted with a password / token / flag / hash that is found when the machine was hacked / the challenge was solved.

One way to provide this would be to upload a password-protected PDF or 7z file for downloading, but after a while the HTB machines get "retired" and the walkthroughs can be published without any protection. In this case, it would be possible to re-publish the content.

A better approach would be (for me as the maintainer of the bilberry-hugo-theme to implement a frontmatter option encryptWithSecret (or a better name found in the future) that will ensure that the markdown-rendered content is encrypted when the hugo command runs. By removing the encryptWithSecret setting the content will not be encrypted on the next build, but visible for the public.

Although this use-case was my main intention to search for away to encrypt the content, there might be more use-cases and I'm looking forward to follow up this thread.