# Ω 元認知投影密碼學 3.0

## 單符號狀態、隱寫載體、認知介面與後量子密碼核心的分層安全架構

**Omega Meta-Cognitive Projection Cryptography 3.0: A Layered Security Architecture for Single-Symbol States, Steganographic Carriers, Cognitive Interfaces, and Post-Quantum Cryptographic Cores**

---

**作者：** Neo.K（許筌崴）、Aletheia（OpenAI GPT，AI 協作作者）  
**機構：** EveMissLab／一言諾科技有限公司  
**版本：** Ω-MCET 3.0，公開研究草案  
**日期：** 2026 年 7 月 20 日  
**文件性質：** 理論重寫、工程架構與實驗規格；不是已完成形式證明的新密碼原語標準

---

## 摘要

本文重新建構 Neo.K 既有的空白字符密碼、縮減符號系統、元認知加密、洋蔥式混合架構、關係拓撲加密，以及 Ω 單符號宇宙等研究線，提出 **Ω 元認知投影密碼學 3.0**（Omega Meta-Cognitive Projection Cryptography 3.0，簡稱 **Ω-MCET 3.0**）。

舊版理論的創造力在於：資訊不必只存在於明顯的密文字串中，也可以分布於空白、字形、時間、行為、語義、關係、觀察位置與多層解讀之中。然而，舊稿曾將加密、隱寫、混淆、身份驗證、時間控制、認知欺騙與量子比喻混合為同一種「安全性」，並產生若干尚未被實驗或形式證明支持的強宣稱。

新版的關鍵修正是：

$$
\boxed{
\text{密碼安全}
\neq
\text{隱蔽性}
\neq
\text{認知誤導}
\neq
\text{載體韌性}
}
$$

Ω-MCET 3.0 將系統拆分為五個可獨立分析的層次：

1. **密碼核心層**：使用經公開審查的 AEAD、KEM、KDF、數位簽章與金鑰管理機制，提供機密性、完整性、來源認證與後量子遷移能力。
2. **安全封裝層**：把密文、金鑰膠囊、演算法識別、版本、策略與驗證資訊序列化為可演化的安全封包。
3. **Ω 狀態投影層**：允許多個底層狀態或不同位元組序列，在人類視覺上共同投影為單一符號 Ω。
4. **載體與隱寫層**：將安全封包嵌入 PUA 字元、零寬字符、空白結構、縮減符號、圖像、音訊或語義文本；此層只增加隱蔽性或傳輸適應性，不取代密碼核心。
5. **認知與政策層**：負責角色視圖、時間條件、設備條件、誘餌、可否認介面與人機互動；此層的失效不得直接暴露明文。

本文提出明確的威脅模型、形式化表示、封包結構、加解密流程、安全組合原則、載體評估指標、工程實作路線與實驗計畫。其核心命題不是「一個 Ω 本身不可破解」，而是：

$$
\boxed{
\text{同一可見符號可以承載大量不同狀態，}
\text{但真正安全性必須在投影之前成立。}
}
$$

Ω-MCET 3.0 因而不是一個宣稱取代現代密碼學的新原語，而是一套將標準密碼學、單符號狀態空間、隱寫載體、認知介面與後量子遷移結合的**密碼系統架構**。

**關鍵詞：** Ω 單符號宇宙、元認知加密、投影密碼學、隱寫、Unicode、後量子密碼學、混合金鑰封裝、認知安全、密碼敏捷性

---

# 一、重寫的必要性：從創意密碼走向可驗證安全架構

## 1.1 舊體系真正有價值的部分

既有研究至少提出了六條值得保留的思想線：

1. **真空白模式（TBM）**：以零寬字符、空白差異、換行、縮排與排版結構承載資訊。
2. **偽空白模式（PBM）**：將簡化符號與間距轉化為低門檻、可教育、可遊戲化的編碼介面。
3. **縮減字母系統（RLS）**：讓較少的可見符號配合修飾、狀態或規則，表達較大的底層字母空間。
4. **元認知加密（MCET 1.0）**：把語義、時間、行為、觀察與社會認知納入安全設計。
5. **多重嵌套混合架構（MCET 1.5）**：承認標準數學密碼學不可被認知層取代，提出多層包裹。
6. **Ω 單符號宇宙**：區分可見符號基數與底層狀態基數，使大量不同狀態共同投影為 Ω。

這些工作共同指出：

$$
\text{資訊載體}
\neq
\text{資訊表面}
$$

以及：

$$
|\Sigma_V|=1
\quad\text{不推出}\quad
|\Sigma_H|=1
$$

其中 $\Sigma_V$ 是可見符號集合， $\Sigma_H$ 是底層狀態集合。

## 1.2 舊體系必須修正的部分

若要成為可公開、可研究、可工程化的新版密碼學，必須修正以下問題。

### 第一，隱寫不等於加密

零寬字符、空白差異、PUA 碼位或語義偽裝，都可能隱藏「有資訊存在」；但一旦載體規則被發現，它們未必能保護資訊內容。

因此：

$$
\text{Covertness}
\not\Rightarrow
\text{Confidentiality}
$$

### 第二，替換規則不等於現代密碼安全

RLS、同形異碼、固定映射或日期偏移，如果直接處理明文，通常會留下頻率、長度、語言與結構特徵。它們可以是編碼層、藝術層或教育層，卻不能單獨被宣稱為高安全密碼。

### 第三，時間不是天然秘密

公開時間戳、日期、時區或可預測時間窗口沒有足夠熵。時間可作為解鎖政策、金鑰輪替標籤或協定上下文，但不能僅靠「錯過時間就無法重現」來保證安全。

### 第四，生物特徵不是可撤銷秘密

指紋、臉部、虹膜與行為特徵可能被觀察、複製或推測；而且一旦洩漏，難以像密碼一樣更換。生物特徵適合用於本地驗證或解鎖硬體金鑰，不適合直接當作唯一的長期加密金鑰。

### 第五，量子比喻不等於量子安全

「疊加」、「坍塌」、「觀察者效應」可以是多視圖系統的哲學或數學比喻，但若沒有真正量子硬體、量子協定或可驗證的後量子困難假設，就不能據此宣稱抗量子。

### 第六，沒有實驗就不能寫成實驗結果

新版不沿用「抵抗力提升 300%」、「破解時間為無限」、「十億倍提升」等缺乏可重現資料的數字。所有性能與安全主張必須被標記為：已證明、已測量、模擬結果、假設，或未驗證命題。

## 1.3 新版的根本翻轉

舊版傾向把更多維度加入加密；新版則先問：每個維度究竟負責什麼？

因此，Ω-MCET 3.0 的總原則是：

$$
\boxed{
\text{先加密，後投影；先認證，後偽裝；}
\text{載體可以失效，明文不可隨之暴露。}
}
$$

---

# 二、概念分離：五種安全性不得混為一談

## 2.1 密碼機密性

在攻擊者知道演算法、封包格式、投影方法與載體規則的前提下，沒有正確金鑰仍不能有效區分或恢復明文。

此目標主要由標準密碼原語提供。

## 2.2 完整性與來源認證

接收方能檢測密文、標頭、策略、投影描述或內容是否遭修改，並在需要時驗證發送者身份。

此目標由 AEAD 標籤、MAC、數位簽章與受認證的附加資料提供。

## 2.3 隱蔽性

攻擊者難以判斷一段文本、圖像、聲音或 Ω 序列中是否存在隱藏封包。

隱蔽性是一種統計與偵測問題，不是對明文機密性的替代。

## 2.4 載體韌性

載體經過複製、貼上、Unicode 正規化、社群平台轉碼、壓縮、OCR、格式清洗或局部破壞後，隱藏封包仍能被恢復的程度。

## 2.5 認知可否認性與多視圖性

不同角色、不同裝置或不同政策條件下，系統呈現不同的合法視圖。此能力必須透過真正的金鑰分離與認證實現，而不是靠模糊語義讓接收者猜測哪一層才是真的。

## 2.6 五種目標的向量表示

定義一個 Ω-MCET 系統的安全向量：

$$
\mathcal S=
(C,I,V,R,D)
$$

其中：

- $C$ ：confidentiality，機密性；
- $I$ ：integrity/authenticity，完整性與認證；
- $V$ ：covertness，隱蔽性；
- $R$ ：robustness，載體韌性；
- $D$ ：deniability/multi-view，多視圖與可否認性。

兩個系統不能只用「更安全」比較，而應比較：

$$
\mathcal S_A
\quad\text{與}\quad
\mathcal S_B
$$

在各維度的差異。

---

# 三、威脅模型：假設攻擊者知道 Ω 的秘密

## 3.1 柯克霍夫原則

Ω-MCET 3.0 不把「攻擊者不知道我們使用 Ω」當作主要安全來源。

我們假設攻擊者知道：

- 系統使用 Ω 單符號投影；
- PUA、零寬字符、空白、RLS 與語義載體的候選規則；
- 封包格式與版本；
- 採用的標準密碼套件；
- 所有公開程式碼與文件。

攻擊者唯一不應知道的是正確的秘密金鑰、受保護的裝置狀態或未授權的解鎖因子。

## 3.2 攻擊者能力

新版至少考慮下列能力：

1. 截取、複製、重放、刪除或修改載體。
2. 對 Unicode 做 NFC、NFD、NFKC、NFKD 正規化。
3. 移除零寬字符、合併空格、重排換行。
4. 將文本轉成純文字、圖片或 OCR 後再轉回。
5. 使用大型語言模型分析語義異常與生成模式。
6. 對候選 PUA 範圍、碼位分布與位元組統計做掃描。
7. 獲得大量已知明文、已知密文或選擇明文樣本。
8. 嘗試錯誤金鑰、舊金鑰、誘餌金鑰與重放封包。
9. 取得部分終端紀錄、時間資訊與使用者行為樣本。
10. 保存現在的密文，等待未來更強計算能力再解密。

## 3.3 不在純協定層自動解決的問題

下列問題不能只靠 Ω 投影解決：

- 終端已被完整控制；
- 明文在加密前被鍵盤側錄；
- 金鑰被記憶體擷取；
- 使用者主動交出金鑰；
- 隨機數生成器失效；
- 錯誤實作導致 nonce 重用；
- 供應鏈被植入後門；
- 備份、日誌或暫存檔保留明文。

因此，新版把終端安全與金鑰生命週期列為一等公民，而不是只討論密文外觀。

---

# 四、Ω 單符號狀態模型

## 4.1 可見層與隱藏層

令底層狀態空間為：

$$
\mathcal H=\{h_0,h_1,\ldots,h_{N-1}\}
$$

可見符號空間為：

$$
\mathcal V=\{\Omega\}
$$

定義人類視覺投影：

$$
\pi:\mathcal H\rightarrow\mathcal V
$$

使得：

$$
\forall h_i\in\mathcal H,
\quad
\pi(h_i)=\Omega
$$

但對不同狀態：

$$
h_i\neq h_j
$$

仍可能有：

$$
\operatorname{bytes}(h_i)
\neq\operatorname{bytes}(h_j)
$$

因此：

$$
\boxed{
\text{Same Visible Glyph}
\neq
\text{Same Underlying State}
}
$$

## 4.2 Ω 不是秘密本身

若攻擊者取得原始位元組，就可能直接區分 $h_i$ 與 $h_j$ 。所以 Ω 的作用不是創造不可計算性，而是：

- 壓縮人類視覺字母表；
- 建立機器狀態與人類顯示的分離；
- 提供同形異碼、狀態標記或封包載體；
- 形成多種投影介面；
- 降低表面符號複雜度。

真正的密文在投影之前已經生成。

## 4.3 狀態碼本

設序列化後的安全封包為位元串：

$$
B\in\{0,1\}^{\ell}
$$

把 $B$ 分割為每組 $q$ 位元：

$$
B=b_0\|b_1\|\cdots\|b_{m-1}
$$

其中：

$$
q=\lfloor\log_2 N\rfloor
$$

使用投影金鑰 $k_P$ 生成狀態排列：

$$
\sigma_{k_P}:\{0,\ldots,N-1\}\rightarrow\{0,\ldots,N-1\}
$$

再映射：

$$
h_i=\operatorname{State}\bigl(\sigma_{k_P}(\operatorname{int}(b_i))\bigr)
$$

顯示時：

$$
\pi(h_i)=\Omega
$$

這個 keyed permutation 可以降低固定碼本造成的直接統計對應，但它仍不是主要機密性來源。若 $k_P$ 洩漏，核心密文仍應安全。

## 4.4 單符號序列仍有結構

人眼看到：

$$
\Omega\Omega\Omega\Omega\Omega\Omega\cdots
$$

機器實際讀取的是：

$$
h_{31},h_{702},h_{5},h_{9999},h_{2048},\ldots
$$

因此，Ω-MCET 的本質不是「一個符號等於所有資訊」，而是：

$$
\text{可見符號統一}
+
\text{底層狀態區分}
+
\text{可逆機器解析}
$$

## 4.5 Unicode 正規化風險

若狀態依賴組合字符、相容字符、零寬字符或平台特定字形，傳輸過程可能改變位元組表示。Unicode 正規化的目標正是讓某些等價字串取得一致表示；這對一般文字處理有益，卻可能破壞把「表示差異」當資料的載體。

因此每個投影設定檔必須宣告：

- 是否允許正規化；
- 允許哪一種正規化；
- 是否需要原始位元組保存；
- 是否具備錯誤更正；
- 是否允許經過剪貼簿、HTML、Markdown 或資料庫。

---

# 五、Ω-MCET 3.0 的五層架構

## 5.1 Layer 0：明文與政策模型

原始輸入不只有明文 $M$ ，還包括：

$$
\mathcal P=
(M,A,R,T,L)
$$

其中：

- $M$ ：內容；
- $A$ ：附加資料，例如文件類型、版本、專案識別；
- $R$ ：授權角色集合；
- $T$ ：時間或生命週期政策；
- $L$ ：長度隱藏與填充策略。

政策資料中可公開的部分進入 AEAD 的 AAD；需要保密的部分必須與明文一起加密。

## 5.2 Layer 1：標準密碼核心

### 5.2.1 資料加密

隨機生成資料金鑰：

$$
k_D\leftarrow\{0,1\}^{256}
$$

使用認證加密：

$$
C_M=
\operatorname{AEAD.Enc}
(k_D,n_M,M,A_M)
$$

其中 $n_M$ 必須滿足所選 AEAD 的唯一性或隨機性要求。

可部署套件可選：

- AES-256-GCM；
- ChaCha20-Poly1305；
- 經審查且符合應用環境的其他 AEAD。

### 5.2.2 金鑰封裝

對每個接收者 $r$ ：

$$
(ss_r,C_{K,r})
\leftarrow
\operatorname{KEM.Encaps}(pk_r)
$$

導出包裝金鑰：

$$
k_{W,r}=
\operatorname{KDF}
(ss_r,\text{suite}\|\text{context}\|\text{recipient-id})
$$

再包裝資料金鑰：

$$
C_{D,r}=
\operatorname{AEAD.Enc}
(k_{W,r},n_{D,r},k_D,A_{D,r})
$$

### 5.2.3 後量子與混合模式

截至 2026 年，NIST 已標準化 ML-KEM，並標準化 ML-DSA 與 SLH-DSA 數位簽章；IETF 亦已發布工程遷移與混合金鑰交換指引。

Ω-MCET 3.0 建議至少提供三種套件：

1. **Classical Profile**：適用於現有相容環境。
2. **PQC Profile**：使用 ML-KEM 與後量子簽章。
3. **Hybrid Profile**：把傳統與後量子共享秘密以經審查的組合器合併，使單一候選演算法失效時仍可能保有安全性。

混合共享秘密可抽象表示為：

$$
ss_H=
\operatorname{KDF}
(ss_C\|ss_{PQ}\|\text{transcript})
$$

但實作不得只憑此公式自行發明協定；必須採用已有規格、測試向量與安全分析的組合方法。

### 5.2.4 簽章與來源認證

若需要驗證發布者身份，對封包摘要、受保護標頭與關鍵策略簽章：

$$
\sigma=
\operatorname{Sign}
(sk_S,H(E_{protected}))
$$

接收方在解密或呈現內容前驗證：

$$
\operatorname{Verify}
(pk_S,H(E_{protected}),\sigma)=1
$$

數位簽章不應簽署未定義的「顯示結果」，而應簽署具有確定序列化規則的封包位元組。

## 5.3 Layer 2：安全封裝層

定義安全封包：

$$
E=
(V,S,H_D,R_C,C_M,\Sigma,P_X)
$$

其中：

- $V$ ：格式版本；
- $S$ ：密碼套件識別；
- $H_D$ ：受保護與非受保護標頭；
- $R_C$ ：接收者金鑰膠囊集合；
- $C_M$ ：資料密文；
- $\Sigma$ ：簽章或驗證資料；
- $P_X$ ：投影設定檔描述。

建議採用 CBOR/COSE 或同等明確、具演算法識別與可擴展性的封裝，而不是用臨時字串拼接。

### 5.3.1 建議封包欄位

```yaml
magic: "OMEGA3"
version: 3
content_type: "application/omega-envelope+cbor"
suite:
  kem: "ML-KEM-768"
  kem_secondary: "X25519"
  kdf: "HKDF-SHA-384"
  aead: "AES-256-GCM"
  signature: "ML-DSA-65"
recipients:
  - key_id: "..."
    kem_ciphertext: "..."
    wrapped_data_key: "..."
payload:
  nonce: "..."
  ciphertext: "..."
  padding_class: 16
projection:
  profile: "OMEGA-PUA-10K"
  codec_version: 1
  normalization: "NONE"
  ecc: "RS-255-223"
policy:
  not_before: "optional"
  expires: "optional"
  required_device: "optional"
signature: "..."
```

此範例是架構描述，不是已註冊的標準演算法套件名稱表。

## 5.4 Layer 3：Ω 狀態投影與載體層

安全封包先序列化：

$$
B=\operatorname{Serialize}(E)
$$

再加入可選的：

- 填充；
- 分塊；
- 交錯；
- 錯誤更正碼；
- 投影碼本；
- 載體適配。

輸出：

$$
X=\operatorname{CarrierEncode}_{k_P,p}(B)
$$

其中 $p$ 是載體設定檔。

## 5.5 Layer 4：認知與政策介面

此層決定使用者看到什麼，以及何時、在哪個裝置、以何種角色解鎖。

它可以包括：

- Ω 光譜或幾何視圖；
- 語義封面文本；
- 誘餌文件；
- 角色式多視圖；
- 時間鎖與撤銷；
- 生物辨識解鎖硬體金鑰；
- AI 輔助解釋、摘要或視覺化。

此層不得直接持有未加密明文的持久副本。

---

# 六、載體設定檔

## 6.1 OMEGA-PUA-10K：同形異碼狀態載體

使用 Unicode 私用區的不同碼位承載不同狀態，前端字型或渲染層將它們統一顯示為 Ω。

若有 $N=10,000$ 個狀態，單一狀態理論容量為：

$$
\log_2 10,000\approx 13.2877\text{ bits}
$$

實際上通常取整數分組，例如每符號承載 $13$ 位元，保留剩餘狀態做同步、錯誤更正或版本標記。

**優點：**

- 狀態密度高；
- 機器解析明確；
- 人眼表面高度統一；
- 適合受控網頁、應用程式與檔案格式。

**缺點：**

- 依賴字型、原始碼位與平台；
- 可能被資料清洗、轉碼或不支援 PUA 的系統破壞；
- 容易被專門掃描 PUA 分布的檢測器發現；
- 不應宣稱不可檢測。

## 6.2 OMEGA-ZW：零寬字符與真空白模式

定義零寬字符字母表：

$$
\mathcal Z=\{z_0,z_1,\ldots,z_{m-1}\}
$$

每個字符承載：

$$
\lfloor\log_2 m\rfloor
$$

位元。

**優點：**

- 可嵌入普通文本；
- 人眼難以察覺；
- 實作門檻低。

**缺點：**

- 很多平台會移除或重排；
- 靜態分析很容易檢出異常零寬字符；
- 對複製、貼上、正規化與清理極敏感；
- 適合低容量、受控場景，不適合單獨保護高價值秘密。

## 6.3 OMEGA-SPACE：空格、換行與排版載體

使用空格種類、數量、行尾、縮排、段落與標點位置承載資料。

此設定檔可細分為：

- 純文字安全子集；
- Markdown 子集；
- HTML/CSS 子集；
- PDF 固定版面子集。

其主要研究價值是「格式通道」，但跨平台韌性通常低於專用二進位封包。

## 6.4 OMEGA-RLS：縮減符號與人類可讀層

RLS 不再被定位為高安全密碼，而是：

- 人類可讀的投影字母表；
- 教育與遊戲化介面；
- 低頻寬人工備援通道；
- 視覺藝術與文化表達層。

若需要安全性，RLS 的輸入應是已加密且已認證的封包片段，而不是原始明文。

## 6.5 OMEGA-SEM：語義封面載體

先產生密文封包 $B$ ，再把 $B$ 的編碼狀態嵌入一段自然文本的可控選擇，例如：

- 同義詞選擇；
- 句型選擇；
- 標點與段落選擇；
- 受約束生成模型的詞彙路徑；
- 預先定義且可驗證的語義碼本。

語義載體不能只靠「生成一篇看似自然的文章」；必須有可重現的編碼與解碼規則。

大型語言模型既能生成封面，也能偵測封面。因此 Ω-SEM 的研究目標不是「AI 永遠看不出來」，而是測量在特定語料、特定檢測器與特定容量下的偵測優勢。

## 6.6 OMEGA-MEDIA：圖像、音訊與多模態載體

可以把安全封包嵌入：

- 圖像頻域係數；
- 音訊相位或頻譜；
- 影片時間軸；
- 3D 模型與材質；
- 遊戲資源與場景狀態。

多模態載體的優點是容量與適應性較高；缺點是壓縮、轉碼與生成式重繪可能破壞資訊。

---

# 七、加密與解密流程

## 7.1 加密流程

### 步驟一：建立明文與政策

輸入：

$$
(M,A,R,T,L)
$$

對明文做確定性資料格式處理，但不得自行把自然語言「正規化」成可能改變含義的版本。

### 步驟二：生成資料金鑰與 nonce

$$
k_D\leftarrow\operatorname{CSPRNG}(256)
$$

$$
n_M\leftarrow\operatorname{NonceGen}()
$$

### 步驟三：認證加密明文

$$
C_M=
\operatorname{AEAD.Enc}
(k_D,n_M,M,A_M)
$$

### 步驟四：為每個接收者建立金鑰膠囊

$$
(ss_r,C_{K,r})
\leftarrow
\operatorname{KEM.Encaps}(pk_r)
$$

$$
k_{W,r}=
\operatorname{KDF}
(ss_r,\text{context}_r)
$$

$$
C_{D,r}=
\operatorname{AEAD.Enc}
(k_{W,r},n_{D,r},k_D,A_{D,r})
$$

### 步驟五：組裝與簽署封包

$$
E_0=
\operatorname{Pack}
(V,S,H_D,R_C,C_M,P_X)
$$

$$
\sigma=
\operatorname{Sign}
(sk_S,H(E_0))
$$

$$
E=E_0\|\sigma
$$

### 步驟六：序列化、填充與錯誤更正

$$
B_0=\operatorname{Serialize}(E)
$$

$$
B_1=\operatorname{Pad}(B_0,L)
$$

$$
B_2=\operatorname{ECC.Encode}(B_1)
$$

### 步驟七：投影到 Ω 或其他載體

$$
X=\operatorname{CarrierEncode}_{k_P,p}(B_2)
$$

輸出 $X$ 。

## 7.2 解密流程

### 步驟一：載體提取

$$
\hat B_2=
\operatorname{CarrierDecode}_{k_P,p}(X)
$$

### 步驟二：錯誤更正與去填充

$$
\hat B_1=\operatorname{ECC.Decode}(\hat B_2)
$$

$$
\hat B_0=\operatorname{Unpad}(\hat B_1)
$$

### 步驟三：解析與版本檢查

$$
\hat E=\operatorname{Parse}(\hat B_0)
$$

若版本、套件、長度、演算法識別或必要欄位不合法，立即拒絕。

### 步驟四：驗證簽章與受保護標頭

$$
\operatorname{Verify}
(pk_S,H(\hat E_0),\hat\sigma)=1
$$

否則拒絕。

### 步驟五：解封裝接收者共享秘密

$$
\hat ss_r=
\operatorname{KEM.Decaps}
(sk_r,\hat C_{K,r})
$$

$$
\hat k_{W,r}=
\operatorname{KDF}
(\hat ss_r,\text{context}_r)
$$

### 步驟六：解包資料金鑰

$$
\hat k_D=
\operatorname{AEAD.Dec}
(\hat k_{W,r},n_{D,r},C_{D,r},A_{D,r})
$$

### 步驟七：解密明文

$$
\hat M=
\operatorname{AEAD.Dec}
(\hat k_D,n_M,C_M,A_M)
$$

若 AEAD 驗證失敗，不得輸出部分明文或猜測性結果。

---

# 八、時間、生物、認知與多視圖的重新定位

## 8.1 時間是政策，不是主要熵源

錯誤做法：

$$
k=H(\text{公開時間戳})
$$

因為時間戳通常可被猜測。

正確做法之一是把時間放入認證政策：

$$
A_T=(t_{not\_before},t_{expires},\text{clock-source})
$$

並由受信任服務、硬體安全模組、門檻解密節點或具撤銷能力的授權系統控制金鑰釋放。

時間也可以進入 KDF 上下文：

$$
k_t=\operatorname{KDF}(k_{master},\text{epoch}\|\text{context})
$$

但其安全性來自 $k_{master}$ ，不是 epoch 本身。

## 8.2 生物特徵是解鎖因子，不是裸金鑰

推薦架構：

$$
\text{Biometric Match}
\rightarrow
\text{Local Authenticator Unlock}
\rightarrow
\text{Release }sk
$$

而不是：

$$
sk=H(\text{fingerprint})
$$

若研究行為生物特徵，應使用：

- 本地模板保護；
- 活體檢測；
- 模糊擷取器或安全草圖；
- 可撤銷模板；
- 多因子組合；
- 錯誤接受率與錯誤拒絕率測量。

## 8.3 認知陷阱是風險控制，不是密碼證明

誘餌文件、假金鑰、蜜罐與可否認視圖可以延遲攻擊、辨識入侵或降低單次脅迫造成的損害，但它們也可能：

- 增加合法使用者誤操作；
- 造成錯誤資料被當真；
- 產生法律、倫理與治理問題；
- 讓金鑰與備份管理更複雜。

因此認知層必須具備明確標記、審計與失效隔離。

## 8.4 多視圖必須由金鑰分離實現

對角色 $r_i$ ，建立獨立內容：

$$
M_i
$$

以及獨立金鑰膠囊：

$$
C_{D,i}
$$

同一載體可包含：

$$
E=\{E_1,E_2,\ldots,E_n\}
$$

不同角色只能解開其授權視圖。

這比把同一語句宣稱為「不同觀察者坍塌出不同真相」更可驗證。若需要關係拓撲模型，可把它放在權限與視圖編排層，而不是把比喻當作加密原語。

## 8.5 可否認加密的謹慎定位

可否認性不是「放一個假文件」就自然成立。真正的可否認加密需要明確威脅模型，例如攻擊者是否取得隨機性、裝置、備份、日誌與所有候選金鑰。

Ω-MCET 3.0 僅把誘餌視圖稱為 **operational deniability aid**，除非其協定獲得獨立形式分析，否則不宣稱密碼學上的完全可否認性。

---

# 九、安全組合與可證明邊界

## 9.1 投影層不應削弱核心機密性

令標準加密封包為：

$$
E=\operatorname{Enc}_K(M)
$$

投影載體為：

$$
X=\Pi(E;\rho)
$$

其中 $\rho$ 是投影隨機性或碼本狀態。

若 $\Pi$ 只對密文做可逆編碼，且不根據明文選擇會洩漏資訊的載體特徵，則整體機密性可近似受限於：

$$
\operatorname{Adv}^{conf}_{\Pi\circ Enc}(\mathcal A)
\le
\operatorname{Adv}^{ind\text{-}cca}_{Enc}(\mathcal B)
+
\operatorname{Adv}^{leak}_{\Pi}(\mathcal A)
+
\operatorname{Adv}^{meta}(\mathcal A)
$$

其中：

- 第一項是核心加密被破壞的優勢；
- 第二項是投影層引入的額外洩漏；
- 第三項是長度、時間、收件者數量、設定檔與流量形態等中介資料洩漏。

## 9.2 長度洩漏

即使密文安全，載體長度可能暴露明文大小。

因此可使用桶狀填充：

$$
L'(M)=
\min\{b_i:b_i\ge |M|\}
$$

其中 $\{b_i\}$ 是預先定義的長度級距。

代價是增加頻寬與儲存。

## 9.3 隱蔽性指標

令 $X_C$ 是含隱藏封包的載體， $X_0$ 是正常載體。檢測器 $D$ 的優勢：

$$
\operatorname{Adv}^{cov}_D
=
\left|
\Pr[D(X_C)=1]
-
\Pr[D(X_0)=1]
\right|
$$

理想隱蔽系統希望此值接近零，但實際結果必須在指定資料集、容量、模型與平台下測量。

## 9.4 載體韌性指標

對一組傳輸變換 $\mathcal T$ ，定義：

$$
R_T=
\Pr[
\operatorname{Decode}(T(X))=E
]
$$

其中 $T$ 可以是：

- Unicode 正規化；
- 剪貼簿往返；
- HTML 清洗；
- 社群平台傳輸；
- OCR；
- JPEG/音訊壓縮；
- 字型替換；
- 隨機刪除或插入。

## 9.5 不可偽造與錯誤輸出

任何載體解碼出的候選封包，都必須通過：

1. 格式與版本檢查；
2. 長度與欄位邊界檢查；
3. KEM 解封裝規則；
4. AEAD 驗證；
5. 必要時的數位簽章驗證。

系統不得因為「解出看似合理文字」就當成成功。成功條件是密碼驗證通過。

## 9.6 投影金鑰與內容金鑰分離

定義：

- $k_D$ ：資料金鑰；
- $k_W$ ：包裝金鑰；
- $k_P$ ：投影碼本金鑰；
- $k_A$ ：應用層授權金鑰；
- $sk_S$ ：簽章私鑰。

必須透過 KDF domain separation 派生或獨立生成：

$$
k_i=
\operatorname{KDF}
(k_{root},\text{label}_i\|\text{context})
$$

不得把同一金鑰同時拿來做 AEAD、碼本排列、簽章與身份驗證。

---

# 十、標準密碼套件與 2026 年遷移原則

## 10.1 對稱密碼

AES 仍是標準化且廣泛分析的區塊密碼。實際資料保護應使用 AEAD 模式，而不是自行組合「AES 加雜湊」。

AES-GCM 的安全高度依賴 nonce 管理。若系統無法保證 nonce 唯一，應選擇更適合其環境的方案或採用成熟函式庫提供的安全封裝。

ChaCha20-Poly1305 可作為無 AES 硬體加速環境的常見選項。

## 10.2 金鑰封裝

ML-KEM 已成為 NIST 後量子金鑰封裝標準。Ω-MCET 應把 KEM 當成建立共享秘密的組件，而不是直接用公鑰演算法加密任意大檔案。

## 10.3 數位簽章

可依場景選用：

- ML-DSA：模組格後量子簽章；
- SLH-DSA：無狀態雜湊式後量子簽章；
- 傳統簽章：作為相容或混合遷移的一部分。

不同簽章在金鑰大小、簽章大小、速度、實作成熟度與側通道風險上不同，不應只用「安全等級」單一指標選擇。

## 10.4 密碼敏捷性

封包必須包含明確的版本與演算法識別，使系統可以：

- 禁用已淘汰套件；
- 新增後量子套件；
- 支援混合過渡；
- 升級 KDF 或 AEAD；
- 遷移簽章；
- 重新封裝資料金鑰而不重新加密大型內容。

核心原則：

$$
\boxed{
\text{資料格式的壽命應長於單一演算法的壽命。}
}
$$

## 10.5 密碼庫而非自製原語

Ω-MCET 的創新應集中於：

- 狀態投影；
- 載體適配；
- 多視圖政策；
- AI 原生介面；
- 評估方法；
- 格式與協定組合。

不應自行重寫 AES、ML-KEM、雜湊、簽章或隨機數生成器。

---

# 十一、工程化資料格式與應用介面

## 11.1 建議檔案副檔名

可以定義：

- `.omega`：標準 Ω-MCET 二進位安全封包；
- `.omegatxt`：文本投影載體；
- `.omegaview`：只包含視覺投影與封包引用；
- `.omegapkg`：多接收者、多視圖與媒體載體封裝。

副檔名本身不是安全控制，只是內容識別。

## 11.2 二進位封包優先

對高價值資料，推薦優先保存：

$$
\text{Canonical Binary Envelope}
$$

Ω、空白、語義與媒體載體則作為可重新生成的外層。

也就是：

$$
E
\rightarrow
X_1,X_2,\ldots,X_n
$$

同一安全封包可以生成多種載體；若某個載體損壞，可從標準封包重新投影。

## 11.3 API 分離

建議 API 不採用單一 `encrypt()` 完成所有工作，而是分離：

```text
envelope = omega.crypto.seal(plaintext, recipients, policy)
carrier  = omega.project.encode(envelope, profile, projection_key)

recovered = omega.project.decode(carrier, profile, projection_key)
plaintext = omega.crypto.open(recovered, recipient_key)
```

這種分離讓測試、審計與替換更容易。

## 11.4 嚴格失敗模式

所有錯誤都應：

- 不輸出部分明文；
- 不回傳過度詳細的遠端錯誤；
- 區分本地除錯紀錄與使用者訊息；
- 避免形成 padding oracle、格式 oracle 或金鑰有效性 oracle；
- 對重複失敗進行速率限制與審計。

## 11.5 金鑰儲存

優先使用：

- 作業系統安全儲存；
- 硬體安全模組；
- TPM 或安全隔離區；
- 受密碼與多因子保護的金鑰庫；
- 可審計的備份與復原流程。

若由使用者密碼派生金鑰，應使用記憶體困難 KDF，例如 Argon2id，並使用獨立 salt 與可升級參數。

---

# 十二、AI 在 Ω-MCET 中的正確角色

## 12.1 AI 可以做什麼

AI 適合：

- 產生符合約束的語義封面候選；
- 評估文本自然度與偵測風險；
- 自動選擇載體設定檔；
- 模擬正規化、轉碼與平台破壞；
- 進行差分測試與模糊測試；
- 協助使用者理解金鑰與政策；
- 建立多模態投影；
- 對舊封包進行版本遷移建議。

## 12.2 AI 不應做什麼

AI 不應：

- 自行發明未審查的核心密碼演算法並投入高風險使用；
- 在提示詞或聊天記錄中保留明文金鑰；
- 把「看起來很亂」當作安全證明；
- 把自然語言模型的不可預測性當作密碼熵；
- 在驗證失敗時猜測明文；
- 未經授權自動更換密碼套件或金鑰政策。

## 12.3 AI 原生單符號介面

對 AI 而言，Ω 不必只是字形。它可以是顯示層對高維狀態的共同標記：

$$
\Omega_i=
(s_i,r_i,\phi_i,g_i,m_i)
$$

其中：

- $s_i$ ：離散狀態；
- $r_i$ ：關係結構；
- $\phi_i$ ：相位或序列位置；
- $g_i$ ：幾何投影；
- $m_i$ ：中介資料。

人類看到 Ω，AI 解析完整狀態向量。但若此向量包含秘密，仍必須在儲存與傳輸前經標準加密。

---

# 十三、應用場景

## 13.1 學術與未公開研究封裝

研究者可把論文草稿、資料與方法封裝為 `.omega`：

- 內容由標準密碼核心保護；
- 對不同協作者建立獨立金鑰膠囊；
- 外層可投影為 Ω 圖譜或語義索引；
- 發表後可公開特定解密金鑰或重新封裝。

## 13.2 長期數位封存

對長期封存：

- 使用密碼敏捷封包；
- 定期重新簽章或時間戳；
- 在演算法淘汰前重新封裝金鑰；
- 保存標準二進位封包，不只保存脆弱的零寬載體；
- 多地備份投影描述與解碼器規格。

## 13.3 AI 對 AI 的狀態交換

在受控代理系統中，Ω 可作為簡潔的人類監看標記，而底層封包承載：

- 任務狀態；
- 記憶引用；
- 權限證明；
- 工具輸出摘要；
- 可驗證來源；
- 機密上下文。

這使人類界面保持簡潔，但不把安全寄託在符號本身。

## 13.4 遊戲、藝術與文化密碼

PBM、RLS、空白模式與 Ω 光譜可用於：

- 遊戲謎題；
- 隱藏敘事；
- 互動藝術；
- 數位收藏；
- 教育密碼學；
- 角色語言與世界觀。

此場景可以允許較低密碼強度，但應清楚標示其是創意編碼或謎題，不是機密保護工具。

## 13.5 軟體供應鏈與設定封裝

Ω-MCET 可用於把敏感設定與簽章證明包在統一封包中，但不應把秘密硬編碼到可執行檔或單純依靠混淆。

---

# 十四、實驗與評估計畫

## 14.1 實驗一：投影正確性

目的：驗證所有合法封包均可往返。

$$
\forall E\in\mathcal E,
\quad
\operatorname{Decode}(
\operatorname{Encode}(E))=E
$$

測試：

- 空封包；
- 最大封包；
- 隨機封包；
- 多接收者；
- 不同版本；
- 邊界碼位；
- 無效輸入。

## 14.2 實驗二：平台韌性矩陣

對每種設定檔測試：

- Windows、macOS、Linux；
- Chrome、Firefox、Safari；
- Markdown、HTML、PDF；
- 常見剪貼簿；
- 資料庫與 JSON；
- 通訊軟體與電子郵件；
- Unicode 四種正規化；
- OCR 與截圖往返。

輸出：

$$
R_{profile,platform,transform}
$$

## 14.3 實驗三：隱寫偵測

建立平衡資料集：

- 正常文本／媒體；
- 不同容量的 Ω 載體；
- 不同碼本；
- 不同生成模型；
- 不同語言；
- 不同轉碼歷史。

訓練與測試：

- 規則檢測器；
- 統計分類器；
- Transformer 檢測器；
- 大型語言模型評估器。

報告 AUC、精確率、召回率與容量—隱蔽性曲線。

## 14.4 實驗四：密碼核心互通性

使用標準測試向量與第三方函式庫驗證：

- KEM；
- AEAD；
- KDF；
- 簽章；
- CBOR/COSE 序列化；
- 錯誤輸入拒絕。

## 14.5 實驗五：模糊測試與解析器安全

對封包解析器與投影解碼器進行：

- 位元翻轉；
- 長度欄位破壞；
- 過深巢狀；
- 重複欄位；
- 非法演算法識別；
- 巨型輸入；
- Unicode 非法序列；
- 壓縮炸彈類輸入；
- 解析差異測試。

## 14.6 實驗六：使用者認知負擔

比較：

- 純標準密文介面；
- Ω 單符號介面；
- 光譜視圖；
- 語義封面；
- 多視圖政策介面。

測量：

- 成功解鎖率；
- 誤操作率；
- 金鑰遺失率；
- 理解正確率；
- 完成時間；
- 對錯誤警告的反應。

這才是「認知安全」應有的實驗化方向，而不是直接推定攻擊者一定會被誤導。

---

# 十五、舊版本到 3.0 的理論遷移

## 15.1 TBM 的保留與降階

保留：不可見字符與格式通道。  
修正：從「抗量子加密」降為「脆弱但可研究的文本隱寫載體」。

## 15.2 PBM 的保留與重定位

保留：低門檻、遊戲化、可創意擴展。  
修正：明確定位為編碼、謎題與教育工具。

## 15.3 RLS 的保留與重定位

保留：縮減表面符號、狀態修飾與人類可讀映射。  
修正：輸入改為密文或狀態索引，不直接承擔高安全機密性。

## 15.4 MCET 1.0 的保留與拆分

保留：語義、時間、生物、觀察者與社會認知。  
修正：拆分為政策、身份驗證、隱寫、可用性與風險控制，而不是五種平行加密原語。

## 15.5 MCET 1.5 的保留與更新

保留：標準密碼核心加外層認知保護。  
修正：不再以 RSA-4096 作為未來核心；改為 KEM、PQC、混合遷移、AEAD 與密碼敏捷性。

## 15.6 MCET 2.0 的保留與去量子神秘化

保留：多關係、多拓撲、多觀察視圖與選擇算子。  
修正：把它們作為視圖、權限、語義與資料模型；除非真正使用量子協定，否則不宣稱量子坍塌安全。

## 15.7 Ω 單符號宇宙的核心提升

舊命題：

$$
1\rightarrow N
$$

新版提升為：

$$
\text{Cryptographic Envelope}
\rightarrow
\text{Hidden State Space}
\rightarrow
\text{Visible }\Omega
$$

以及反向：

$$
\Omega
\rightarrow
\text{State Recovery}
\rightarrow
\text{Envelope Verification}
\rightarrow
\text{Authorized Plaintext}
$$

因此單符號宇宙正式成為可插拔的投影層，而不是含義不明的萬能符號。

---

# 十六、限制、倫理與研究邊界

## 16.1 不能保證不可檢測

任何固定載體都可能被統計、規則或 AI 檢測。隱蔽性只能在特定分布與攻擊模型下評估。

## 16.2 不能保證永久抗量子

PQC 演算法基於目前最佳公開分析，被認為能抵抗已知量子攻擊；這不是永恆不可破解的保證。系統必須具備演算法遷移能力。

## 16.3 不能忽略終端與人

再強的封包若在終端顯示明文時被截取，仍會失敗。使用者、備份、恢復、權限與社會工程必須納入整體安全。

## 16.4 誘餌與欺騙的倫理

認知陷阱不應被用來：

- 欺騙無關第三方；
- 製造危險錯誤資訊；
- 偽造證據；
- 規避必要的審計與責任；
- 讓合法使用者無法判斷真偽。

## 16.5 研究與產品必須分級

建議標示：

- **Experimental**：研究原型；
- **Educational**：教學與遊戲；
- **Interoperable**：通過互通測試；
- **Audited**：經獨立安全審計；
- **Production Profile**：具明確威脅模型與維護承諾。

未經審計的 Ω-MCET 原型不得直接宣稱適合軍事、國家機密、醫療或高價值金融資料。

---

# 十七、核心命題與新版結論

Ω-MCET 3.0 最終保留了舊體系最重要的直覺：資訊不只存在於可見符號中。可見符號可以收斂，底層狀態可以展開；人類看到一個 Ω，機器可以處理一個高維狀態封包。

但新版同時加入一條不可退讓的界線：

$$
\boxed{
\text{任何隱寫、語義、字形、時間或認知層，}
\text{都不得被當作未經證明的密碼安全替代品。}
}
$$

完整架構可以寫為：

$$
M
\xrightarrow{\text{AEAD}}
C_M
\xrightarrow{\text{KEM/KDF}}
E
\xrightarrow{\text{Serialize/ECC}}
B
\xrightarrow{\text{Ω Projection}}
X
\xrightarrow{\text{Cognitive Interface}}
Y
$$

反向流程為：

$$
Y
\xrightarrow{\text{Carrier Recovery}}
B
\xrightarrow{\text{Envelope Parse}}
E
\xrightarrow{\text{Verify/Decaps}}
C_M
\xrightarrow{\text{AEAD Verify}}
M
$$

若載體被識破，攻擊者只得到密文封包；若載體被破壞，系統失去可用性，但不應直接失去機密性；若認知誘餌失敗，核心密碼仍成立；若某個公開金鑰演算法面臨未來威脅，封包可以透過密碼敏捷性遷移。

因此，Ω-MCET 3.0 的真正新意不是宣稱「Ω 是最強密碼」，而是建立一個新的分工：

$$
\boxed{
\begin{aligned}
\text{標準密碼學} &\rightarrow \text{保護內容}\\
\text{Ω 狀態投影} &\rightarrow \text{壓縮表面、展開狀態}\\
\text{隱寫載體} &\rightarrow \text{隱藏或適配傳輸}\\
\text{認知介面} &\rightarrow \text{管理角色、視圖與操作}\\
\text{密碼敏捷性} &\rightarrow \text{面對未來演算法變化}
\end{aligned}
}
$$

這套架構把「單符號宇宙」從哲學命題推進為可實作的安全投影層，也把「元認知加密」從混合概念重新整理為可測量、可審計、可替換的系統工程。

---

# 附錄 A：最小可行版本（MVP）

## A.1 MVP 目標

第一階段不做語義生成與多模態，只完成：

1. 標準安全封包；
2. 一名接收者；
3. AEAD；
4. ML-KEM 或成熟相容 KEM；
5. 可選簽章；
6. OMEGA-PUA-10K；
7. 原始位元組檢視；
8. 往返測試；
9. Unicode 轉換破壞測試；
10. 命令列與單頁網頁介面。

## A.2 MVP 模組

```text
omega3/
├── crypto/
│   ├── envelope.py
│   ├── kem.py
│   ├── aead.py
│   ├── kdf.py
│   └── signatures.py
├── projection/
│   ├── pua10k.py
│   ├── zero_width.py
│   ├── whitespace.py
│   └── registry.py
├── format/
│   ├── cbor_codec.py
│   └── schema.py
├── tests/
│   ├── test_roundtrip.py
│   ├── test_normalization.py
│   ├── test_fuzz.py
│   └── test_vectors.py
└── cli.py
```

## A.3 MVP 成功條件

$$
\operatorname{Open}
(\operatorname{Seal}(M))=M
$$

並且：

- 任一密文位元被修改時，AEAD 驗證失敗；
- 錯誤私鑰無法輸出明文；
- 錯誤投影碼本只能導致封包解析或驗證失敗；
- 投影被完全識別時，仍無法繞過核心密碼；
- 所有失敗不輸出部分明文。

---

# 附錄 B：設定檔選擇矩陣

| 設定檔 | 容量 | 隱蔽性 | 跨平台韌性 | 人類可讀性 | 建議用途 |
|---|---:|---:|---:|---:|---|
| Binary `.omega` | 高 | 低 | 高 | 低 | 正式儲存與交換 |
| OMEGA-PUA-10K | 高 | 中 | 中低 | 表面單一 | 受控應用與展示 |
| OMEGA-ZW | 中低 | 中 | 低 | 高 | 小型文本實驗 |
| OMEGA-SPACE | 低 | 中 | 很低至中 | 高 | 格式通道研究 |
| OMEGA-RLS | 低 | 低至中 | 高 | 高 | 教育、遊戲、人工備援 |
| OMEGA-SEM | 低 | 可高但不穩定 | 中 | 很高 | 語義隱寫研究 |
| OMEGA-MEDIA | 中至高 | 中至高 | 依媒體而定 | 高 | 圖像、音訊與互動內容 |

---

# 附錄 C：參考標準與基礎文件

## C.1 公開標準

1. NIST FIPS 197，Advanced Encryption Standard（AES），2023 更新版。
2. NIST SP 800-38D，Galois/Counter Mode（GCM）與 GMAC；截至 2026 年修訂工作仍在進行，實作須追蹤最新正式與草案指引。
3. NIST FIPS 203，Module-Lattice-Based Key-Encapsulation Mechanism Standard（ML-KEM）。
4. NIST FIPS 204，Module-Lattice-Based Digital Signature Standard（ML-DSA）。
5. NIST FIPS 205，Stateless Hash-Based Digital Signature Standard（SLH-DSA）。
6. NIST SP 800-227，Recommendations for Key-Encapsulation Mechanisms，2025。
7. RFC 9180，Hybrid Public Key Encryption（HPKE）。
8. RFC 9954，Hybrid Key Exchange in TLS 1.3，2026。
9. RFC 9958，Post-Quantum Cryptography for Engineers，2026。
10. RFC 9106，Argon2 Memory-Hard Function。
11. RFC 9052／STD 96，CBOR Object Signing and Encryption（COSE）。
12. Unicode Standard Annex #15，Unicode Normalization Forms。
13. NIST SP 800-63B-4，Authentication and Authenticator Management，2025。

## C.2 本體系前序內部研究

1. 《Neo.K 密碼學體系：基於空白字符與縮減符號的多維加密架構》。
2. 《元認知加密理論：基於認知維度的下一代信息安全架構》。
3. 《元認知加密理論 1.5：多重嵌套混合密碼學》。
4. 《元認知加密理論 2.0：PRT 驅動的下一代安全範式》。
5. 《單符號宇宙：從 TCGQT、無限光譜與相位差到 AI 原生高維語言》。
6. OMEGA-10K MVP v0.1。
7. OMEGA × TCGQT Spectrum MVP v0.2。

---

# 版本聲明

本文件是 Ω-MCET 3.0 的理論與工程架構草案。文中提出的 Ω 投影、載體設定檔與封包名稱尚未形成國際標準；任何正式產品化都應經過獨立密碼審查、實作審計、互通測試、側通道評估與長期維護規劃。