요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
1
Kernel Crypto API Architecture
2
==============================
4
Cipher algorithm types
5
----------------------
7
The kernel crypto API provides different API calls for the following
8
cipher types:
10
- Symmetric ciphers
12
- AEAD ciphers
14
- Message digest, including keyed message digest
16
- Random number generation
18
- User space interface
20
Ciphers And Templates
21
---------------------
23
The kernel crypto API provides implementations of single block ciphers
24
and message digests. In addition, the kernel crypto API provides
25
numerous "templates" that can be used in conjunction with the single
26
block ciphers and message digests. Templates include all types of block
27
chaining mode, the HMAC mechanism, etc.
29
Single block ciphers and message digests can either be directly used by
30
a caller or invoked together with a template to form multi-block ciphers
31
or keyed message digests.
33
A single block cipher may even be called with multiple templates.
34
However, templates cannot be used without a single cipher.
36
See /proc/crypto and search for "name". For example:
38
- aes
40
- ecb(aes)
42
- cmac(aes)
44
- ccm(aes)
46
- rfc4106(gcm(aes))
48
- sha1
50
- hmac(sha1)
52
- authenc(hmac(sha1),cbc(aes))
54
In these examples, "aes" and "sha1" are the ciphers and all others are
55
the templates.
57
Synchronous And Asynchronous Operation
58
--------------------------------------
60
The kernel crypto API provides synchronous and asynchronous API
61
operations.
63
When using the synchronous API operation, the caller invokes a cipher
64
operation which is performed synchronously by the kernel crypto API.
65
That means, the caller waits until the cipher operation completes.
66
Therefore, the kernel crypto API calls work like regular function calls.
67
For synchronous operation, the set of API calls is small and
68
conceptually similar to any other crypto library.
70
Asynchronous operation is provided by the kernel crypto API which
71
implies that the invocation of a cipher operation will complete almost
72
instantly. That invocation triggers the cipher operation but it does not
73
signal its completion. Before invoking a cipher operation, the caller
74
must provide a callback function the kernel crypto API can invoke to
75
signal the completion of the cipher operation. Furthermore, the caller
76
must ensure it can handle such asynchronous events by applying
77
appropriate locking around its data. The kernel crypto API does not
78
perform any special serialization operation to protect the caller's data
79
integrity.
81
Crypto API Cipher References And Priority
82
-----------------------------------------
84
A cipher is referenced by the caller with a string. That string has the
85
following semantics:
87
::
89
template(single block cipher)
92
where "template" and "single block cipher" is the aforementioned
93
template and single block cipher, respectively. If applicable,
94
additional templates may enclose other templates, such as
96
::
98
template1(template2(single block cipher)))
101
The kernel crypto API may provide multiple implementations of a template
102
or a single block cipher. For example, AES on newer Intel hardware has
103
the following implementations: AES-NI, assembler implementation, or
104
straight C. Now, when using the string "aes" with the kernel crypto API,
105
which cipher implementation is used? The answer to that question is the
106
priority number assigned to each cipher implementation by the kernel
107
crypto API. When a caller uses the string to refer to a cipher during
108
initialization of a cipher handle, the kernel crypto API looks up all
109
implementations providing an implementation with that name and selects
110
the implementation with the highest priority.
112
Now, a caller may have the need to refer to a specific cipher
113
implementation and thus does not want to rely on the priority-based
114
selection. To accommodate this scenario, the kernel crypto API allows
115
the cipher implementation to register a unique name in addition to
116
common names. When using that unique name, a caller is therefore always
117
sure to refer to the intended cipher implementation.
119
The list of available ciphers is given in /proc/crypto. However, that
120
list does not specify all possible permutations of templates and
121
ciphers. Each block listed in /proc/crypto may contain the following
122
information -- if one of the components listed as follows are not
123
applicable to a cipher, it is not displayed:
125
- name: the generic name of the cipher that is subject to the
126
priority-based selection -- this name can be used by the cipher
127
allocation API calls (all names listed above are examples for such
128
generic names)
130
- driver: the unique name of the cipher -- this name can be used by the
131
cipher allocation API calls
133
- module: the kernel module providing the cipher implementation (or
134
"kernel" for statically linked ciphers)
136
- priority: the priority value of the cipher implementation
138
- refcnt: the reference count of the respective cipher (i.e. the number
139
of current consumers of this cipher)
141
- selftest: specification whether the self test for the cipher passed
143
- type:
145
- skcipher for symmetric key ciphers
147
- cipher for single block ciphers that may be used with an
148
additional template
150
- shash for synchronous message digest
152
- ahash for asynchronous message digest
154
- aead for AEAD cipher type
156
- compression for compression type transformations
158
- rng for random number generator
160
- kpp for a Key-agreement Protocol Primitive (KPP) cipher such as
161
an ECDH or DH implementation
163
- blocksize: blocksize of cipher in bytes
165
- keysize: key size in bytes
167
- ivsize: IV size in bytes
169
- seedsize: required size of seed data for random number generator
171
- digestsize: output size of the message digest
173
- geniv: IV generator (obsolete)
175
Key Sizes
176
---------
178
When allocating a cipher handle, the caller only specifies the cipher
179
type. Symmetric ciphers, however, typically support multiple key sizes
180
(e.g. AES-128 vs. AES-192 vs. AES-256). These key sizes are determined
181
with the length of the provided key. Thus, the kernel crypto API does
182
not provide a separate way to select the particular symmetric cipher key
183
size.
185
Cipher Allocation Type And Masks
186
--------------------------------
188
The different cipher handle allocation functions allow the specification
189
of a type and mask flag. Both parameters have the following meaning (and
190
are therefore not covered in the subsequent sections).
192
The type flag specifies the type of the cipher algorithm. The caller
193
usually provides a 0 when the caller wants the default handling.
194
Otherwise, the caller may provide the following selections which match
195
the aforementioned cipher types:
197
- CRYPTO_ALG_TYPE_CIPHER Single block cipher
199
- CRYPTO_ALG_TYPE_AEAD Authenticated Encryption with Associated Data
200
(MAC)
202
- CRYPTO_ALG_TYPE_KPP Key-agreement Protocol Primitive (KPP) such as
203
an ECDH or DH implementation
205
- CRYPTO_ALG_TYPE_HASH Raw message digest
207
- CRYPTO_ALG_TYPE_SHASH Synchronous multi-block hash
209
- CRYPTO_ALG_TYPE_AHASH Asynchronous multi-block hash
211
- CRYPTO_ALG_TYPE_RNG Random Number Generation
213
- CRYPTO_ALG_TYPE_AKCIPHER Asymmetric cipher
215
- CRYPTO_ALG_TYPE_SIG Asymmetric signature
217
- CRYPTO_ALG_TYPE_PCOMPRESS Enhanced version of
218
CRYPTO_ALG_TYPE_COMPRESS allowing for segmented compression /
219
decompression instead of performing the operation on one segment
220
only. CRYPTO_ALG_TYPE_PCOMPRESS is intended to replace
221
CRYPTO_ALG_TYPE_COMPRESS once existing consumers are converted.
223
The mask flag restricts the type of cipher. The only allowed flag is
224
CRYPTO_ALG_ASYNC to restrict the cipher lookup function to
225
asynchronous ciphers. Usually, a caller provides a 0 for the mask flag.
227
When the caller provides a mask and type specification, the caller
228
limits the search the kernel crypto API can perform for a suitable
229
cipher implementation for the given cipher name. That means, even when a
230
caller uses a cipher name that exists during its initialization call,
231
the kernel crypto API may not select it due to the used type and mask
232
field.
234
Internal Structure of Kernel Crypto API
235
---------------------------------------
237
The kernel crypto API has an internal structure where a cipher
238
implementation may use many layers and indirections. This section shall
239
help to clarify how the kernel crypto API uses various components to
240
implement the complete cipher.
242
The following subsections explain the internal structure based on
243
existing cipher implementations. The first section addresses the most
244
complex scenario where all other scenarios form a logical subset.
246
Generic AEAD Cipher Structure
247
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
249
The following ASCII art decomposes the kernel crypto API layers when
250
using the AEAD cipher with the automated IV generation. The shown
251
example is used by the IPSEC layer.
253
For other use cases of AEAD ciphers, the ASCII art applies as well, but
254
the caller may not use the AEAD cipher with a separate IV generator. In
255
this case, the caller must generate the IV.
257
The depicted example decomposes the AEAD cipher of GCM(AES) based on the
258
generic C implementations (gcm.c, aes-generic.c, ctr.c, ghash-generic.c,
259
seqiv.c). The generic implementation serves as an example showing the
260
complete logic of the kernel crypto API.
262
It is possible that some streamlined cipher implementations (like
263
AES-NI) provide implementations merging aspects which in the view of the
264
kernel crypto API cannot be decomposed into layers any more. In case of
265
the AES-NI implementation, the CTR mode, the GHASH implementation and
266
the AES cipher are all merged into one cipher implementation registered
267
with the kernel crypto API. In this case, the concept described by the
268
following ASCII art applies too. However, the decomposition of GCM into
269
the individual sub-components by the kernel crypto API is not done any
270
more.
272
Each block in the following ASCII art is an independent cipher instance
273
obtained from the kernel crypto API. Each block is accessed by the
274
caller or by other blocks using the API functions defined by the kernel
275
crypto API for the cipher implementation type.
277
The blocks below indicate the cipher type as well as the specific logic
278
implemented in the cipher.
280
The ASCII art picture also indicates the call structure, i.e. who calls
281
which component. The arrows point to the invoked block where the caller
282
uses the API applicable to the cipher type specified for the block.
284
::
287
kernel crypto API | IPSEC Layer
288
|
289
+-----------+ |
290
| | (1)
291
| aead | <----------------------------------- esp_output
292
| (seqiv) | ---+
293
+-----------+ |
294
| (2)
295
+-----------+ |
296
| | <--+ (2)
297
| aead | <----------------------------------- esp_input
298
| (gcm) | ------------+
299
+-----------+ |
300
| (3) | (5)
301
v v
302
+-----------+ +-----------+
303
| | | |
304
| skcipher | | ahash |
305
| (ctr) | ---+ | (ghash) |
306
+-----------+ | +-----------+
307
|
308
+-----------+ | (4)
309
| | <--+
310
| cipher |
311
| (aes) |
312
+-----------+
316
The following call sequence is applicable when the IPSEC layer triggers
317
an encryption operation with the esp_output function. During
318
configuration, the administrator set up the use of seqiv(rfc4106(gcm(aes)))
319
as the cipher for ESP. The following call sequence is now depicted in
320
the ASCII art above:
322
1. esp_output() invokes crypto_aead_encrypt() to trigger an
323
encryption operation of the AEAD cipher with IV generator.
325
The SEQIV generates the IV.
327
2. Now, SEQIV uses the AEAD API function calls to invoke the associated
328
AEAD cipher. In our case, during the instantiation of SEQIV, the
329
cipher handle for GCM is provided to SEQIV. This means that SEQIV
330
invokes AEAD cipher operations with the GCM cipher handle.
332
During instantiation of the GCM handle, the CTR(AES) and GHASH
333
ciphers are instantiated. The cipher handles for CTR(AES) and GHASH
334
are retained for later use.
336
The GCM implementation is responsible to invoke the CTR mode AES and
337
the GHASH cipher in the right manner to implement the GCM
338
specification.
340
3. The GCM AEAD cipher type implementation now invokes the SKCIPHER API
341
with the instantiated CTR(AES) cipher handle.
343
During instantiation of the CTR(AES) cipher, the CIPHER type
344
implementation of AES is instantiated. The cipher handle for AES is
345
retained.
347
That means that the SKCIPHER implementation of CTR(AES) only
348
implements the CTR block chaining mode. After performing the block
349
chaining operation, the CIPHER implementation of AES is invoked.
351
4. The SKCIPHER of CTR(AES) now invokes the CIPHER API with the AES
352
cipher handle to encrypt one block.
354
5. The GCM AEAD implementation also invokes the GHASH cipher
355
implementation via the AHASH API.
357
When the IPSEC layer triggers the esp_input() function, the same call
358
sequence is followed with the only difference that the operation starts
359
with step (2).
361
Generic Block Cipher Structure
362
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
364
Generic block ciphers follow the same concept as depicted with the ASCII
365
art picture above.
367
For example, CBC(AES) is implemented with cbc.c, and aes-generic.c. The
368
ASCII art picture above applies as well with the difference that only
369
step (4) is used and the SKCIPHER block chaining mode is CBC.
371
Generic Keyed Message Digest Structure
372
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
374
Keyed message digest implementations again follow the same concept as
375
depicted in the ASCII art picture above.
377
For example, HMAC(SHA256) is implemented with hmac.c and
378
sha256_generic.c. The following ASCII art illustrates the
379
implementation:
381
::
384
kernel crypto API | Caller
385
|
386
+-----------+ (1) |
387
| | <------------------ some_function
388
| ahash |
389
| (hmac) | ---+
390
+-----------+ |
391
| (2)
392
+-----------+ |
393
| | <--+
394
| shash |
395
| (sha256) |
396
+-----------+
400
The following call sequence is applicable when a caller triggers an HMAC
401
operation:
403
1. The AHASH API functions are invoked by the caller. The HMAC
404
implementation performs its operation as needed.
406
During initialization of the HMAC cipher, the SHASH cipher type of
407
SHA256 is instantiated. The cipher handle for the SHA256 instance is
408
retained.
410
At one time, the HMAC implementation requires a SHA256 operation
411
where the SHA256 cipher handle is used.
413
2. The HMAC instance now invokes the SHASH API with the SHA256 cipher
414
handle to calculate the message digest.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
커널 Crypto API 아키텍처
1-3커널 Crypto API 아키텍처
암호 알고리즘 유형
4-19암호 알고리즘 유형
커널 Crypto API는 다음 암호 유형마다 서로 다른 API 호출을 제공합니다.
- 대칭 암호(Symmetric ciphers)
- AEAD 암호
- 키 기반 message digest를 포함한 message digest
- 난수 생성
- 사용자 공간 인터페이스
암호와 template
20-56암호와 template
커널 Crypto API는 단일 블록 암호와 message digest 구현을 제공합니다. 또한 단일 블록 암호 및 message digest와 함께 사용할 수 있는 여러 `template`을 제공합니다. Template에는 모든 종류의 block chaining mode와 HMAC 메커니즘 등이 포함됩니다.
호출자는 단일 블록 암호와 message digest를 직접 사용할 수도 있고, template과 함께 호출하여 다중 블록 암호 또는 키 기반 message digest를 구성할 수도 있습니다.
하나의 단일 블록 암호를 여러 template으로 감싸 호출할 수도 있습니다. 그러나 단일 암호 없이 template만 사용할 수는 없습니다.
`/proc/crypto`에서 `name`을 검색하십시오. 예시는 다음과 같습니다.
- `aes`
- `ecb(aes)`
- `cmac(aes)`
- `ccm(aes)`
- `rfc4106(gcm(aes))`
- `sha1`
- `hmac(sha1)`
- `authenc(hmac(sha1),cbc(aes))`
이 예에서 `aes`와 `sha1`은 암호이고 나머지는 모두 template입니다.
동기 및 비동기 연산
57-80동기 및 비동기 연산
커널 Crypto API는 동기 API 연산과 비동기 API 연산을 제공합니다.
동기 API 연산을 사용할 때 호출자는 커널 Crypto API가 동기적으로 수행하는 암호 연산을 호출합니다. 즉, 호출자는 암호 연산이 끝날 때까지 기다립니다. 따라서 커널 Crypto API 호출은 일반 함수 호출처럼 동작합니다. 동기 연산용 API 호출 집합은 작으며 개념적으로 다른 암호 라이브러리와 유사합니다.
비동기 연산에서는 암호 연산 호출 자체가 거의 즉시 끝납니다. 이 호출은 암호 연산을 시작하지만 완료를 알리지는 않습니다. 호출자는 암호 연산을 시작하기 전에 완료를 알리기 위해 커널 Crypto API가 호출할 callback 함수를 제공해야 합니다. 또한 자신의 데이터에 적절한 locking을 적용하여 비동기 event를 처리할 수 있도록 보장해야 합니다. 커널 Crypto API는 호출자 데이터의 무결성을 보호하기 위한 별도의 serialization 연산을 수행하지 않습니다.
Crypto API 암호 참조와 우선순위
81-174Crypto API 암호 참조와 우선순위
호출자는 문자열로 암호를 참조합니다. 이 문자열은 다음 의미를 갖습니다.
::
template(single block cipher)
여기서 `template`과 `single block cipher`는 각각 앞에서 설명한 template과 단일 블록 암호입니다. 필요한 경우 다음과 같이 추가 template이 다른 template을 감쌀 수 있습니다.
::
template1(template2(single block cipher)))
커널 Crypto API는 하나의 template이나 단일 블록 암호에 여러 구현을 제공할 수 있습니다. 예를 들어 최신 Intel 하드웨어의 AES에는 AES-NI, assembler 구현, 순수 C 구현이 있습니다. `aes` 문자열로 암호 handle을 초기화하면 Crypto API는 그 이름을 제공하는 모든 구현을 찾고, 각 구현에 부여된 우선순위 값이 가장 높은 구현을 선택합니다.
호출자가 우선순위 기반 선택에 의존하지 않고 특정 구현을 지정해야 할 수도 있습니다. 이를 위해 암호 구현은 공통 이름과 별도로 고유 이름을 등록할 수 있습니다. 고유 이름을 사용하면 의도한 구현을 확실히 참조할 수 있습니다.
사용 가능한 암호 목록은 `/proc/crypto`에 있습니다. 다만 이 목록은 template과 암호의 가능한 모든 조합을 열거하지 않습니다. `/proc/crypto`의 각 블록에는 다음 정보가 포함될 수 있으며, 특정 암호에 적용되지 않는 항목은 표시되지 않습니다.
- `name`: 우선순위 기반 선택의 대상인 암호의 일반 이름이며 암호 할당 API에서 사용할 수 있습니다.
- `driver`: 암호의 고유 이름이며 암호 할당 API에서 사용할 수 있습니다.
- `module`: 암호 구현을 제공하는 커널 모듈입니다. 정적으로 연결된 암호는 `kernel`로 표시됩니다.
- `priority`: 암호 구현의 우선순위 값입니다.
- `refcnt`: 해당 암호의 참조 횟수, 즉 현재 사용자의 수입니다.
- `selftest`: 암호 self test의 통과 여부입니다.
- `type = skcipher`: 대칭 키 암호입니다.
- `type = cipher`: 추가 template과 함께 사용할 수 있는 단일 블록 암호입니다.
- `type = shash`: 동기 message digest입니다.
- `type = ahash`: 비동기 message digest입니다.
- `type = aead`: AEAD 암호 유형입니다.
- `type = compression`: 압축 유형 transform입니다.
- `type = rng`: 난수 생성기입니다.
- `type = kpp`: ECDH 또는 DH 구현과 같은 Key-agreement Protocol Primitive(KPP) 암호입니다.
- `blocksize`: byte 단위 암호 블록 크기입니다.
- `keysize`: byte 단위 키 크기입니다.
- `ivsize`: byte 단위 IV 크기입니다.
- `seedsize`: 난수 생성기에 필요한 seed data 크기입니다.
- `digestsize`: message digest의 출력 크기입니다.
- `geniv`: IV 생성기이며 현재는 폐기되었습니다.
키 크기
175-184키 크기
암호 handle을 할당할 때 호출자는 암호 유형만 지정합니다. 그러나 대칭 암호는 일반적으로 여러 키 크기를 지원합니다. 예를 들어 AES-128, AES-192, AES-256이 있습니다. 키 크기는 제공된 키의 길이로 결정되므로 커널 Crypto API는 특정 대칭 암호 키 크기를 별도로 선택하는 방법을 제공하지 않습니다.
암호 할당 유형과 mask
185-233암호 할당 유형과 mask
여러 암호 handle 할당 함수에서는 type flag와 mask flag를 지정할 수 있습니다. 두 매개변수의 의미는 다음과 같으며 이후 절에서는 반복해서 설명하지 않습니다.
Type flag는 암호 알고리즘 유형을 지정합니다. 기본 처리를 원하면 보통 0을 전달합니다. 그 밖에는 앞에서 설명한 암호 유형에 대응하는 다음 값을 사용할 수 있습니다.
- `CRYPTO_ALG_TYPE_CIPHER`: 단일 블록 암호
- `CRYPTO_ALG_TYPE_AEAD`: Associated Data를 포함한 인증 암호화(MAC)
- `CRYPTO_ALG_TYPE_KPP`: ECDH 또는 DH 구현과 같은 Key-agreement Protocol Primitive(KPP)
- `CRYPTO_ALG_TYPE_HASH`: raw message digest
- `CRYPTO_ALG_TYPE_SHASH`: 동기 다중 블록 hash
- `CRYPTO_ALG_TYPE_AHASH`: 비동기 다중 블록 hash
- `CRYPTO_ALG_TYPE_RNG`: 난수 생성
- `CRYPTO_ALG_TYPE_AKCIPHER`: 비대칭 암호
- `CRYPTO_ALG_TYPE_SIG`: 비대칭 서명
- `CRYPTO_ALG_TYPE_PCOMPRESS`: 하나의 segment만 처리하지 않고 분할 압축·해제를 허용하는 `CRYPTO_ALG_TYPE_COMPRESS`의 확장 버전입니다. 기존 사용자가 전환되면 이를 대체하기 위한 유형입니다.
Mask flag는 암호 유형을 제한합니다. 허용되는 flag는 암호 조회를 비동기 암호로 제한하는 `CRYPTO_ALG_ASYNC`뿐입니다. 일반적으로 호출자는 mask flag에 0을 전달합니다.
호출자가 mask와 type을 지정하면 주어진 암호 이름에 적합한 구현을 찾는 Crypto API의 검색 범위가 제한됩니다. 따라서 초기화 호출에서 존재하는 이름을 사용하더라도 type과 mask 값 때문에 해당 구현이 선택되지 않을 수 있습니다.
커널 Crypto API의 내부 구조
234-245커널 Crypto API의 내부 구조
커널 Crypto API의 내부에서는 하나의 암호 구현이 여러 계층과 간접 참조를 사용할 수 있습니다. 이 절은 Crypto API가 여러 구성 요소를 사용해 완전한 암호를 구현하는 방식을 설명합니다.
다음 하위 절은 기존 암호 구현을 바탕으로 내부 구조를 설명합니다. 첫 절은 가장 복잡한 시나리오를 다루며, 다른 시나리오는 논리적으로 그 일부입니다.
일반 AEAD 암호 구조
246-360일반 AEAD 암호 구조
다음 구조도는 자동 IV 생성을 사용하는 AEAD 암호의 커널 Crypto API 계층을 분해합니다. 표시된 예는 IPSEC 계층에서 사용됩니다.
다른 AEAD 사용 사례에도 같은 구조가 적용되지만 호출자가 별도의 IV 생성기를 결합하지 않을 수 있습니다. 이 경우 호출자가 IV를 생성해야 합니다.
예시는 일반 C 구현인 `gcm.c`, `aes-generic.c`, `ctr.c`, `ghash-generic.c`, `seqiv.c`를 기반으로 GCM(AES) AEAD 암호를 분해합니다. 이 일반 구현은 커널 Crypto API의 전체 논리를 보여 줍니다.
AES-NI처럼 간소화된 구현은 Crypto API 관점에서 더 분해할 수 없는 요소를 하나로 합칠 수 있습니다. AES-NI 구현에서는 CTR mode, GHASH 구현, AES 암호가 하나의 Crypto API 등록 구현으로 합쳐집니다. 아래 개념은 여전히 적용되지만 Crypto API가 GCM을 개별 하위 구성 요소로 나누지는 않습니다.
구조도의 각 블록은 커널 Crypto API에서 얻은 독립적인 암호 instance입니다. 호출자나 다른 블록은 해당 암호 구현 유형의 API 함수를 사용해 각 블록에 접근합니다. 블록에는 암호 유형과 구현 논리가 표시되며 화살표는 호출 관계와 호출되는 블록을 가리킵니다.
IPSEC esp_output (1)→AEAD seqiv→AEAD gcm
IPSEC esp_input (2)→AEAD gcm
AEAD gcm (3)→SKCIPHER ctr→CIPHER aes (4)
AEAD gcm (5)→AHASH ghash
IPSEC의 출력·입력 경로에서 SEQIV, GCM, CTR(AES), GHASH가 호출되는 구조입니다.
IPSEC 계층이 `esp_output()`으로 암호화 연산을 시작하고 관리자가 ESP 암호를 `seqiv(rfc4106(gcm(aes)))`로 구성한 경우 위 구조도의 호출 순서는 다음과 같습니다.
- 1. `esp_output()`이 `crypto_aead_encrypt()`를 호출하여 IV 생성기가 결합된 AEAD 암호화를 시작합니다. SEQIV가 IV를 생성합니다.
- 2. SEQIV가 AEAD API로 연결된 GCM 암호를 호출합니다. SEQIV를 만들 때 GCM handle이 제공됩니다. GCM handle을 만들 때 CTR(AES)와 GHASH 암호도 생성되고 이후 사용을 위해 handle이 유지됩니다. GCM 구현은 GCM 규격에 맞게 CTR mode AES와 GHASH를 호출합니다.
- 3. GCM AEAD 구현이 생성된 CTR(AES) handle로 SKCIPHER API를 호출합니다. CTR(AES)를 만들 때 AES의 CIPHER 구현도 생성되고 handle이 유지됩니다. CTR(AES)의 SKCIPHER 구현은 CTR block chaining mode만 구현하며 chaining 처리 후 AES CIPHER 구현을 호출합니다.
- 4. CTR(AES)의 SKCIPHER가 AES handle로 CIPHER API를 호출해 한 블록을 암호화합니다.
- 5. GCM AEAD 구현은 AHASH API를 통해 GHASH 구현도 호출합니다.
IPSEC 계층이 `esp_input()`을 호출하면 연산이 2단계에서 시작한다는 점만 다르고 같은 호출 순서를 따릅니다.
일반 블록 암호 구조
361-370일반 블록 암호 구조
일반 블록 암호는 위 구조도와 같은 개념을 따릅니다. 예를 들어 CBC(AES)는 `cbc.c`와 `aes-generic.c`로 구현됩니다. 이 경우 4단계만 사용하며 SKCIPHER block chaining mode가 CBC라는 점이 다릅니다.
일반 키 기반 message digest 구조
371-414일반 키 기반 message digest 구조
키 기반 message digest 구현도 위 구조도와 같은 개념을 따릅니다. 예를 들어 HMAC(SHA256)은 `hmac.c`와 `sha256_generic.c`로 구현됩니다.
Caller some_function (1)→AHASH hmac→SHASH sha256 (2)
호출자가 AHASH HMAC을 시작하면 HMAC instance가 SHASH SHA256을 사용해 digest를 계산합니다.
호출자가 HMAC 연산을 시작할 때 적용되는 호출 순서는 다음과 같습니다.
- 1. 호출자가 AHASH API 함수를 호출하고 HMAC 구현이 필요한 연산을 수행합니다. HMAC 암호를 초기화할 때 SHA256의 SHASH 암호 유형이 생성되고 SHA256 instance handle이 유지됩니다. HMAC 구현이 SHA256 연산을 필요로 할 때 이 handle을 사용합니다.
- 2. HMAC instance가 SHA256 handle로 SHASH API를 호출하여 message digest를 계산합니다.
요약과 해설
architecture.rst:1-414이 문서는 Linux 커널 Crypto API가 알고리즘과 template을 조합하고, 이름과 우선순위로 구현을 선택하며, type·mask로 검색 범위를 제한하는 방식을 설명합니다.
후반부는 IPSEC의 GCM(AES) 경로를 AEAD SEQIV와 GCM, SKCIPHER CTR(AES), CIPHER AES, AHASH GHASH 계층으로 분해하고 HMAC(SHA256)의 AHASH·SHASH 관계도 보여 줍니다. 원문의 두 ASCII 그림은 같은 호출 관계를 유지하는 구조화 도식으로 다시 구성했습니다.