“哈基米咯南北绿豆阿西噶哈呀库那路～”
Version: 0.2
Status: Experimental Standard
Author: RFC Hajimi Standard Committee
Date: January 3 2026
RFC Hajimi (Request for Comments: Hajimi) defines a robust, character-based encoding and cryptographic framework. It transforms arbitrary binary data into a unique 16-character alphabet derived from cultural phonetic symbols. Beyond simple encoding, this standard specifies a multi-tier security architecture including symmetric XOR obfuscation, GPG-style asymmetric encryption, and Ed25519-based digital signatures.
哈基密标准（RFC-HJM）定义了一种稳健的基于字符的编码和加密框架。它将任意二进制数据转换为一种独特的由文化音素符号导出的 16 字符字母表。超过简单的编码，此标准指定了包括对称 XOR 混淆、GPG 风格的非对称加密和基于 Ed25519 的数字签名在内的多层安全架构。
The goal of RFC Hajimi is to provide a standardized, character-based method for data handling while maintaining the mathematical rigor of modern cryptography.
哈基密标准（RFC-HJM）的目标是提供一种标准化的、基于字符的数据处理方法，同时保持现代密码学的数学严谨性。
- HJM-16 (十六基米表): The core 16-character alphabet.
- Nibble: A 4-bit unit of data (half a byte).
- HJM-Enc (哈基米编码): The process of converting binary data to Hajimi characters.
- HJM-Sign (哈基米签名): The process of generating an Ed25519 signature in Hajimi format.
- HJM-Verify (哈/哈气): The process of verifying a signature's authenticity.
- Public Key (公基): The publicly distributable key in Hajimi format.
- Private Key (私基): The sensitive, non-distributable key in Hajimi format.
- Identity (基份): A structured token containing a user's metadata (Name, Email) and their Public Key (公基).
- Obfuscation Key (混淆密钥): A 8-bit key used for symmetric XOR operations.
- Symmetric Hajimi (对称基米): The data format after standard HJM-16 encoding and optional symmetric XOR obfuscation.
- Asymmetric Hajimi (非对称基米): The data format representing results of asymmetric operations (RSA, Ed25519, X25519), including encrypted payloads and digital signatures.
The alphabet consists of 16 specific Unicode characters. Each character corresponds to a hexadecimal value from 0x0 to 0xF.
| Hex | Character | Meaning/Phonetic | Hex | Character | Meaning/Phonetic |
|---|---|---|---|---|---|
| 0x0 | 哈 | Ha | 0x8 | 阿 | A |
| 0x1 | 基 | Ji | 0x9 | 西 | Xi |
| 0x2 | 米 | Mi | 0xA | 噶 | Ga |
| 0x3 | 咯 | Lo | 0xB | 呀 | Ya |
| 0x4 | 南 | Nan | 0xC | 库 | Ku |
| 0x5 | 北 | Bei | 0xD | 那 | Na |
| 0x6 | 绿 | Lv | 0xE | 路 | Lu |
| 0x7 | 豆 | Dou | 0xF | ～ | (Wave/End) |
- Decomposition: Take the input byte stream. For each byte, split it into two 4-bit nibbles.
- Order: The Most Significant Nibble (MSN) is processed first, followed by the Least Significant Nibble (LSN).
- Mapping: Look up each nibble in the HJM-16 table and append the character to the output string.
- Validation: Ensure the input string consists only of valid HJM-16 characters and has an even length.
- Reverse Mapping: Convert each character back to its 4-bit value.
- Recomposition: Combine two 4-bit values (High << 4 | Low) to reconstruct the original byte.
Provides a basic layer of privacy by XORing each input byte with an 8-bit key before encoding.
secret_byte = original_byte ^ (key % 256)
Designed for secure messaging between two parties.
- Public Key: (n, e) - Used by the sender to encrypt.
- Private Key: (n, d) - Used by the receiver to decrypt.
- Standard: RFC Hajimi uses a simplified RSA implementation where session data is serialized and then HJM-16 encoded.
The highest tier of the standard, providing non-repudiation and integrity via the Ed25519 signature algorithm.
-
Curve: Edwards25519 (
$x^2 + y^2 = 1 + d x^2 y^2$ over$\mathbb{F}_{2^{255}-19}$ ). - Signature Length: 64 bytes (128 Hajimi characters).
- Public Key Length: 32 bytes (64 Hajimi characters).
The official reference implementation is provided via the RFCHajimi module.
To launch a Julia environment with the official standard pre-loaded:
julia --project="." -i -e 'include("src/RFCHajimi.jl"); using .RFCHajimi'If you are integrating RFC Hajimi into a larger Julia project:
- Activate Project:
using Pkg Pkg.activate("/path/to/rfc-hajimi") Pkg.instantiate()
- Load Source:
include("src/RFCHajimi.jl") using .RFCHajimi
# Standard HJM-16 Encoding
cipher = hjm_encode("🐎 哈基米～哈基米～")
# Keyed Symmetric Hajimi (Layer 1)
key = 127
secret = hjm_encode("喝了蜂蜜就能更快！", key=key)
plain = hjm_decode(secret, key=key)The official way to establish a verified identity.
# 1. Start the interactive identity wizard
# This will ask for your Name and Email Address
sk, pk, id_str = hjm_create_identity()
# 2. Export your PUBLIC key for community submission
hjm_export_public_key(pk, "my_identity.hjm-pub", identity=id_str)
# 3. Export your PRIVATE key (with interactive confirmation)
# Note: Private keys can only be saved to the current directory.
hjm_export_private_key(sk, "my_identity.key")
# 4. Sign a message using your private key
sig = hjm_sign("I am authorized.", sk)
# 5. Verify any signature
is_valid = hjm_verify("I am authorized.", sig, pk)Used for establishing a shared secret over an insecure channel.
# Alice and Bob generate temporary DH keys
sk_a, pk_a = hjm_dh_generate_keys()
sk_b, pk_b = hjm_dh_generate_keys()
# Compute shared secret
shared_secret = hjm_dh_shared_secret(sk_a, pk_b)hjm_encrypt_file("secret.pdf", "secret.hjm", key=123)
hjm_decrypt_file("secret.hjm", "restored.pdf", key=123)# Importing back from armored string
imported_sk = hjm_import_key(read("my_identity.key", String))A reference browser-based transformation tool is available at index.html. This tool allows for instant encoding and decoding of HJM-16 streams without requiring a Julia environment.
The public site is available at https://rfc-hajimi.gaafet.org.
- The symmetric XOR layer is intended for obfuscation.
- Layer 2 (RSA): Reference implementation uses small primes for demonstration; production scripts should use hardened RSA.
- Layer 3 (Ed25519) & Layer 4 (X25519): Implemented following RFC 8032 and Curve25519 specifications for cryptographic strength.
- RFC Hajimi provides a robust framework for character-oriented cryptographic operations.
- Implement HJM-Auth (Hajimi-based OAuth 2.0 extension).
- Hardware Security Module (HSM) prototype for "Physical Hajimi Keys".
- NO LIABILITY: The RFC Hajimi Standard Committee and contributors are not responsible for any data, content, or consequences resulting from the use of this encoding or its cryptographic layers. Users assume all risks associated with data loss, corruption, or exposure.
- CRYPTO-SECURITY: Based on current mathematical reasoning and the security properties of the underlying primitives (RSA, X25519, Ed25519), it is computationally infeasible to reverse or "break" the content generated by a valid secret key without authorization. However, this is not a guarantee against future mathematical breakthroughs or implementation-specific vulnerabilities.
- EXPERIMENTAL STATUS: This standard is presented as an experimental security project. It should be used with appropriate caution in mission-critical environments.