commit 5770aac9da0ce184bf9d39eb38ba73dc3ca0754c
parent 2b735deb4758e5ccab9f82c93c8f346b95adb874
Author: lash <dev@holbrook.no>
Date: Tue, 25 Jun 2024 22:02:08 +0100
Publish clortho
Diffstat:
5 files changed, 186 insertions(+), 35 deletions(-)
diff --git a/Makefile b/Makefile
@@ -6,7 +6,8 @@ BASEDIR=$(CURDIR)
INPUTDIR=$(BASEDIR)/content
OUTPUTDIR=$(BASEDIR)/output
#LOCALDIR=${HOME}/public_html/site
-LOCALDIR=${HOME}/pub/manbytesgnu.com
+#LOCALDIR=${HOME}/pub/manbytesgnu.com
+LOCALDIR=${HOME}/public_html/manbytesgnu.com
CONFFILE=$(BASEDIR)/pelicanconf.py
PUBLISHCONF=$(BASEDIR)/publishconf.py
KEYID=59A844A484AC11253D3A3E9DCDCBD24DD1D0E001
diff --git a/content.proposed/20220112_clortho.rst b/content.proposed/20220112_clortho.rst
@@ -1,33 +0,0 @@
-Clortho
-#######
-
-:date: 2022-01-12 15:03
-:modified: 2022-01-12 15:03
-:category: Code
-:author: Louis Holbrook
-:tags: crypto,hash,sha512,bash,cli
-:slug: clortho
-:summary: A key value store at your fingertips
-:lang: en
-:status: draft
-
-
-Ever since I started using the pass_ CLI as my password manager, I've found myself putting all sorts of stuff in there; usernames, email, urls, crypto addresses, api keys, you name it.
-
-It makes total sense that some of these items are in there. For example, I store the url to a service together with the password, usually accompanied by the username and the email used [1]_. No password recoveries needed.
-
-However, I've also started putting in things like crypto addresses, or even token smart contract addresses in there, it seems less of a good fit. One thing is that it spams the password directory. But another more sinister issues is that it's pretty clear for anyone reading the directory what items you are storing data for.
-
-
-Hiding the key
-==============
-
-So what if I want to store key/value pairs, and at the same time I want to hide what I am storing?
-
-..
-
- .. [1] I use a different email for each service I sign up to, and for every other context I have to leave my email for something.
-
-..
-
- .. _pass: https://www.passwordstore.org/
diff --git a/content.proposed/20240517_localmd.rst b/content.proposed/20240517_localmd.rst
@@ -5,7 +5,7 @@ Local documentation viewers
:category: Hygiene
:author: Louis Holbrook
:tags: bash,markdown,pandoc,vimb,buku
-:slug: internet-up-monitor
+:slug: local-doc-view
:summary: Bash script to render and spawn a viewer for markdown files
:lang: en
:status: draft
diff --git a/content.proposed/20240618_why_perl.rst b/content.proposed/20240618_why_perl.rst
@@ -0,0 +1 @@
+# https://blogs.perl.org/users/buddy_burden/2012/04/perl-vs-shell-scripts.html
diff --git a/content/20220112_clortho.rst b/content/20220112_clortho.rst
@@ -0,0 +1,182 @@
+Secrets in the shell
+####################
+
+:date: 2024-06-25 20:46
+:modified: 2024-06-25 21:58
+:category: Code
+:author: Louis Holbrook
+:tags: crypto,hash,sha512,bash,cli,ccrypt
+:slug: clortho
+:summary: A key value store at your fingertips
+:lang: en
+:status: published
+
+
+Ever since I started using the pass_ CLI as my password manager, I've found myself putting all sorts of stuff in there; usernames, email, urls, crypto addresses, api keys, you name it.
+
+It makes total sense that some of these items are in there. For example, I store the url to a service together with the password, usually accompanied by the username and the email used [1]_. No password recoveries needed.
+
+However, at some point I also started putting in things like crypto addresses, or even token smart contract addresses in there.
+
+That seemed less of a good fit.
+
+One thing is that it spams the password directory.
+
+Another, perhaps more sinister, issue is that it's pretty clear for anyone reading the directory what items you are storing data for.
+
+So what if I want to store key/value pairs, and at the same time I want to hide what I am storing?
+
+
+Hiding the key
+==============
+
+
+A simple solution is to hash the key together with some passphrase as "salt", along the lines of this:
+
+.. code-block:: bash
+
+ key=$1
+ # read passphrase from stdin
+ stty -echo
+ echo -n "passphrase: "
+ read passphrase
+ stty echo
+ hash_key() {
+ # dump the passphrase (assuming mktemp stores in volatile memory)
+ ktt=$(mktemp)
+ kt=$(mktemp)
+ chmod 200 $kt
+ echo $passphrase > $kt
+ chmod 600 $kt
+ # the salted key; first add the hashed passphrase (sha512)
+ kc=$(sha512sum $kt | awk '{print $1;}' > $ktt)
+ # remove the stored passphrase
+ shred $kt
+ # then add the key to the mix, and hash again
+ echo $kp >> $ktt
+ kc=$(sha512sum $ktt | awk '{print $1;}')
+ }
+
+The ``kc`` variable at the end of the script above now contains the *salted* hash of the key.
+
+Specifically, in this implementation, given key ``"foo"`` and passphrase ``"bar"``, the resulting key will be:
+
+``a9454592edbed78c3abb739dd88567bc92cc4ea1feee8480c7204d48d7d0e9ce86f9c79d55e39751ceb3f2774913841056293a5e8e8f440a3f281dffabd6f540``.
+
+
+Added value
+===========
+
+Now we can encrypt the store the corresponding value, and store it in a file that has that literal hash as the key.
+
+Using ccrypt_ as an example:
+
+.. code-block:: bash
+
+ data_dir=$HOME/.obfuscated
+ key=$1
+ vp=$2
+ echo -n "$vp" > $t
+ # create a file for ccrypt to read, because supplying any other way in shell is not so safe.
+ passfile=$(mktemp)
+ chmod 600 $passfile
+ echo -n $passphrase > $passfile
+ chmod 400 $passfile
+ ccrypt -k $passfile $t
+ shred $passfile
+ if [ "$?" -gt "0" ]; then
+ >&2 echo set key fail
+ exit 1
+ fi
+ # run the code in the previous section
+ hash_key
+ mkdir -vp $data_dir
+ cp $t.cpt $data_dir/$kc
+ shred $t.cpt
+
+At the end of this operation, the *encrypted* value is stored in a file whose name is the *salted* hash of the key.
+
+
+
+Mastering the keys
+------------------
+
+Let's say you want to store some `Ethereum addresses`_ that are of interest to you, but should be of interest to noone else.
+
+So, let's choose a prefix for "Ethereum addresses." Let it be ``etha``
+
+Next, let's pick an identifier that we will remember, that describes the *purpose* of the address. In this case it's for "governance of the organization 'Xy Zzy Co.'". The key then becomes ``ethagovxyzzyco``.
+
+Last, for a bit of extra fun, let's add some random stuff at the end of the string, like `shilling!shilling?oh,shilling <https://www.quotes.net/mquote/42425>`_. Thus, we finally end up with `ethagovxyzshilling!shilling?oh,shilling``.
+
+What we need to memorize here is:
+
+* whenever referring to an *Ethereum address*. we use ``etha``
+* whenever referring to *governance*. we use ``gov``
+* whenever referring to an entity, we use the name of the organization *less whitespace and special characters*.
+* the three above are added one after another
+* add the extra fun
+
+There will of course always be a pattern to how you create and add similar structures for other categories, actions and entities.
+
+But the point here is to show that it doesn't take *that much* to have some advantage of *plausible deniability*: Even faced with the `5 Dollar Wrench Problem`_, if you are able to hold your ground, there is no feasible way to prove that you *don't own something*. Bite the bullet, absorb the pain, deny ownership, and you'll be fine.
+
+
+Perils and pitfalls
+===================
+
+None of this is in no way safe by itself.
+
+Some concerns are named below. Surely there are others, too.
+
+
+Out of sight, but still mined
+-----------------------------
+
+You may find it a pain in the ass to type the passphrase for the key salt every time.
+
+An obvious workaround for that is to store the passphrase in a file.
+
+But keep in mind that, if you do that, the key obfuscation is going to be less safe than your regular passwords storage.
+
+That is to say: If the attacker can read your passwords ciphertext, most likely the attacked can read you obfuscation passphrase, too.
+
+
+Out of mind, out of luck
+------------------------
+
+Maybe the most important thing to realize in this solution is that there is no way to recall the original keys from the file names under which the values are stored.
+
+Instead, the idea is that you decide on a naming scheme for certain crucial values you want to store, and *remember* how to reconstruct them. [2]_
+
+
+Shell shill
+-----------
+
+The code above has been adapted from a ``bash`` tool I've already written for the purpose, given the name Clortho_.
+
+Shell script is surely a very poor choice for this kind of thing, but at the time I simply wanted to write shell so that's how it ended up.
+
+I probably will rewrite it for another environment at some point.
+
+But for now it illustrates the point.
+
+
+..
+
+ .. [1] I use a different email for each service I sign up to, and for every other context I have to leave my email for something. I highly recommend this practice, aswell as running your own mail server. `It really isn't that hard <https://www.linuxbabe.com/mail-server/setup-basic-postfix-mail-sever-ubuntu>`_.
+
+
+..
+
+ .. [2] I'm not going to lie: That kind of thing takes practice. As in, you need to remind yourself from time to time what your scheme is. Perhaps that is an unthinkable proposition in the age of the Smartphone and the illusion of auxiliary instant truths. But I come from a time where I knew all numbers and addresses I needed to know by heart. The more you do it, the more you remember. The less you do it, the more you are dependent on others. What others do you depend on? And so on it goes...
+
+.. _pass: https://www.passwordstore.org/
+
+.. _ccrypt: https://ccrypt.sourceforge.net/
+
+.. _Clortho: https://holbrook.no/src/clortho
+
+.. _5 Dollar Wrench Problem: https://xkcd.com/538/
+
+.. _Ethereum addresses: https://kobl.one/blog/create-full-ethereum-keypair-and-address/
