Chelovek & RuneCaster
RuneCaster
Ever thought about how those old rune symbols might hide themselves in modern encryption? I’ve been tracing patterns between the two, and I think there’s a neat logic that could solve both a linguistic puzzle and a code‑breaking problem. What do you think?
Chelovek
Sounds intriguing, but I’ll need a concrete mapping and some test data to see if the logic holds. If you can formalize the pattern and show it works on several examples, we can evaluate its practical value.
RuneCaster
Here’s a quick prototype I’m running on a handful of Elder Futhark symbols.
The idea is to treat each rune as a binary bit‑string derived from its left‑to‑right axis count, then map that string to an ASCII character.
1. Count the number of vertical strokes (1) versus diagonal strokes (0) in the rune’s standard diagram.
2. Convert the tally to a 5‑bit binary number.
3. Translate that binary to decimal and then to the corresponding ASCII character (A=65, a=97, etc.).
Example mapping:
-ᚠ (Fehu) has 2 vertical, 3 diagonal → 01001 → 9 → TAB (control) → we map it to ‘F’ manually for clarity.
-ᚢ (Uruz) has 1 vertical, 4 diagonal → 00100 → 4 → EOT → map to ‘U’.
-ᚦ (Thurisaz) has 3 vertical, 2 diagonal → 01110 → 14 → SO → map to ‘Þ’.
-ᚨ (Ansuz) has 0 vertical, 5 diagonal → 00001 → 1 → SOH → map to ‘A’.
When I feed the string “Fehu Uruz Thurisaz Ansuz” into the system, the decoded message comes out as “FUTU”. I’ve tested a batch of 12 runes, all producing valid ASCII characters when I apply a small lookup table for control codes.
If you want a more robust test, let me know which rune set you want to run through, and I’ll generate a spreadsheet of the binary patterns and their ASCII equivalents.
Chelovek
Interesting approach, but the mapping seems a bit arbitrary. The conversion from stroke counts to 5‑bit numbers works only if every rune ends up in the 0–31 range, and you’re then forcing control characters into printable letters. If you want a real cipher, the key step is to define a deterministic, reversible mapping that covers the full ASCII range without needing a manual lookup. For a quick test, try a few more runes—make sure the vertical‑diagonal counts don’t overlap in a way that creates the same binary string for different symbols. That will show whether the system is actually discriminating between them. If you supply a spreadsheet, I can check the consistency and suggest a better scheme.
RuneCaster
Here’s a quick sheet for ten runes, with stroke counts, binary, decimal, and the ASCII char we get if we simply map 0‑31 to printable space‑to‑unit controls. I’ve checked for duplicates: each rune has a unique binary string.
| Rune | V | D | Binary | Dec | Raw ASCII |
|-----|---|---|--------|-----|-----------|
| ᚠ Fehu | 2 | 3 | 01001 | 9 | TAB |
| ᚢ Uruz | 1 | 4 | 00100 | 4 | EOT |
| ᚦ Thurisaz | 3 | 2 | 01110 | 14 | SO |
| ᚨ Ansuz | 0 | 5 | 00001 | 1 | SOH |
| ᚩ Raido | 1 | 4 | 00101 | 5 | ENQ |
| ᚫ Kenaz | 2 | 3 | 01010 | 10 | LF |
| ᚬ Gebo | 3 | 2 | 01111 | 15 | SI |
| ᚭ Wunjo | 2 | 3 | 01011 | 11 | VT |
| ᚮ Hagalaz | 1 | 4 | 00110 | 6 | ACK |
| ᚱ Raido2 | 2 | 3 | 01000 | 8 | BS |
Notice the pattern: V=vertical, D=diagonal. I’ve kept the mapping to raw ASCII because that’s what the math gives you; if you need printable letters you’ll need a second lookup table, but at least every rune lands on a distinct 5‑bit value. Feel free to swap the V/D counts if you want to avoid control chars or push into the printable range.
Chelovek
Looks solid from a uniqueness standpoint, but the raw output still lands in the control range. If you want printable characters without a secondary table, consider shifting the binary values up by 32 or redefining the stroke counts so the resulting decimals fall into the 32–126 printable range. That way you keep the one‑to‑one mapping and avoid the need for a lookup step.
RuneCaster
Sure thing, let’s just bump every decimal up by 32 and you’ll be in the printable zone. That turns the 9 from Fehu into 41, which is ‘A’, the 4 from Uruz into 36, ‘&’, and so on. If you want to keep the stroke logic more natural, we could re‑weight the diagonal strokes to give each rune a distinct 5‑bit code that already falls between 32 and 126—like making 0 vertical, 5 diagonal count as 32 instead of 1, and adjusting the others by a constant offset. Either way you’ll get a one‑to‑one cipher without the lookup step. What do you think?
Chelovek
Bumping each value by 32 is the simplest fix; it guarantees printable output and keeps the mapping linear. The only downside is that the resulting characters are not alphabetic or easily readable. If you want the cipher to produce meaningful letters, you’ll need to adjust the stroke weights so the base 5‑bit numbers fall within 32–122 and then map them to A–Z or a–z as needed. For pure data‑hiding, the 32‑shift is fine and easy to implement. It also preserves the uniqueness and the one‑to‑one nature of the mapping. If you’re okay with the mixed‑case output, go ahead. If you need legible text, tweak the counts so the raw decimals already lie in the printable range.
RuneCaster
I’ll just slide every result up by 32 and call it a day – the cipher stays linear, uniqueness is intact, and you can paste it straight into a log file. If you need a readable motto, I can tweak the stroke weights so the base bits land in the 32‑122 range and then apply an A‑Z mapping. Otherwise, the mixed‑case output is as cryptic as any ancient sigil. Which path do you want?