In the last few days I went down the rabbithole of 4x4 sudokus, and found out that (up to permutations) there are only 12 possible solutions.
I decide to write up the small research I did as well as some fun findings discovered along the way in a blog post.
Also, yes this is extremely pointless and silly, and the math involved is not incredibly high level, but I still think it's an enjoyable bit of recreational math worth your time!
Did you check for rotational and mirror symmetry? As in, are the 12 unique sudokus just the same one, rotated in 4 ways, and mirrored along the x or y axis?
I was wondering this myself so I wrote a script that shows that there are duplicated puzzles if you count a rotated Sudoku as being equivalent. Here's one example:
Puzzle 2 is
1234
3412
2341
4123
If you rotate it counterclockwise you have
4213
3142
2431
1324
And if you normalize it, replacing the first row with "1234" (brilliant idea from the post), you get
1234
4312
2143
3421
Which is listed as puzzle 7. A quick check gives me that puzzles 1, 2, 3, 5, 11 and 12 would be unique under rotation, but I wrote that check in five minutes so there must be bugs somewhere. Also, I performed no check for mirror symmetry whatsoever (update: I did a quick one, same result).
I don't want to miss my chance to say that the post is brilliant and that it convinced me to leave what I was doing to check for rotations. I was nerd sniped in the best way and I take my hat off for the OP.
Depends on your usecase. If I understand it correctly, KeePass is "just" a password manager, not meant to deploy files to a system.
So for example if you wanted to backup and later import/deploy your ssh key, you'd have to manually take the saved value from KeePass and paste it into a file in the correct location (I'm only assuming tho, I don't use KeePass)
My tool is intended more for deploying files to a system where they can be used by various programs. This is closer to something like sops/sops-nix.
I guess that my wording "secrets" might be ambiguous on this. It's not meant to be a password manager or work as one. It's meant to be a tool for backing up and deploying SSH keys, wireguard keys, and so on
I didn't know about it existence, it looks like a nice project! Also, it would probably play nicely with Nix (by writing wrappers instead of symlinks)
However it doesn't fit quite the same niche that my tool does. If I understand it correctly (though I only read those two links) fnox is more about how to use the secrets, ie given an encrypted description of the secrets, how to make them accessible to programs (kind of like sops?)
With my tool, secrets on the device are in plaintex and simply accessed by path reference by the respective programs. The focus of secs-man is more on exporting, ensuring integrity, and importing (possibly to remote machines). All of this, while being manually recoverable even without the tool.
Still, interesting project! Might take inspiration from it for some features
That is true, but it's not specifically what makes it unique. Most encryption tool (like https://github.com/FiloSottile/age which is what secs-man uses under the hood) do not usually bake in the encryption key, rather they expect you to generate it and provide it.
This is true for secs-man too: when you export it prompts with "Enter passphrase:" and you enter the passphrase (I am considering extending it to read the passphrase from a file or from an environment variable, or piped in from stdin, but I'm still not sure what to think of if from a security standing point and I they don't fit my current use so I don't have it in the current TODO)
What makes it unique is that it can be completely emulated by hand (even though it might be a bit tedious) from just a terminal with bash and age installed. This is explained a bit better in the blog post or in the "philosophy section" of the README, but the main point is that (in my opinion) you should NEVER find yourself vendor-locked-in for any data, in particular for secrets. However, you will always need tools for managing them. My tool is designed to be usable and avoid vendor-lock-in, meaning that even if you lose access to the tool you are not locked out of your tools!
I have probably phrased it better in the linked blog post, I invite you to read it if you're still curious. I'm here for any other question!
Sincerely, I don't get the motivation for this. It feels like `age` is pulling most of the work I care about. `age` is the only tool here encrypting and decrypting secrets, are you managing the orchestration of secrets with your tool?
age is pulling all the encryption work. What the tool does is the import/export managing.
First of all, it creates snapshots for each export and it ensures to pull the latest snapshot during import. Also, it manages the hashes of the secrets (created on first export) and of the export, which ensure that the files are not corrupted, so that when I import I can be sure that no bitrot happened and the secrets that get copied on my machine are bit-identical to the ones I exported.
That being said, it's true that this is not a lot of work to be pulling. As I wrote in the blog post, this Rust tool could have been a Bash script. However I opted for not-bash because I don't feel particularly comfortable with bash and I like to have types. If I knew Go, it would have been a solid option
Yes, that was intentional. Originally it was just called "secrets-manager", I decided to shorten it only because it was (not really) too long to type, and a friend of mine had the realization that you can abbreviate it to something that sounds funny!
reply