Alberich Handbook – Enigma M4, Modern V3 & Courier

Manual version: 4 September 2026 · Alberich Modern V3 · V3 hardened

Welcome. This handbook explains the historical Enigma M4 simulation and Alberich’s modern Modern V3 encryption system — honestly, in two languages, offline.

Alberich runs in the browser, as an Android app (Play Store or the author’s F-Droid repo), and as a companion for Chrome, Edge, Firefox and Thunderbird. No account, no ads, no tracking.

1. What is Alberich?

Alberich is a browser-based rotor encryption application built around two distinct worlds: a historically oriented simulation of the Enigma M4 and Alberich’s modern Modern V3 encryption system. The classic mode recreates the operating principle of the Enigma M4 for historical, technical and experimental use. Modern V3 develops the rotor concept further and combines it with Base-26 encoding, automatic message keys, key sheets, nets and Courier mode. Processing is performed locally in the browser. Plaintext and key material are designed to remain on the device.

Modern V3 is Alberich’s recommended everyday mode. It is an openly specified experimental rotor protocol that evolves the historical Enigma concept for modern use. It is not a replacement for widely reviewed modern AEAD cryptography. Alberich deliberately focuses on a different architecture: transparent rotor cryptography, local key management and optional physical separation between cryptography and communication.

Why Alberich?

• Local, not cloud: encryption and key management run on the device.
• No sign-up: no Alberich account.
• No telemetry: Alberich does not need usage analytics.
• No cloud keys: day keys stay under the users’ control. There is no central key server.
• Open and inspectable: specification, source code and self-tests make the design checkable.
• Courier-ready: plaintext and day keys can stay entirely on a separate offline device.

Three paths to keep distinct from the start:

• Traditional Historical Enigma M4 simulation — learning and experiment mode.
• Modern V3 Recommended Alberich everyday mode; sheet type V3 hardened for shorter key periods.
• Courier Optional air-gap workflow: keep cryptography physically separate from communication.

Courier mode

Keep plaintext off the messenger device

Plaintext stays offline. In Courier mode, the offline device performs the cryptography. The online device transports Alberich ciphertext only. Plaintext and day keys therefore do not have to be entrusted to the messaging device. Client-side scanning on the communications device therefore sees only ciphertext.

That is the architectural answer to client-side scanning debates: not another algorithm on the same phone, but splitting compute from transport. Procedure in chapter 6.

1.1 Getting Android

Two official channels, the same app (currently 1.0, revision 31):

• Google Play — shortest path. Updates through the store.
• The author’s F-Droid repo — signed APKs on alberich.pro, updates through the F-Droid client. This is not f-droid.org. Android source is not the public GitHub repo.

Landing page, QR and fingerprint: alberich.pro/fdroid. Repo address: https://alberich.pro/fdroid/repo. Fingerprint (SHA-256): 5D0B21FEEA5FE33D702AE4FDB8A556108C9BE1993A031A413B24C7C399EDC4C3.

Without the F-Droid client you can use Obtainium with the same address and fingerprint. A raw APK is the third path — unknown sources, no automatic updates unless you then add the repo.

2. Quick start

Traditional

Historical M4 following Kriegsmarine operating practice: rotor order and daily key from the sheet, a message key per message, A–Z capitals only. Period becomes X, comma Y, question mark UD. Encrypt and decrypt are the same operation.

1. Select main mode Traditional.
2. Set rotors, rings, plugboard and ground setting — as on a historical key sheet.
3. Type A–Z. The same setting decrypts again.
4. Optional procedure Message key: Alberich can generate the four-letter message key instead of choosing it by hand.

To recreate original M4 traffic, follow the historical regulations (key sheet, kenngroups, message key). Alberich removes the paperwork; in Traditional mode it does not change the machine’s electrical behaviour.

Modern V3 recommended

1. The top bar must show Modern.
2. Load a sheet: recommended V3 hardened (time slots) or V3 · daily key (JSON / QR / manual). At least three plug pairs.
3. Type plaintext → copy the ALBV message (including the check group).
4. Receiver: paste the complete message — from ALBV through the last group. Output is the plaintext.

Before the first message, make sure sender and receiver use the same sheet. For a daily-key sheet the sheet word (seven letters) is enough; for V3 hardened compare month and fingerprint. Both are plausibility checks, not identity proofs.

3. Step by step for new users

1. Open the app. Web: alberich.pro, or the Android app via Play or F-Droid, or a companion. There is no key server; a local copy is enough.
   Open Alberich in the browser Alberich on Google Play Alberich via F-Droid Alberich Companion for Chrome Alberich Companion for Edge Alberich Companion for Firefox Alberich Mail Companion
2. Pick a language. DE | EN in the header. The choice is stored.
3. Turn Modern on. The top bar must say “Modern”, not Traditional. The two modes are incompatible because they use different algorithms — do not mix them on the sender and receiver side. Note: the Alberich Companion is deliberately slim for the browser and the mail client. It only has Modern mode, not Traditional. Traditional lives in the web app and the Android app.
4. First code sheet. Open setup. For everyday use generate V3 hardened (default 4 hours). Alternatively keep V3 · daily key as a monthly sheet. The bundled demo sheet (sheet word CPTZ YYH) is a public daily key and not secure. It is only for trying this handbook — not for your own messages.
5. Compare the sheet. Daily key: seven letters, shown as XXXX XXX, a CRC-32 sheet word. V3 hardened: month and fingerprint. Both are short, non-secret comparison values — a practical everyday check, not a signature. For sensitive groups, verify the match through an independent channel whenever practical.
6. Encrypt a first message. Input type “Plaintext”, type the text. Output in groups of four. Per message Alberich generates a new message key and message ID — not on every keystroke.
7. Message layout. ALBV | header | message ID | body | check group. Without the complete message there is no plaintext. Groups of four are display only.
8. Decrypt. Input type “Ciphertext”, paste the complete message. The check group is verified first.
9. Optional: courier. A second device that stays offline. Details in chapter 6.

4. The two main modes in detail

4.1 Traditional mode

Historical M4: rotors I–VIII, Greek rotor Beta or Gamma, reflector Bruno/Caesar (Dora as an option). You set four start positions (Greek rotor plus left, middle and right). The Greek rotor sits in the electrical path but does not step during encipherment — historically and in Alberich Traditional. That is separate from the ring setting: it applies to all four rotors, including the Greek rotor — as on the historical M4. The Greek rotor does not step during encipherment; ring and start position are still two different settings and both take effect. Older Alberich Traditional traffic whose first ring letter was not A decrypts differently after this correction.

• Involutory: the same setting decrypts again. A letter never enciphers to itself.
• A–Z only. Spaces stay visible in the input but are not machine steps. Period → X, comma → Y, ? → UD.
• Stepping: classic double-stepping. The right rotor advances one position on every keypress. If it sits on a notch, it takes the middle rotor with it. In so-called double-stepping the middle rotor can advance on two consecutive keypresses because of the notch logic, taking the left rotor with it. The left rotor’s notch has no effect. The Greek rotor stands still.

Simple and message-key procedures

Simple uses one start position for the whole text — good for trying the machine.

Message key follows the historical regulation: the daily key supplies the ground setting; each message gets four extra letters as the message key. That becomes the header; the body runs under the message key. Historically you had to choose and transmit that key according to kenngroup rules.

Automatic message key: Alberich can generate the four letters. That removes the paperwork; it does not change the machine. For everyday Traditional use this is the convenient path; for historically faithful drills, still pick the message key yourself.

Use: learning, historical simulation, classic drills. Not the recommended everyday path.

4.2 Modern V3 (current standard)

Modern V3 is Alberich’s recommended everyday mode. It is an openly specified experimental rotor protocol that evolves the historical Enigma concept for modern use. The rotors follow a four-stage double-step: the right rotor always moves; notches on the right, middle and left rotors take the slower ones with them — including the Greek rotor. The written step rule and the Python reference in the public repository describe the same machine the app runs. Self-tests check that browser, app and reference agree.

• End rotor (E) instead of reflector (UKW). The signal path is not reversed. Encrypt and decrypt are therefore different paths. Alberich handles that for you: you only choose “Plaintext” or “Ciphertext”; the inverted end rotor stays behind the scenes.
• Truly random filler notches with counts from {5, 7, 9} sit on the sheet, independent of rings and plugs.
• Base-26: any text (umlauts, numbers, emoji) is mapped internally to A–Z so the rotor machine stays on letters. You do not re-encode anything.
• Greek rotor steps: unlike Traditional mode it no longer stands still. When the left rotor sits on a notch, the Greek rotor moves too. Its ring setting applies.
• Message layout: every Modern message starts with the stamp ALBV, carries header, message ID and body, and ends with a check group. The check group rejects changes before any plaintext appears.
• Automatic message key of four letters — the start positions of all four rotors, including the Greek rotor.
• Two sheet types: V3 · daily key (one key per calendar day) and V3 hardened (an independent full key per time slot). The telegram remains ALBV. Details in chapter 5.

Fixed points on the end rotor: a letter may map to itself (A → A). That is allowed for a free permutation and impossible on the historical UKW.

Involutions are discarded: an involution is a pairing (like the UKW). Alberich does not emit such end rotors. If random generation still produces an involution, it is thrown away and generated again — so Modern V3 does not accidentally become self-inverse.

5. Code sheets, codebooks & networks

Modern V3 has two sheet types. Both produce normal ALBV messages. The cipher core does not change. Sender and receiver need the same type and the same sheet.

• V3 · daily key: one full V3 key per calendar day. Share as JSON, still QR (ALBERICH-CBQR1) or text.
• V3 hardened: one full, independent V3 key per time slot. Share as a binary file .alb3cb2; in the web app also as a live QR (CBQR2). JSON and still QR cannot carry a hardened sheet.

Traditional stays on the classic monthly key sheet. The companion (Chrome, Edge, Firefox, Thunderbird) has daily keys only — no hardened sheet generator.

5.1 V3 · daily key

• Generate: create a monthly sheet at random in setup.
• Sheet word: a short, non-secret comparison value based on CRC-32 (shown as XXXX XXX). It helps detect accidental differences between sheets — a practical everyday check. It is not a signature or cryptographic authentication; CRC-32 collisions are possible. For sensitive groups, verify the match through an independent channel whenever practical.
• Networks: the historical term for different groups — family, friends, colleagues. Up to five named networks, one sheet each. Nobody in another group can read along; the split raises security. “Remove sheet” clears only the active network. Re-importing or deleting a sheet does not reset the local message-key register.
• Import/export: JSON, QR (ALBERICH-CBQR1), text, optional NFC. Sheet QR and courier QR are separate.

The demo sheet (sheet word CPTZ YYH) is public. It is for demonstration only and must not be used for personal messages with sensitive content. Day 16 of that sheet is the documented test day for the example messages in the appendix.

5.2 V3 hardened

V3 hardened has shipped (web 1.0 revision 65, Android 1.0 revision 31). It is Modern V3 with an automatically changing full key: end rotor and filler notches sit on the sheet, telegram ALBV. The clock selects the period; it does not derive the key.

• Key validity: 24 hours · Simple, 4 hours · Recommended (default), 1 hour · Higher protection. Everyone on a network must use the same sheet and the same profile.
• Alberich key time: CET (UTC+1) all year, no daylight saving, regardless of the device time zone.
• 24 hours · Simple uses the same daily cadence as the daily key, but live QR or file and CET instead of JSON or a still QR. Less traffic under one key: 4 hours.
• Pin over clock: a message already started stays on its time slot. New messages use the key that is current then.
• Receive: the check group finds the matching slot itself (MAC-first). Do not pick a time slot.
• Compare: hardened sheets show month and fingerprint, not the legacy sheet word.
• Transfer: web via live QR (CBQR2, animated) or binary file .alb3cb2. Android via file .alb3cb2 — no MUR live QR. JSON and still QR remain for daily keys only.

6. Courier mode

Plaintext stays offline. In Courier mode, the offline device performs the cryptography. The online device transports Alberich ciphertext only. Plaintext and day keys therefore do not have to be entrusted to the messaging device. Alberich shows the finished ciphertext as a QR code; the online device scans it and sends it on the channel you already use. The receiver mirrors this: ciphertext from the messenger → QR → offline device decrypts.

Courier splits computing from transport. Encrypt and decrypt stay on a second device that remains offline (courier off, airplane mode). The everyday device (courier on) only ever sees the finished ciphertext.

Why this helps against client-side scanning (Chat Control 2.0): those schemes target the communications device. If plaintext and the daily key never live there, a scan sees only ciphertext. Courier does not change the cipher. It changes where the cipher runs.

+---------------------------+                     +---------------------------+
| OFFLINE                   |                     | ONLINE                    |
|                           |      AIR GAP        |                           |
| [plaintext]               |                     |              [messenger]  |
|      |                    |                     |                    ^      |
|      v                    |                     |                    |      |
| Alberich encrypts         |  QR / ALBERICH-     |                    |      |
|      |                    |  CTQR1  ----------> |                    |      |
|      v                    |                     |                    v      |
| [ciphertext]              |                     |      [ciphertext only]    |
+---------------------------+                     +---------------------------+

• One courier QR holds at most 955 ciphertext letters. Ignore the length warning if you are not using courier.
• A sheet QR does not import keys into courier mode.
• Default after first start: courier off. Turning it on asks for confirmation.

7. The cryptographic heart

7.1 Traditional path (historical M4)

plaintext
   |
   v
Plugboard → Right rotor → Middle rotor → Left rotor → Greek rotor
                                                                  |
                                                                 UKW
                                                                  |
Plugboard ← Right rotor ← Middle rotor ← Left rotor ← Greek rotor
   |
   v
ciphertext

Involution: the UKW pairs letters. The whole path is therefore self-inverse: the same keying returns the plaintext. A letter never enciphers to itself — the classic crib that helped break the cipher.

Classic stepping: the right rotor always moves. On a notch it takes the middle rotor. In double-stepping the middle rotor can advance on two consecutive keypresses because of the notch logic, taking the left rotor with it. The left rotor’s notch has no effect. The Greek rotor stands still.

Rotor wirings (I–VIII, Beta, Gamma, UKW Bruno/Caesar) are historical and do not change.

7.2 Modern V3 — signal path and machine

plaintext
   |
   v
Plugboard → Right rotor → Middle rotor → Left rotor → Greek rotor → End rotor
                                                                          |
                                                                          v
                                                                     ciphertext

On decrypt Alberich uses the same step sequence and the inverse end rotor. You do not set that; the app switches the path when the input is ciphertext.

The end rotor is a free 26-letter permutation, not involutory. Bruno, Caesar and Dora are not the Modern default.

Greek-rotor start and ring. The ground setting is four letters — the visible start of all four rotors, including the Greek rotor. That is true in Traditional and in Modern. During encipherment the Greek rotor does not step in Traditional. The ring setting of the Greek rotor is something else: it applies in Traditional as on the historical M4 and in Modern V3. It shifts which wiring is active at which visible position. That the Greek rotor does not step in Traditional does not change that. In Modern the ground setting encrypts the message-key header and belongs to the canonical day key of the check group. A wrong ground setting fails the check group; no plaintext appears.

7.3 V3 stepping

Notches are read before the rotors move. Modern V3 uses four-stage double-step. In so-called double-stepping the middle rotor can advance on two consecutive keypresses because of the notch logic:

  Greek rotor    Left rotor    Middle rotor    Right rotor
        ^              ^              ^                *
        |              |              |                |
        +------ double-step ------+                    |
                       |              +---- on notch --+
                       +---- on middle notch ----------+

7.4 Base-26 encoding

The rotor machine knows A–Z only. The UTF-8 message is therefore turned into one large integer and then written in base 26 as the letter body:

n ← 0
for each byte b:  n ← n × 256 + b
then n as A–Z digits (base 26)

The letter count of the body determines the original byte length uniquely. An empty message stays empty. Invalid lengths or non-UTF-8 are rejected.

Another character changes the whole integer (times 256 plus the new byte). That is why the ciphertext body looks mixed while you type — a consequence of the encoding, not a claim of cryptographic avalanche. Recommended maximum everyday length: 4,096 characters.

7.5 Message layout and check group

A Modern message is A–Z only. Groups of four are display. Minimum length 36 letters. The stamp ALBV means: this is a Modern V3 message.

ALBV | header (4) | message ID (8) | body | check group (20)

The header carries the message key: four rotor positions including the Greek rotor, encrypted under the day’s ground setting. The message ID is eight random letters, not a rotor position. It sits in the clear in the message and is bound into the check group. The message ID allows Alberich to detect messages already seen by the local replay cache. This protection remains local and requires no cloud state. Detection applies in the current session (up to 512 entries) and is not necessarily persistent across restarts or devices. The body is the Base-26 plaintext through the machine, running under the message key.

The check group lets Alberich reject tampering or the wrong key before any plaintext is released. Technically: HKDF-SHA-256 derives an authentication key from the canonical day key (salt ALBERICH-ALB3-AUTH, info pruefgruppe-v1); HMAC-SHA-256 is computed with that key; the first 12 bytes become 20 Base-26 letters (about 94 bits of tag space). The check group strengthens integrity and authenticity checking; it does not add to the nominal confidentiality keyspace. If it does not match, no plaintext appears.

The check group is computed from a canonical write-up of the daily key. That write-up includes a network label. Alberich uses the fixed abbreviation ALB here — not the internal number each device assigns to a network locally. Sender and receiver would not share that local number; the check group would fail even though both have the same sheet.

Canonical daily key of the documented test day (demo sheet, 16 August 2026):

ALB3-KEY
net:ALB
epoch:2026-08-16
rotors:Beta,V,VI,VIII
rings:EPEL
ground:CDSZ
plugs:AE BF CM DQ HU JN LX PR SZ VW
end:QWERTYUIOPASDFGHJKLZXCVBNM
notches:AFLRX|BEIMQUY|CDHKNPSVZ

7.6 Keyspace and security claims

The figures below apply only to the Modern V3 standard profile (four rotors by the selection rules, ten plug pairs with no repeated letters, a free non-involutory end rotor, three filler sets from {5,7,9}, randomness from the device cryptography interface — a CSPRNG, a cryptographically secure random generator). Hand-set rotors or plugs do not inherit these counts.

What “layer” means here. These are not five ciphers stacked on top of each other, but five views of the same system — the public research count, so combinatorics is never sold as attack cost.

• A Support — how many standard sheets can exist at all (pure combinatorics).
• B Shannon — how evenly the generator spreads over that space (actual entropy).
• C Min-entropy — the least favourable, i.e. most likely, generator output.
• D Equivalent-key — whether any settings would do nothing electrically (dead fields).
• E Best demonstrated attack — what has actually been measured, not what the bit count promises.

What Alberich deliberately does not solve. Forward secrecy in the classical sense (as in Signal): there, new key material is agreed after each message. Stealing today’s key still does not read yesterday. With V3 · daily key the key lasts the whole day; with V3 hardened it lasts the time slot (24, 4 or 1 hour). Whoever has the sheet reads every message of that epoch. Other epochs with another key stay untouched; that is not ratchet forward secrecy.

Anonymity: Alberich does not hide who talks to whom. The messenger still sees sender, receiver and time. Metadata, a stolen sheet and a compromised offline device sit outside the cipher.

8. Security, threat model & good practice

The table describes typical situations, not a ranking of the cipher. Left the situation, middle what Alberich does, right what you still handle operationally.

What Alberich offers — and what it does not claim

Transparency is a feature, not a weakness.

Good practice

• Compare the sheet word (daily key) or month and fingerprint (V3 hardened) on a different path from the messages. Do not photograph the sheet or put it in the cloud.
• Change rotors and keys only when the text fields are empty. Check the mode at the top.
• Do not mix Traditional and Modern: different algorithms, incompatible.
• Use courier if the online device is untrusted. Never take the offline device “briefly online”.
• Emergency wipe if the device or sheet is lost, then a new sheet to your partners.

Chat Control 2.0 / client-side scanning: courier helps against scans on the messenger device, because neither plaintext nor sheet live there. It does not help against metadata, the offline device, an unsafely shared or published sheet, or a forged website.

The internal cryptanalysis of Modern V3 — attacks, limits and the public evidence snapshot — is in chapter 9 Lab.

9. Lab: We attacked Modern V3

How secure is Alberich Modern V3 in practice? Instead of assuming that a large keyspace must be enough, the lab tried to take the system apart systematically: intercepted messages, known plaintext, very long messages, many messages under the same key, reused message keys, partial knowledge of key components, state and cycle analysis, and targeted attacks on the rotor structure.

Without being given parts of the day key in advance, our extensive internal cryptanalysis did not practically recover the complete Modern V3 day key.

That is a strong result — but it is not a proof of security. The research also found concrete protocol weaknesses and operational risks. That is exactly why the lab exists: not to claim perfect security, but to expose weaknesses before someone else does.

In short: Modern V3 after the cryptanalysis campaign

Four numbers that capture the closure

These numbers are not “security bits”. They describe concrete experiments under explicitly defined conditions.

What did we attack?

The internal campaign went far beyond simple brute force. It covered several distinct attack models.

What does this mean for regular Alberich users?

1. The day key remains the real secret. If someone gets the code sheet, they have the key. No rotor mechanism can save a published or stolen sheet. The day key in the codebook should always be treated and protected as one complete unit, not as a collection of independent parameters. Do not distribute the sheet over the same channel as the messages if you can avoid it.
2. Do not reuse message keys. When the previous message is removed with the delete button and a new message is then written, Alberich automatically generates a new random message key. Do not manually copy or reuse a message key that has already been used.
3. Fewer messages per long-lived key are better. This does not make the rotor cipher mathematically “stronger”. It reduces how much material an attacker can collect under the same shared configuration. That is what V3 hardened is for: shorter epochs (4 hours recommended) instead of a rigid 24-hour key. See chapter 5.2.
4. Sensitive or very large content can use a fresh key. A session or one-shot key — a fresh independent V3 configuration for one session, one document or even one message — is recommended, but not shipped yet. Until then, generate a new hardened sheet or pick the shorter profile (1 hour).
5. Courier solves a different part of the problem. Cryptanalysis asks how strong the cipher is. Courier asks where plaintext and keys exist at all. If the messaging device never holds plaintext or the day key, it cannot hand them to an app, a server or a local scanner. This does not replace cipher strength, but it reduces endpoint exposure. See chapter 6.

What has changed — and what is still planned?

Public cryptanalysis evidence on GitHub

The public snapshot is not a security certificate and not proof that Alberich is “unbreakable.” It is also not the complete internal Laboratory and contains no private truth data. Its purpose is transparency: readers should be able to see which attacks were actually performed, what they found, and which evidence supports our current assessment of Modern V3.

If you do not want to take our conclusions on trust, you can inspect the published evidence yourself.

Frequently asked questions about the lab

10. FAQ & troubleshooting

11. Glossary

ALBV

Visible stamp of a Modern V3 message. Applies to daily keys and V3 hardened.

Alberich key time

CET (UTC+1) all year, no daylight saving. Selects the time slot for V3 hardened, regardless of the device time zone.

Base-26

Mapping any text onto A–Z as one large integer so the rotor machine stays on letters.

Double-step

A rotor takes the next one with it when it sits on a notch — historical behaviour, extended to four rotors in Modern V3.

End rotor (E)

Free 26-letter permutation instead of a reflector. Not involutory. Fixed points allowed.

Greek rotor

Beta or Gamma. Four start positions like the other rotors. In Traditional it does not step; the ring applies. In Modern V3 it steps and the ring applies.

Ground setting

Four-letter start from the daily key. Encrypts the message-key header.

Involution

A map equal to its inverse. Historical Enigma; not Modern V3.

Short-period class

A precisely defined five-start class with an unusually short internal state period. In the lab it became exploitable only with extremely long known plaintext (16,384 characters). Automatic rejection during generation is not shipped yet (laboratory).

Courier

Physical split: compute offline, online only ciphertext via QR ALBERICH-CTQR1.

Filler notches (“Lückenfüller”)

Key-dependent turnover notches on the right, middle and left rotors. Historically each rotor had one or two fixed notches. Modern V3 puts 5, 7 or 9 notches per rotor from the daily key — visible on the sheet, independent of rings and plugs. The Greek rotor has no notches. These notches remove the fixed historical pattern and make a direct transfer of classic Enigma period and notch attacks significantly more difficult. The behaviour is openly documented and can be analysed independently.

Message ID

Eight random letters, not a rotor position. Bound into the check group and used by the local, session-scoped replay cache — no cloud state.

No-gift

Attacker model without gifted secret key components. The attacker works only with what the model allows — for example public telegrams, or known plaintext in a known-plaintext attack.

Emergency wipe

Deletes every sheet in this browser or app.

Check group

20-letter authentication group at the end of the message (HKDF, then HMAC-SHA-256). Verified first; no plaintext without a valid group.

Message key

Four-letter rotor start per message. Modern: automatic; Traditional: manual or generated.

Sheet word

A short, non-secret CRC-32 comparison value for the daily-key monthly sheet (shown as XXXX XXX). Everyday plausibility check, not a signature. Hardened sheets use month and fingerprint instead.

UKW

Historical reflector (Bruno, Caesar, Dora).

V3 hardened

Shipped sheet type: an independent full key per time slot (24 / 4 / 1 hour). Cipher core unchanged. Transfer via .alb3cb2 (web also live QR).

Time slot

Validity window of a full key in V3 hardened. The clock selects the slot; it does not derive the key.

Filler notches — picture

Gold marks the notches. The remaining letters are the “gaps” — hence the name. When a rotor sits on a gold position, it takes the next one with it. Key-dependent turnover notches remove the fixed historical pattern and make a direct transfer of classic Enigma period and notch attacks significantly more difficult.

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
  ■       ■       ■       ■       ■       ■       ■
  7 notches, count from {5, 7, 9}, positions random

Appendix

Example message (test vector)

Plaintext Hello, demo sheet day 16 (sheet word CPTZ YYH), message key LDNQ, message ID TESTMSGX. For checking only — not for everyday use.

ALBV KCBD TEST MSGX XWSW IYDB UEFR KEQM ITQR COGP DSZA L

Ungrouped (the app accepts this too):

ALBVKCBDTESTMSGXXWSWIYDBUEFRKEQMITQRCOGPDSZAL

To test: import the demo JSON, pick day 16, paste the full message as ciphertext. Expected output: Hello.

Second vector, UTF-8: plaintext Guten Tag! Äpfel 🔐

ALBVKCBDTESTMSGXXYEOWAEKZVYWNKGNQGALJWTDDGVPGDVBKCQNOSYVWGYPSDFCYZLSRHZAVJ

Links

• Live app: alberich.pro
• Android: alberich.pro/fdroid
• Blog: alberich.pro/blog
• GitHub: MyEngineeringTools/alberich
• Modern V3 cryptanalysis & evidence: alberich-v3-cryptanalysis-evidence
• Crypto spec: docs/crypto-spec/modern-v3.md
• Threat model: docs/threat-model.md

Versions

• Handbook date: 4 September 2026
• Recommended web app: 1.0 (Revision 65)
• Android: 1.0 (Revision 31)
• Browser companion: 1.0.24 · Thunderbird: 1.0.16