양자내성 SoC를 위한 SHA-3·SHAKE 설계 핵심

- 4월 26, 2026

🔐 SoC 보안 IP를 위한 SHA-3 / SHAKE 종합 기술 브리핑

📌 대상 보안 하드웨어 RTL 설계자 · 알고리즘부터 Verilog 구현, PQC 연계까지

한 줄 요약: SHA-3 / SHAKE 코어 1개를 잘 설계하면 ① 무결성 해시, ② MAC(KMAC), ③ DRBG·스트림, ④ ML-KEM·ML-DSA 같은 양자내성 알고리즘의 빌딩블록까지 모두 한 IP에서 커버할 수 있다. PQC 의무화 흐름 속에서 사실상 "기본 탑재 IP"가 되어가고 있는 이유다.

🧭 1. 표준 위상 — 왜 지금 SHA-3인가

SHA-3는 NIST가 2015년 FIPS 202로 공식화한 차세대 해시 표준으로, 본체는 KECCAK 팀(Bertoni · Daemen · Peeters · Van Assche)이 설계한 Keccak 알고리즘이다. SHA-2가 Merkle–Damgård 기반인 반면 SHA-3는 스펀지(Sponge) 구조를 채택해 길이 연장 공격에 구조적으로 면역이며, 동일 코어로 다양한 출력 길이를 만들 수 있다.

SHAKE128 / SHAKE256은 같은 Keccak-p[1600, 24] 치환을 공유하는 가변 길이 출력 함수(XOF)이다. 결과적으로 단일 하드웨어 코어 = 고정 길이 해시 + 임의 길이 PRF + PQC 빌딩블록이 성립한다.

▶ 표준별 파라미터 한눈에 보기

함수	Rate (r)	Capacity (c)	출력	보안
SHA3-224	1152	448	224	112
SHA3-256	1088	512	256	128
SHA3-384	832	768	384	192
SHA3-512	576	1024	512	256
SHAKE128	1344	256	가변	128
SHAKE256	1088	512	가변	256

▶ Rate(throughput) vs Capacity(보안) 트레이드오프

SHAKE128

r=1344

SHA3-224

r=1152

SHA3-256

r=1088

SHA3-384

r=832

SHA3-512

r=576

📊 막대가 길수록 1라운드당 흡수 비트가 많다 = 처리량 ↑. 단 capacity가 줄어 보안 마진이 ↓ (보안 ≈ c/2).

⚙️ 2. 핵심 이론 — 1600-bit 스펀지 상태

전체 상태 크기는 b = 1600 비트이며, b = r + c로 분리된다. 외부와 XOR 되는 영역이 rate r, 외부에 노출되지 않는 보안 마진이 capacity c다.

1600비트는 5 × 5 × 64 (x, y, z) 3차원 배열로 본다. z축 64-bit 워드를 Lane이라 부르며, Verilog의 자연스러운 처리 단위가 된다.

⚠️ Endianness 함정: FIPS 202는 메시지 바이트의 LSB가 lane의 z=0에 들어가도록 매핑한다. 무심코 MSB-first로 구현하면 NIST CAVP 테스트 벡터가 전부 깨진다 — 가장 흔한 디버깅 늪.

🛠️ 3. 처리 단계 Step-by-Step (Verilog 관점)

Step 1. 패딩 + 도메인 분리

함수	부착 비트열 (LSB-first)	첫 패드 바이트
SHA3-*	`01` + `10*1`	0x06
SHAKE*	`1111` + `10*1`	0x1F
RawSHAKE	`11` + `10*1`	0x07

"SHAKE는 0x1F, SHA-3는 0x06"이라는 매직 바이트는 임의 상수가 아니라 LSB-first로 도메인 비트열을 더한 결과값이다. RTL에서는 마지막 블록의 마지막 바이트에 도메인 비트를 OR로 삽입하고, 블록 마지막 비트(pad10*1의 마지막 1)를 OR해야 한다.

Step 2 ~ 3. 흡수 + Keccak-f[1600] 24라운드

메시지를 r-bit 블록으로 잘라 상태와 XOR한 뒤 24라운드 치환을 돌린다. 각 라운드는 정확히 5단계로 구성되며, 비선형은 χ 단 한 단계뿐이다 — 이는 후술할 마스킹 비용 절감의 결정적 이점이다.

단계	역할	선형성	HW 비용
θ	column 패리티 XOR — 확산	선형	XOR 게이트
ρ	lane 내 64-bit 회전	선형	와이어링 0
π	5×5 평면 lane 재배치	선형	와이어링 0
χ	유일한 비선형 — AND·NOT·XOR	비선형	DPA 표적
ι	Round Constant XOR	선형	ROM/case

Step 4. 짜내기 (Squeezing)

출력 d 비트를 채울 때까지 S[0:r-1]를 토해내고, 모자라면 다시 Keccak-f를 돌린다. SHA3-256/512처럼 d ≤ r 인 경우 squeeze 1회로 끝나지만, SHAKE는 본질적으로 squeeze 루프 위에서 동작하므로 streaming(valid/ready) 인터페이스가 필수다.

🏗️ 4. RTL 데이터패스 선택과 벤치마크 레인지

구조	1 hash 시간	면적	용도
Iterative (1 round/clk)	24 cycles	작음	범용 SoC (가장 일반적)
Unrolled / Pipelined	≥ 1 cycle/blk	매우 큼	네트워크 라인레이트 40 Gbps+
Folded (64-bit datapath)	수백 cycles	매우 작음	IoT, 스마트카드

📊 업계 보고 (2024 서베이) — FPGA Iterative ≈ 1.5–2.5k LUT, 1–3 Gbps · Unrolled ≈ 10–20k LUT, 30–40 Gbps+ · ASIC Iterative ≈ 20–40k GE. 공정/툴/옵션에 따라 광범위하게 변하므로 절대값으로 인용하지 말고 본인 PDK 재합성 후 검증할 것.

▶ 모듈 분할 권장안

keccak_top
├── pad_unit     : 도메인 비트 + pad10*1, byte-enable
├── absorb_xor_mux : state[0:r-1] ^= block
├── keccak_round  : θ → ρ → π → χ → ι (combinational)
├── round_counter : 0..23
├── rc_rom      : 24 × 64-bit round constants
├── state_reg    : 5×5 lane array (reg [63:0] A[0:4][0:4])
└── squeeze_unit  : 출력 r-bit 단위 스트리밍

▶ 자주 빠지는 함정 (Pitfalls)

▶ 1600-bit 단일 reg 선언은 합성기에서 routing congestion 유발. 5×5 lane array로 선언해 인덱스 연산으로 θ/ρ/π를 깔끔하게 표현하라.

▶ I/O 병목 — Keccak-f는 24 cycle이면 끝나는데 1600-bit를 32/64-bit AXI로 토하면 데이터 전송이 더 오래 걸린다. AXI4-Stream + DMA 권장.

▶ Constant-time 보장 — 알고리즘 자체는 데이터 비의존이지만, valid/ready 핸드셰이킹이나 패딩 컨트롤러에서 입력 길이에 따라 분기 시간이 새지 않게 주의.

▶ 테스트 벡터 — 최종 다이제스트만 비교하면 θ/ρ 비트오더 버그를 놓친다. CAVP KAT + FIPS 202 Appendix B로 중간 라운드 상태까지 일치 검증할 것.

🛡️ 5. 사이드채널(SCA) 대응 — IP의 사실상 의무

Keccak이 선형 4단계 + 비선형 1단계(χ) 구조라는 점은 마스킹(masking) 측면의 큰 장점이다. χ 단계의 AND-NOT 연산이 DPA의 주 표적이므로, Boolean masking을 기본으로 하고 share 간 상관을 제거하는 DOM(Domain-Oriented Masking) 또는 Threshold Implementation(TI)이 사실상 표준이다.

▶ 마스킹 비용 (2-share 기준)

면적 증가 약 2.5–3배

지연 증가 약 1.5배

▶ Round Constant 주입 구간에 랜덤 마스크 refresh, 그리고 fault injection 대응을 위한 redundancy / round-recompute 검증을 추가 권장. FIPS 140-3 / CC EAL 인증 트랙에 올리려면 사실상 필수다.

🚀 6. PQC 연계 — 진짜 미래 수요

NIST는 2024년 PQC(양자내성암호) 표준을 확정했으며, 그 핵심 알고리즘들이 내부 해시·XOF로 SHA-3 / SHAKE를 대량 호출한다.

PQC 표준의 SHA-3 / SHAKE 의존도 (개념적)

ML-KEM (FIPS 203, Kyber) — SHAKE128 매트릭스 샘플링

ML-DSA (FIPS 204, Dilithium) — SHAKE256 PRF·도전값

SLH-DSA (FIPS 205, SPHINCS+) — SHA-3 기반 PRF

🧠 SoC 설계 시사점:

▶ SHA-3 코어는 단발 호출이 아니라 수십~수백 번 짧은 메시지로 호출되는 패턴이 된다 → 세션 캐싱과 빠른 상태 reset이 throughput을 좌우.

▶ SHAKE의 중간 state save / restore 인터페이스가 사실상 필수.

▶ KMAC, cSHAKE, TupleHash, ParallelHash(SP 800-185)도 같은 코어로 처리 가능 → 명령 디코더에 함수 코드 필드 두는 설계가 일반적.

🪶 7. 경량 영역 — ASCON과의 비교

항목	SHA-3 / Keccak	ASCON-Hash
내부 상태	1600-bit	320-bit
구조	Sponge	Sponge (유사)
면적	기준	약 1/4 이하
타깃	범용 / PQC / 서버	IoT / 센서 / RFID

▶ 칩이 PQC, TLS, 디스크 암호화 등 "큰 보안"을 다루면 SHA-3, 정말 좁은 IoT/센서 노드면 ASCON-Hash가 합리적이다. 대체재가 아니라 세그먼트가 다른 표준임을 기억할 것.

🔮 8. 향후 전망 (Outlook)

▶ PQC 의무화 흐름과 함께 SHA-3 / SHAKE 가속기는 선택이 아닌 기본 IP. 정부·국방·금융 SoC 스펙에서 FIPS 202 / 203 / 204 동시 지원 요구가 늘고 있다.

▶ 하나의 Keccak 코어를 다용도로 재사용하는 트렌드 — 해시, KMAC, DRBG, PQC 내부 PRF까지 — 이 강해지면서 절대 성능보다 인터페이스 유연성(state save/restore, 도메인 코드, 스트리밍)이 차별 포인트가 된다.

▶ 사이드채널 보호 내장형 IP가 표준화되어 마스킹·셔플링·redundancy 없이는 정부 인증 트랙 진입 자체가 어려워진다.

▶ 경량 + 양자내성 하이브리드 SoC — ASCON(LWC) + SHA-3 / SHAKE(PQC) 듀얼 IP를 같은 칩에 두는 설계가 IoT 게이트웨이 / 엣지에서 늘어날 전망.

✅ 9. 설계자 체크리스트 (Final)

✓ FIPS 202의 도메인 비트(0x06 / 0x1F / 0x07)와 pad10*1을 LSB-first 비트 단위로 정확히 구현했는가?

✓ 1600-bit 상태를 5×5×64 lane 배열로 모델링했는가? Endianness 매핑은 부록 그대로인가?

✓ θ / ρ / π / χ / ι 각 단계의 중간 상태가 골든 모델과 일치하는가? (CAVP KAT만으로는 부족)

✓ iterative vs unrolled 결정이 목표 throughput · 면적 · 전력과 일치하는가?

✓ AXI4-Stream / DMA로 I/O 병목을 제거했는가?

✓ 사이드채널(DPA / fault) 대응이 위협 모델에 맞게 들어갔는가?

✓ SHAKE state save / restore, 도메인 코드, KMAC / cSHAKE 확장 여지를 인터페이스에 남겼는가?

✓ 검증에 NIST CAVP + FIPS 202 Appendix B + hashlib 골든 3중 비교를 적용했는가?

📚 References

📌 면책 조항 본 문서는 SoC 보안 IP 설계자를 위한 기술 브리핑이며, 본문에 인용된 FPGA / ASIC 벤치마크 수치(LUT · GE · Gbps)는 공정 · EDA 툴 · 합성 옵션에 따라 광범위하게 변동되는 레인지 추정치입니다. 실제 설계 결정 전에 본인 환경에서 재합성·재검증하시기 바랍니다. 보안 인증(FIPS 140-3, CC EAL 등) 적용을 위해서는 인증 기관의 최신 가이드라인을 별도로 확인하십시오.

📄 Raw Data

# SoC 보안 IP 설계를 위한 SHA-3 / SHAKE 종합 기술 브리핑

작성자: 보안 하드웨어 리서치 데스크
대상: SoC 보안 가속기 RTL 설계자
범위: 알고리즘 이론 → Verilog 구현 디테일 → PQC/경량 암호 연계 전망

---

## 1. 개요와 표준 위상 (Why SHA-3 / SHAKE)

**SHA-3**(Secure Hash Algorithm-3)는 NIST가 2015년 **FIPS 202**로 공식화한 차세대 해시 표준이며, 그 본체는 KECCAK 팀(Bertoni, Daemen, Peeters, Van Assche)이 설계한 **Keccak** 알고리즘이다. SHA-2가 Merkle–Damgård 구조를 따르는 반면, SHA-3는 **스펀지(Sponge) 구조**를 채택하여 **길이 연장 공격(length extension attack)**에 구조적으로 면역이며 동일 코어로 다양한 출력 길이를 만들 수 있다는 점에서 SoC IP화에 매우 유리하다.

**SHAKE**(SHAKE128, SHAKE256)는 같은 Keccak-p[1600, 24] 치환을 공유하는 **가변 길이 출력 함수(XOF, eXtendable-Output Function)**다. 즉 단일 하드웨어 코어로 (a) 고정 길이 해시(SHA3-224/256/384/512), (b) 임의 길이 의사난수/키 스트림(SHAKE128/256)을 모두 제공할 수 있다는 뜻이며, 이는 **PQC(양자내성암호) 가속기**가 SHA-3 코어를 마치 "암호 프리미티브 풀(pool)"처럼 호출하는 최근 트렌드와 정확히 맞물린다 (NIST FIPS 202).

**설계자 관점의 한 줄 요약:** SHA-3/SHAKE 코어 1개를 잘 설계하면 ① 무결성 해시 ② MAC(KMAC) ③ DRBG/스트림 ④ ML-KEM/ML-DSA의 빌딩블록까지 한 IP에서 커버할 수 있다.

---

## 2. 핵심 이론: 스펀지 구조와 1600-bit 상태

### 2.1 스펀지 파라미터
- 전체 상태 크기 $b = 1600$ 비트 (SHA-3 표준은 항상 Keccak-p[1600, 24]).
- $b = r + c$, 여기서 **rate $r$**는 외부와 XOR 되는 영역, **capacity $c$**는 외부 비공개 보안 마진.
- 표준별 파라미터:
  | 함수 | $r$ (bits) | $c$ (bits) | 출력 |
  |------|-----------:|-----------:|------|
  | SHA3-224 | 1152 | 448 | 224 |
  | SHA3-256 | 1088 | 512 | 256 |
  | SHA3-384 | 832  | 768 | 384 |
  | SHA3-512 | 576  | 1024 | 512 |
  | SHAKE128 | 1344 | 256 | 가변 |
  | SHAKE256 | 1088 | 512 | 가변 |

  capacity는 보안 강도의 절반과 직접 연동되므로(보안 ≈ $c/2$), **rate가 클수록 throughput은 높지만 보안 마진은 줄어든다.** SHAKE128이 rate 1344로 가장 빠른 이유다 (NIST FIPS 202).

### 2.2 상태 행렬
1600비트는 **5×5×64 (x, y, z)** 3차원 배열로 본다.
- **Lane**: $z$축 64-bit 워드. Verilog에서의 자연스러운 처리 단위.
- **Slice / Plane / Column / Row**: 각 라운드 함수가 접근하는 단면. $\theta$는 column, $\pi$는 lane 위치, $\rho$는 lane 내부 비트를 다룬다.

**Endianness 주의:** FIPS 202는 비트/바이트 매핑을 부록에 명시한다. 메시지 바이트의 **LSB가 lane의 z=0**에 들어가도록 매핑해야 하며, 이를 잘못 구현하면 NIST CAVP 테스트 벡터가 전부 깨진다.

---

## 3. 처리 단계 Step-by-Step (Verilog RTL 관점)

### Step 1. 패딩과 도메인 분리 (가장 흔한 실수 지점)
FIPS 202는 함수마다 **도메인 분리 비트**를 다르게 정의한다 (FIPS 202 §B.2 / Appendix B).

| 함수 | 부착 비트열 (LSB-first) | 바이트로 보면 첫 패드 바이트 |
|------|-------------------------|------------------------------|
| SHA3-* | `01` + `10*1` | `0x06` |
| SHAKE* | `1111` + `10*1` | `0x1F` |
| RawSHAKE | `11` + `10*1` | `0x07` |

즉 “SHAKE는 0x1F, SHA-3는 0x06”이라는 매직 바이트는 **LSB-first로 비트열을 더한 결과**이지, 임의로 정해진 magic이 아니다. RTL에서는 **마지막 블록의 마지막 바이트**에 도메인 비트를 OR로 삽입하고, **블록 마지막 비트**에 `1`을 OR해야 한다 (`pad10*1`의 마지막 1).

### Step 2. 흡수 단계 (Absorbing)
1. 1600-bit 상태 레지스터 $S$를 0으로 초기화.
2. 메시지를 $r$-bit 블록 $P_i$로 잘라, $S[0:r-1] \mathrel{\oplus}= P_i$ 수행.
3. $S \leftarrow \text{Keccak-f}[1600](S)$ (24 라운드 치환).
4. 모든 블록을 소진할 때까지 반복.

### Step 3. Keccak-f[1600] (라운드당 5단계, 총 24라운드)
1. **θ (Theta)** – 각 column의 패리티를 양옆 column과 XOR. 확산(diffusion) 담당. 선형.
2. **ρ (Rho)** – lane 내부 64-bit 회전. 회전량은 표로 사전정의된 상수. 하드웨어에서는 **순수 와이어링**이라 면적/지연 0에 가깝다.
3. **π (Pi)** – lane을 $5\times5$ 평면 안에서 재배치. 역시 **wiring-only**.
4. **χ (Chi)** – 유일한 비선형 단계. $A'[x] = A[x] \oplus ((\lnot A[x+1]) \land A[x+2])$. 혼돈(confusion)과 사이드채널 공격의 주 타깃.
5. **ι (Iota)** – round constant XOR. 24개의 RC는 LFSR로 사전 계산되어 ROM 또는 case문으로 둔다.

### Step 4. 짜내기 단계 (Squeezing)
- 출력 길이 $d$ 비트를 채울 때까지 $S[0:r-1]$을 출력 버퍼로 토해내고, 모자라면 다시 Keccak-f를 한 번 더 돌린다.
- SHA3-256/512처럼 $d \le r$인 경우는 squeeze 1회로 끝난다.
- SHAKE는 본질적으로 squeeze loop 위에서 돌아가므로 **streaming 인터페이스(valid/ready)** 가 필수.

---

## 4. Verilog / RTL 구체 설계 가이드

### 4.1 데이터패스 아키텍처 선택지
| 구조 | 1 hash 처리 시간 | 면적 | 용도 |
|------|------------------|------|------|
| **Iterative (1 round/clk)** | 24 cycles | 작음 | 범용 SoC, 가장 일반적 |
| **Unrolled / Pipelined** | 1 cycle/blk (이상) | 매우 큼 | 네트워크 라인레이트(40 Gbps+) |
| **Folded (e.g. 64-bit datapath)** | 수백 cycles | 매우 작음 | IoT, 스마트카드 |

업계 보고된 벤치마크 레인지 (Recent Keccak Hardware Surveys, 2024):
- **FPGA (Xilinx UltraScale+)**: Iterative 1-round 코어 ≈ 1.5k–2.5k LUT, 1–3 Gbps. 24-round Unrolled/Pipelined ≈ 10k–20k LUT, 30–40 Gbps+.
- **ASIC**: Iterative 코어 ≈ **20k–40k GE** (TSMC 7/12/28nm 추정치). 비트당 에너지 효율은 SHA-2보다 우수한 것으로 보고됨.

> 실수치는 공정/툴/파라미터에 매우 민감하므로, 위 수치는 **자료(2024년 서베이) 기준 레인지**로 받아들이고 본인 PDK에서 재측정해야 한다.

### 4.2 RTL 모듈 분할 권장안
```
keccak_top
 ├── pad_unit          : 도메인 비트 + pad10*1, byte-enable 처리
 ├── absorb_xor_mux    : state[0:r-1] ^= block
 ├── keccak_round      : θ → ρ → π → χ → ι (combinational, 1 round)
 ├── round_counter     : 0..23
 ├── rc_rom            : 24 × 64-bit round constants
 ├── state_reg         : reg [1599:0]  (또는 25 × [63:0] lane array)
 └── squeeze_unit      : 출력 r-bit 단위 시프트/스트리밍
```

### 4.3 자주 빠지는 함정 (Pitfalls)
- **1600-bit 단일 reg 선언**은 합성기에서 **routing congestion**을 유발한다. **5×5 lane array(`reg [63:0] A[0:4][0:4];`)**로 선언하면 θ/ρ/π를 인덱스 연산으로 깔끔하게 표현할 수 있고, FPGA에서는 필요시 `(* KEEP *)`, `(* RAM_STYLE *)` 지시어로 배치 힌트를 준다.
- **I/O 병목**: Keccak-f는 24 cycle이면 끝나는데 1600-bit를 32/64-bit AXI로 토하다 보면 오히려 데이터 전송이 더 오래 걸린다. **AXI4-Stream + DMA 또는 hash-and-DMA 통합**을 권장.
- **Constant-time 보장**: 알고리즘 자체는 데이터 비의존(constant-time)이지만, **valid/ready 핸드셰이킹과 패딩 처리 컨트롤러**에서 입력 길이에 따라 분기 시간이 새지 않도록 주의.
- **테스트 벡터**: NIST CAVP의 KAT(Known Answer Test) 및 **FIPS 202 Appendix B 예제**로 **각 라운드 중간 상태**까지 일치 검증해야 한다. 최종 다이제스트만 비교하면 θ/ρ 비트오더 버그를 놓치기 쉽다.

### 4.4 검증 흐름
1. **Golden model**: Keccak Team이 배포하는 C reference 또는 Python `hashlib.shake_*` / `hashlib.sha3_*`.
2. **단위 테스트**: 각 5-단계(θ, ρ, π, χ, ι) 별 입력/출력 비교.
3. **블록 단위**: Keccak-f[1600] 1회 vs 골든 모델.
4. **풀 함수**: SHA3-256, SHAKE128(out=4096-bit) KAT.
5. **랜덤화 stress + 코너**: 0-byte 메시지, $r-1$ byte 메시지(패딩이 두 블록 걸치는 케이스).

---

## 5. 사이드채널(SCA) 대응 — SoC 보안 IP의 사실상 의무

Keccak이 선형 4단계 + 비선형 1단계($\chi$)로 구성된 점은 **마스킹(masking)** 측면에서 큰 장점이다.

- **공격 표적**: $\chi$ 단계의 AND-NOT 연산이 DPA(Differential Power Analysis)의 주 타깃.
- **대응 기법**:
  - **Boolean masking** ($S = S_1 \oplus S_2$)을 기본으로,
  - **DOM(Domain-Oriented Masking)** 또는 **Threshold Implementation(TI)** 으로 share 간 상관을 제거.
- **비용 (Recent Keccak Hardware Surveys, 2024 인용)**: 2-share 마스킹 기준 **면적 약 2.5–3배, 지연 약 1.5배** 증가.
- **추가 권장**: 라운드 키/RC 주입 구간에 **랜덤 마스크 refresh**, 그리고 fault injection 대응을 위한 **redundancy 또는 round-recompute** 검사.

---

## 6. PQC(양자내성암호)와의 연계 — 이게 진짜 미래 수요다

NIST는 2024년 PQC 표준을 확정했으며, 그 핵심 알고리즘들이 **내부 해시/XOF로 SHA-3/SHAKE를 대량 호출**한다.

- **ML-KEM (FIPS 203, 구 Kyber)**: 키 생성·캡슐화 과정에서 **SHAKE128**(매트릭스 A 샘플링), **SHA3-256/512**(해시·KDF) 사용.
- **ML-DSA (FIPS 204, 구 Dilithium)**: 서명 시 **SHAKE256**으로 의사난수/도전값 생성.
- **SLH-DSA (FIPS 205, 구 SPHINCS+)**: SHA-3/SHAKE 변형이 핵심 PRF.

**SoC 설계 시사점:**
1. SHA-3 코어는 **단발 호출이 아니라 수십~수백 번 짧은 메시지로 호출**되는 패턴이 된다 → **세션/스테이트 캐싱**과 **빠른 상태 reset** 인터페이스가 throughput을 좌우한다.
2. SHAKE의 **중간 state를 외부에 노출/재로딩**할 수 있는 인터페이스(예: state save/restore)가 PQC 가속 시 필수.
3. KMAC, cSHAKE, TupleHash, ParallelHash(NIST SP 800-185)도 같은 코어로 처리 가능하므로 **명령 디코더에 함수 코드 필드**를 두는 설계가 일반적.

---

## 7. 경량 영역: ASCON과의 비교

NIST는 2023년 LWC(Lightweight Cryptography) 최종 표준으로 **ASCON 패밀리**를 선정했다.

| 항목 | SHA-3/Keccak | ASCON-Hash |
|------|--------------|------------|
| 내부 상태 | 1600-bit | **320-bit** |
| 구조 | Sponge | Sponge (유사) |
| 면적 | 기준 | **약 1/4 이하** |
| 타깃 | 범용/PQC/서버 | IoT, 센서, RFID급 |

**판단 가이드:** 칩이 PQC, TLS, 디스크 암호화 등 “큰 보안”을 다루면 SHA-3, 정말 좁은 IoT/센서 노드라면 ASCON-Hash가 합리적이다. 다만 **ASCON과 SHA-3는 대체재가 아니라 세그먼트가 다른 표준**이라는 점을 이해할 것 (NIST LWC 결과).

---

## 8. 향후 전망 (Outlook)

1. **PQC 의무화 흐름**과 함께 SHA-3/SHAKE 가속기는 **선택이 아닌 기본 IP**로 자리잡을 전망. 정부/국방/금융 SoC 스펙에서 FIPS 202/203/204 동시 지원 요구가 늘고 있다.
2. **하나의 Keccak 코어가 다용도로 재사용**되는 트렌드 — 해시, KMAC, DRBG, PQC 내부 PRF까지 — 이 강해지면서, 코어 자체의 절대 성능보다 **인터페이스 유연성(state save/restore, 도메인 코드, 스트리밍)** 이 차별 포인트가 된다.
3. **사이드채널 보호 내장형 IP**가 표준이 되어가고 있다. 마스킹·셔플링·redundancy 없이는 정부 인증(FIPS 140-3, CC EAL 등) 트랙에 올리기 어렵다.
4. **경량 + 양자내성 하이브리드 SoC**: ASCON(LWC) + SHA-3/SHAKE(PQC) 듀얼 IP를 같은 칩에 두는 설계가 IoT 게이트웨이/엣지에서 늘어날 것으로 보인다.

---

## 9. 설계자에게 주는 체크리스트 (요약)

- [ ] FIPS 202의 **도메인 비트(0x06 / 0x1F / 0x07)** 와 **pad10\*1**을 LSB-first 비트 단위로 정확히 구현했는가?
- [ ] 1600-bit 상태를 **5×5×64 lane 배열**로 모델링했는가? Endianness 매핑은 부록 그대로인가?
- [ ] θ/ρ/π/χ/ι 각 단계의 **중간 상태**가 골든 모델과 일치하는가? (CAVP KAT만으로는 부족)
- [ ] **iterative vs unrolled** 결정이 목표 throughput·면적·전력과 일치하는가?
- [ ] AXI4-Stream/DMA로 **I/O 병목**을 제거했는가?
- [ ] **사이드채널(DPA/fault)** 대응이 위협 모델에 맞게 들어갔는가?
- [ ] **SHAKE state save/restore**, 도메인 코드, KMAC/cSHAKE 확장 여지를 인터페이스에 남겼는가?
- [ ] 검증에 **NIST CAVP / FIPS 202 Appendix B / hashlib 골든** 3중 비교를 적용했는가?

---

> 라운드 간 모순 사항: 본 리서치 두 라운드에서 알고리즘 정의·파라미터·도메인 분리 비트·PQC 연계 기술에 대한 **모순된 진술은 발견되지 않았다.** 단, FPGA/ASIC 벤치마크 수치(LUT, GE, Gbps)는 공정·툴·구현 옵션에 따라 광범위하게 달라지는 “레인지 추정치”이므로, 절대값으로 인용하지 말고 본인 환경에서 재합성해 검증할 것을 권한다.
---

## References

- [NIST FIPS 202 (SHA-3 Standard)](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf)
- [Keccak Team Specifications](https://keccak.team/specifications.html)
- [NIST PQC Standards (FIPS 203/204/205)](https://csrc.nist.gov/projects/post-quantum-cryptography)

이 블로그 검색

Brave Ogu

구글 안티그래비티 완전 분석 — 모델·요금제·CLI 총정리