ref: RFC3961
An encryption mechanism must define the following properties and operations:
1. Protocol Key Format
Specifies which characters (octet string) can appear in a valid key.
For keys that require special encoding, it must specify how to encode them.
For encryption mechanisms that don’t have
<span>perfectly dense key spaces</span>, this will describe the representation used for encoding keys.
There is no need to specify how to encode invalid keys, and all rules for generating keys should avoid producing invalid keys.
2. Specific Key Structure
Describes the keys derived from the selected key and how they are used for encryption, decryption, or checksum calculation.
For example: it may be a key, or a set of keys, or a combination of the original key and some additional data.
It is recommended to use one or more keys derived from the original key using a
<span>one-way key derivation function</span>.
3. Required Checksum Mechanism
Indicates the checksum mechanism provided by this encryption mechanism.
Since Kerberos does not have a built-in mechanism for negotiating checksum mechanisms, once the encryption mechanism is determined, the corresponding checksum mechanism provided by that encryption mechanism must be used.
4. Key-Generation Seed Length K
This is the length of the random bit string required by the <span>random-to-key</span> function to generate keys using the current encryption scheme.
This must be a fixed value.
5. Key Generation Functions
In many cases, keys must be generated based on different types of input.
All functions must specify how to correctly generate keys and must avoid generating keys that severely compromise data confidentiality.
6. String-to-Key
<span>string-to-key (UTF-8 string, UTF-8 string, opaque) -> (protocol-key)</span>
This function generates a key from two strings and an opaque data.
Typically, one of the two strings is the <span>user's password</span>, and the other is the <span>salt</span>.
This salt is intended to generate different keys from the same password for different users or realms.
(it’s intended to produce different keys from the same password for different users or realms)
The third parameter is an opaque data used to specify parameters related to the encryption mechanism.
Since doing so implies knowledge of a specific encryption system, generating non-default parameter values should be an uncommon operation, and normal Kerberos applications should be able to treat this parameter block as an opaque object provided by the KDC or default to some specific mechanism-related constant values.
The string-to-key function should be a one-way function, so that leaking a user key in one realm does not leak it in another realm, even if the same password is used (with different salt values).
7. Random-to-Key
<span>random-to-key (bitstring[k]) -> (protocol-key)</span>
This function generates a key from a random bit string of a specific size.
8. Key-Derivation
<span>key-derivation (protocol-key, integer) -> (specific-key)</span>
In this function, the integer parameter is the key usage value.
Assume the attacker knows the Key usage value.
9. String-to-Key Parameter Format
Specifies the format of the <span>opaque</span> parameter that can be passed to <span>string-to-key</span>.
As mentioned above, this should be treated as opaque for most applications.
10. Default String-to-Key Parameters (Octet String)
The default values specified here are used when applications (Kerberos or others) do not explicitly specify the corresponding parameters.
11. Cipher State
It describes all the information that can be transferred from one operation to the next during the encryption or decryption process using a specific key.
For example:
The IV (initial vector) used in the block encryption process in CBC mode.
Nonces or other data that may be used in other encryption modes.
This state cannot be empty, and it must affect the entire encryption and decryption process.
When the cipher state is transferred from one operation to another, it ensures that the decryption order is consistent with the encryption order.
12. Initial Cipher State
<span>initial cipher state (specific-key, direction) -> (state)</span>
Specifies how to handle the cipher state.
13. Encrypt
<span>encrypt (specific-key, state, octet string) -> (state, octet string)</span>
This function takes a specific key, cipher state, and a non-empty plaintext, generating ciphertext and a new cipher state.
If the underlying encryption algorithm does not provide integrity protection (e.g., DES CBC), then additional MAC algorithms or signatures must be used.
Some random factors (e.g., confounders) should be included so that observers cannot tell whether two messages contain the same plaintext, even if the cipher state and specific keys are the same.
14. Decrypt
<span>decrypt (specific-key, state, octet string) -> (state, octet string)</span>
This function takes a specific key, cipher state, and a non-empty ciphertext, verifies message integrity, and if the integrity check is successful, outputs a plaintext and a new cipher state.
15. Pseudo-Random
<span>pseudo-random (protocol-key, octet-string) -> (octet-string)</span>
A pseudo-random function, abbreviated as <span>PRF</span>.
This pseudo-random function should generate an octet string of some size that is independent of the octet string input.
It should guarantee that even if the output is public, it should not leak the input key.
Checksum General Principles
A checksum mechanism must define the following properties and operations:
1. Associated Encryption Algorithm (s)
This indicates which types of encryption keys this checksum mechanism can be used with.
A keyed checksum algorithm can be used with one or more encryption algorithms if the following parameters are the same:
- key format
- string-to-key function
- default string-to-key parameters
- key derivation function
An unkeyed checksum algorithm can be used with any encryption algorithm.
2. Get_MIC Function
This function generates a MIC token for a given specific key and message, which can be used to verify the integrity of the related message.
This function does not need to return the same deterministic result every time it is used; it only needs to generate a token that the <span>verify_mic</span> function can check.
3. Verify_MIC Function
Given a specific key, message, and MIC token, this function can be used to check whether the integrity of the message has been compromised.
For deterministic <span>get_mic</span> functions, the corresponding <span>verify_mic</span> may simply generate another checksum and compare the two.
<span>get_mic</span> and <span>verify_mic</span> functions must accept arbitrary-length input. If padding is required, the format of the padding must be provided.