Or just add another EVP_CIPHER_CTX_ctrl() option (EVP_CTRL_CIPHER_ONE_SHOT
or similar.) and handle it the way CCM does now and finish the operation
on the first data update.
That doesn't require a new API and would probably simplify some existing
code.
Peter
From: Patrick Steuer
To:
On 17/01/18 16:34, Michael Richardson wrote:
>
> Matt Caswell wrote:
> >> Matt Caswell wrote: >> a) when the existing FD is
> >> connect(2) any future traffic to the bound >> port will get rejected
> >> with no port. So the application really has to >> open a new socket
> >> f
On 01/17/2018 12:04 PM, Patrick Steuer wrote:
> libcrypto's interface for ciphers and digests implements a flexible
> init-update(s)-final calling sequence that supports streaming of
> arbitrary sized message chunks.
>
> Said flexibility comes at a price in the "non-streaming" case: The
> operation
libcrypto's interface for ciphers and digests implements a flexible
init-update(s)-final calling sequence that supports streaming of
arbitrary sized message chunks.
Said flexibility comes at a price in the "non-streaming" case: The
operation must be "artificially" split between update/final. This
Matt Caswell wrote:
>> Matt Caswell wrote: >> a) when the existing FD is
>> connect(2) any future traffic to the bound >> port will get rejected
>> with no port. So the application really has to >> open a new socket
>> first. The application can do this two ways: it can >> open
On Tue, 2018-01-16 at 19:31 +, Sands, Daniel wrote:
> On Tue, 2018-01-16 at 14:50 +, Salz, Rich via openssl-dev wrote:
> > OpenSSL defines it as a SET OF and the spec says it’s a SEQUENCE
> > OF. Ouch! Will that cause interop problems if we change it? (I
> > don’t remember the DER encodi