Skip to content

Commit 6486ccb

Browse files
committed
Document fixes
Signed-off-by: Elena Uziunaite <elena.uziunaite@arm.com>
1 parent 1086ccb commit 6486ccb

1 file changed

Lines changed: 15 additions & 15 deletions

File tree

kb/how-to/reduce-polarssl-memory-and-storage-footprint.md

Lines changed: 15 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -18,52 +18,52 @@ By default, Mbed TLS offers several compatibility options and frequently used fu
1818

1919
The memory footprint is the size of the memory needed at runtime to store variables, contexts and other runtime information.
2020

21-
## Multiple Precision Integers (MPIs)
21+
### Multiple Precision Integers (MPIs)
2222

23-
### Reducing the maximum size of MPIs
23+
#### Reducing the maximum size of MPIs
2424

2525
By default, `MBEDTLS_MPI_MAX_SIZE` is set to 1024 bytes (8192 bits). If you know that you will not use larger MPIs, you can reduce `MBEDTLS_MPI_MAX_SIZE`.
2626

27-
### Reducing the MPI window size
27+
#### Reducing the MPI window size
2828

2929
By default, `mbedtls_mpi_exp_mod()` uses a sliding window size (`MBEDTLS_MPI_WINDOW_SIZE`) of up to 6. You can reduce this value down to 1, which reduces the memory used to the detriment of performance. This only has an effect if you use RSA, DHM or `mbedtls_mpi_exp_mod()` directly.
3030

31-
## Elliptic curves
31+
### Elliptic curves
3232

33-
### Disabling unused ECP curves
33+
#### Disabling unused ECP curves
3434

3535
Disabling large elliptic curves that you do not use in your application saves a lot of memory.
3636

37-
### Reducing the maximum ECP bits
37+
#### Reducing the maximum ECP bits
3838

3939
By default, the `MBEDTLS_ECP_MAX_BITS` is set to `521` to support 521 bits elliptic curves. If you know that you will only use smaller curves, you can safely reduce this value. However, this only has a minimal effect on the memory used.
4040

41-
### Reducing the ECP window size
41+
#### Reducing the ECP window size
4242

4343
By default, elliptic curve multiplications use a window size (`MBEDTLS_ECP_WINDOW_SIZE`) of up to 6. You can reduce this value down to 2, which reduces the memory used to the detriment of performance. The larger the elliptic curves, the bigger the impact. See also [How to tune ECC resource usage](how-do-i-tune-elliptic-curves-resource-usage.md).
4444

45-
### Disabling the ECP fixed point optimizations
45+
#### Disabling the ECP fixed point optimizations
4646

4747
If you disable the ECP fixed point optimizations (`MBEDTLS_ECP_FIXED_POINT_OPTIM`), you lose some performance but use less memory. See also [How to tune ECC resource usage](how-do-i-tune-elliptic-curves-resource-usage.md).
4848

49-
## SSL/TLS
49+
### SSL/TLS
5050

51-
### Reducing the SSL frame buffer
51+
#### Reducing the SSL frame buffer
5252

5353
By default, Mbed TLS uses a 16 KB frame buffer to hold data for incoming and outgoing frames. This is a TLS standard requirement. If you control both sides of a connection (server and client), you can reduce the maximum frame size to reduce the buffers needed to store the data. The size of this frame is determined by `MBEDTLS_SSL_MAX_CONTENT_LEN`. You can safely reduce this to a more appropriate size (such as 2 KB) if:
5454

5555
* Both sides support the `max_fragment_length` SSL extension (allowing reduction to under 1 KB for the buffers).
5656
* You know the maximum size that will ever be sent in a single SSL/TLS frame (whether or not you control both sides of the connection).
5757

58-
## AES
58+
### AES
5959

60-
### Storing AES tables in ROM
60+
#### Storing AES tables in ROM
6161

6262
By default, our AES implementation uses tables that are computed the first time AES is used and then stored in RAM. You can store them in ROM by enabling `MBEDTLS_AES_ROM_TABLES`. This is a RAM-ROM trade-off.
6363

64-
## X.509
64+
### X.509
6565

66-
### Parsing X.509 certificates without copying the raw certificate data
66+
#### Parsing X.509 certificates without copying the raw certificate data
6767

6868
The X.509 CRT parsing APIs `mbedtls_x509_crt_parse()` and `mbedtls_x509_crt_parse_der()` create an internal copy of the raw certificate data passed to them. While this allows you to free or reuse the input buffer, it means the raw certificate data will be twice in memory at some point.
6969

@@ -80,7 +80,7 @@ X.509 certificate context. See the [documentation](https://github.com/Mbed-TLS/m
8080

8181
_Example:_ If your own certificate and/or the trusted CA certificates are hardcoded in ROM, you may use `mbedtls_x509_parse_der_nocopy()` to create X.509 certificate contexts from them without an additional copy in RAM.
8282

83-
### Removing a peer certificate after the handshake
83+
#### Removing a peer certificate after the handshake
8484

8585
By default, Mbed TLS saves a copy of the peer certificate for the lifetime of an SSL session and makes it available through the public API `mbedtls_ssl_get_peer_cert()`. If the application does not need to inspect the peer certificate, disabling the compile-time option `MBEDTLS_SSL_KEEP_PEER_CERTIFICATE` saves RAM as the SSL module will not keep a copy of the peer certificate after the handshake.
8686
The API `mbedtls_ssl_get_peer_cert()` to obtain the peer certificate is still present, but always returns `NULL`.

0 commit comments

Comments
 (0)