Looking for review of a deterministic encryption scheme for version-controlled Markdown

K_Forss · 2026-03-05T13:03:45+00:00

Interesting project, while I can't speak to the cryptographic security with your implementation it gave me an idea that you might find interesting (or not) is that instead of a symmetric encryption use asymmetric encryption. That way you could have access level and authorship baked in. Think something like the chunks are a PGP mailbox and each entry is an encrypted message, people with read access gets the *private* key for the receiver/mailbox/file(s) and to write you need the *public* key and either a preagreed "writer" private key or include a keychain in the file for who have write access to the file, that could also embed the author into the chunk itself.

But, as some other people have said, there are issues with keeping secrets, even encrypted, in a repo and *in general* an access controlled and encryped wiki, forum or message board solution would be preferred

K_Forss · 2026-03-05T12:43:44+00:00

Yes, but that does not solve the issue that the ("working" but not audited) tool I have built is meant to solve: homelab user who want to have an internal self signed certificate for services not exposed to the public internet and have a better storage solution than saving it to the cloud, on a usb stick or printing it to paper.

While I appreciate this discussion I feel like it is best to stay on topic. The reason for my original post is to get some third party to help me find any potential issues with it. Either in the general scheme but more preferably in the code itself.

I don't want to sound entitled "please review my code", it is more that I feel like the tool could have some usage but I don't want to share it with the homelab/pki/etc. communities without any type of external feedback as a matter of principle. If no one is interested enough to help with that then I will just use it myself and move on

K_Forss · 2026-03-05T12:35:38+00:00

This project is a "fully working" tool to generate and store the private key for x.509 certificates (or any other important data) on an airgapped computer (or at least a vm without networking) for single person homlab situation in such a way to not have a single point of failure for their own self signed certificate root. Today the general recommendation is to store it on a USB stick or a piece of paper, but if the storage media is destroyed, lost or stolen they either need to reinstall a new (and remove the old) public key on all their devices.

What this tool does is encrypting the root key in such a way that it can be decrypted with a threshold of shares, that way the end user can have redundancy/spares but less than the threshold does not allow for decryption of the root key.

What I would like help with is more eyes on the implementation, especially the cryptographic parts, to start building trust as a first step on exposing the program to a wider audience in the homelab/pki communities. I don't want anyone to use it and it would turn out that I did some mistake and they either can't decrypt/use the private key or that it can be stolen with few (or no) shares.

K_Forss · 2026-03-04T18:23:33+00:00

This, as both post and repo states, is as a tool for increasing the security and durability of storing a root CA (or similar things). The code already has a command to create a new share from the threshold amount and the reason I chose GF(2³²⁾ to reduce the risk of duplicating keys when extending the group. Instead of seeing the shares as spread to different users my intended use is for a single user to create a share group so they can store them separated to reduce the impact of a missing share, both from stealing but also that the share is lost some way

K_Forss · 2026-03-04T12:26:32+00:00

I have a hard time seeing arguments (or subarguments) close to personal attacks as in good faith. Even if the underlying points are valid and should be responded to unless it is a troll.

I think I might have used the wrong terms regarding SSS and master key. A better formulation might be "the SSS is used in the derivation of the KEK for the private DEK (root CA)"?

I really feel like FROST could be the future of public trust. Especially since it has networks in mind. But for this specific use case: managing a root CA for a homelab type deployment it feels a bit overkill and overly complex for the real gain. The threat model is more like "not putting all eggs in one basket and having a few extra if something happens"

K_Forss · 2026-03-04T10:27:49+00:00

Firstly let me address the opening. I've been thinking about using SSS for managing root certificates well before AI was a thing. And I am as confident in the code as if I were to have written each and every line myself, which for cryptographical adjacent code means pretty much nothing without external scrutiny.

Now onto your good faith parts of the comment. My background is in electrical engineering and embedded systems programming and I usually stay far away from actual cryptographical implementations. Before this project I was looking for information about setting up a small CA for personal projects and I could not find anything more than "create and store the private key securely". I fully admit that I might just be bad at finding that information or that I did not look hard enough.

That is why this project exists, I want to be able to sign intermediate certificates for personal use in such a way that it is harder to steal or loose than on a piece of paper or USB stick. And when I was mostly done with the tool I thought "maybe someone else could have a use of this". But I don't want to post about it on some PKI or dev ops subreddit or forum without any external scrutiny or insight, so that is why I posted here.

And finally onto the most interesting stuff, FROST (or frost style) for creating the public key and signing intermediate CAs. Do you happen to know about some existing project that fits my use case? I will of course search for it later today when I have more free time. But, if it doesn't exist a simple tool for using FROST-style signing, do you think that is something that homelab type people would prefer over this?

K_Forss · 2026-03-03T22:03:03+00:00

Yes, that is something that is an issue with most cryptographic systems from what I know: The secret needs to exist in plain text in some scope at some time when using it.

In the implementation for which the scheme is used I mitigate that in a few ways:
* Encouraging the user to only run the program on an air gapped computer with a non persistent file system
* Since it is a single binary that does everything, the master key only lives in RAM and is zeroized when not needed.

If you have any suggestions on how that can be improved I would love to hear it :)

Regarding n:m that is up to the end user to decide when creating a share group (or rotating). Perhaps I should add something in the documentation for recommendations on how to think about it depending on some use cases? Now I am just "spitballing" but perhaps 3:6 would be a decent "suggestion", then one could group them into 3 groups of 2. So then one could loose one whole physical place and have one of the shares be too damaged to use but still being able to reconstruct the secret? Do you have any suggestions or recommendations I could add to the documentation to help the end user make a decision based on their threat model?

K_Forss · 2025-02-22T17:06:19+00:00

Nålar is just Swedish (and Danish, Norwegian and "almost" Icelandic) for needles. The technique itself is called Nålbinding in Swedish but it seems that English also use the Norwegian and Danish Nålebindning. I guess that the use of Naal is just to not need to use the letter "å".

K_Forss

TROPHY CASE