Just for RSA. Do encrypt and decrypt. Include a bold comment that this should not be used for bulk encryption.

It should be the current best practice (fetch), have proper error handling and resource allocation/deallocation and be in the style of a known answer test.

Context and Description

The READMEs and any example code in all projects should be updated to reflect the move from the IBM-Swift organization to the Kitura organization.

If anyone wants to take on all or part of this, please comment here so other's know what you're working on and submit PR's. :-)

Thanks!

There's little information about what keys and values are in the output, what it means and how they are related to the screen output. In general that needs to be added. (special topics see #1675, #1674)

Problem:

A common pattern is:

GUARD(s2n_stuffer_skip_write(stuffer, bytes_to_write));
uint8_t* ptr = suffer->blob.data + stuffer->write_cursor - bytes_to_write;

which could be simplified.

Solution:

*ptr could be an *out parameter to s2n_stuffer_skip_write

• Does this change what S2N sends over the wire? No.
• Does this change any public APIs? No.

Currently Redis is our only supported persistent session store as an alternative to encrypted cookie sessions. Redis provides greater security, but has friction in initial setup which likely makes most users opt for cookie based sessions.

Let's aim to start supporting the table DBs of the big 3 cloud vendors, starting with DynamoDB.

Current Behavior

Only Redis is supported. It has a lo

Context

The configuration option MBEDTLS_SSL_MAX_CONTENT_LEN controls the "Maximum length of incoming and outgoing plaintext fragments". Since its introduction two more finer-grained options have been introduced: MBEDTLS_SSL_IN_CONTENT_MAX and MBEDTLS_SSL_OUT_CONTENT_MAX. These two options provide exactly the same functionality as MBEDTLS_SSL_MAX_CONTENT_LEN however allow for more c