|
53 | 53 | #define MBEDTLS_ERR_AES_INVALID_KEY_LENGTH -0x0020 /**< Invalid key length. */
|
54 | 54 | #define MBEDTLS_ERR_AES_INVALID_INPUT_LENGTH -0x0022 /**< Invalid data input length. */
|
55 | 55 |
|
56 |
| -/* Error codes in range 0x0023-0x0025 */ |
| 56 | +/* Error codes in range 0x0021-0x0025 */ |
| 57 | +#define MBEDTLS_ERR_AES_BAD_INPUT_DATA -0x0021 /**< Invalid input data. */ |
57 | 58 | #define MBEDTLS_ERR_AES_FEATURE_UNAVAILABLE -0x0023 /**< Feature not available. For example, an unsupported AES key size. */
|
58 | 59 | #define MBEDTLS_ERR_AES_HW_ACCEL_FAILED -0x0025 /**< AES hardware accelerator failed. */
|
59 | 60 |
|
@@ -309,7 +310,49 @@ int mbedtls_aes_crypt_cfb8( mbedtls_aes_context *ctx,
|
309 | 310 | * must use the context initialized with mbedtls_aes_setkey_enc()
|
310 | 311 | * for both #MBEDTLS_AES_ENCRYPT and #MBEDTLS_AES_DECRYPT.
|
311 | 312 | *
|
312 |
| - * \warning You must keep the maximum use of your counter in mind. |
| 313 | + * \warning You must never reuse a nonce value with the same key. Doing so |
| 314 | + * would void the encryption for the two messages encrypted with |
| 315 | + * the same nonce and key. |
| 316 | + * |
| 317 | + * There are two common strategies for managing nonces with CTR: |
| 318 | + * |
| 319 | + * 1. You can handle everything as a single message processed over |
| 320 | + * successive calls to this function. In that case, you want to |
| 321 | + * set \p nonce_counter and \p nc_off to 0 for the first call, and |
| 322 | + * then preserve the values of \p nonce_counter, \p nc_off and \p |
| 323 | + * stream_block across calls to this function as they will be |
| 324 | + * updated by this function. |
| 325 | + * |
| 326 | + * With this strategy, you must not encrypt more than 2**128 |
| 327 | + * blocks of data with the same key. |
| 328 | + * |
| 329 | + * 2. You can encrypt separate messages by dividing the \p |
| 330 | + * nonce_counter buffer in two areas: the first one used for a |
| 331 | + * per-message nonce, handled by yourself, and the second one |
| 332 | + * updated by this function internally. |
| 333 | + * |
| 334 | + * For example, you might reserve the first 12 bytes for the |
| 335 | + * per-message nonce, and the last 4 bytes for internal use. In that |
| 336 | + * case, before calling this function on a new message you need to |
| 337 | + * set the first 12 bytes of \p nonce_counter to your chosen nonce |
| 338 | + * value, the last 4 to 0, and \p nc_off to 0 (which will cause \p |
| 339 | + * stream_block to be ignored). That way, you can encrypt at most |
| 340 | + * 2**96 messages of up to 2**32 blocks each with the same key. |
| 341 | + * |
| 342 | + * The per-message nonce (or information sufficient to reconstruct |
| 343 | + * it) needs to be communicated with the ciphertext and must be unique. |
| 344 | + * The recommended way to ensure uniqueness is to use a message |
| 345 | + * counter. An alternative is to generate random nonces, but this |
| 346 | + * limits the number of messages that can be securely encrypted: |
| 347 | + * for example, with 96-bit random nonces, you should not encrypt |
| 348 | + * more than 2**32 messages with the same key. |
| 349 | + * |
| 350 | + * Note that for both stategies, sizes are measured in blocks and |
| 351 | + * that an AES block is 16 bytes. |
| 352 | + * |
| 353 | + * \warning Upon return, \p stream_block contains sensitive data. Its |
| 354 | + * content must not be written to insecure storage and should be |
| 355 | + * securely discarded as soon as it's no longer needed. |
313 | 356 | *
|
314 | 357 | * \param ctx The AES context to use for encryption or decryption.
|
315 | 358 | * \param length The length of the input data.
|
|
0 commit comments