evp cipher/digest - add alternative to init-update-final interface

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

evp cipher/digest - add alternative to init-update-final interface

Patrick Steuer
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
leads to more functions than necessary needing to be called to
process a single paket (user errors). It is also a small paket
performance problem for (possibly engine provided) hardware
implementations for which it enforces a superfluous call to a
coprocessor or adapter.

libssl currently solves the problem, e.g for tls 1.2 aes-gcm record
layer encryption by passing additional context information via the
control interface and calling EVP_Cipher (undocumented, no engine
support. The analoguously named, undocumented EVP_Digest is just an
init-update-final wrapper). The same would be possible for tls 1.3
pakets (it is currently implemented using init-update-final and
performs worse than tls 1.2 record encryption on some s390 hardware).

I would suggest to add (engine supported) interfaces that can process a
paket with 2 calls (i.e. init-enc/dec/hash), at least for crypto
primitives that are often used in a non-streaming context, like aead
constructions in modern tls (This would also make it possible to move
tls specific code like nonce setup to libssl. Such interfaces already
exist in boringssl[1] and libressl[2]).

What do you think ?

Best,
Patrick

[1]
https://commondatastorage.googleapis.com/chromium-boringssl-docs/aead.h.html
[2] http://man.openbsd.org/EVP_AEAD_CTX_init
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: evp cipher/digest - add alternative to init-update-final interface

OpenSSL - Dev mailing list
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 must be "artificially" split between update/final. This
> leads to more functions than necessary needing to be called to
> process a single paket (user errors). It is also a small paket
> performance problem for (possibly engine provided) hardware
> implementations for which it enforces a superfluous call to a
> coprocessor or adapter.
>
> libssl currently solves the problem, e.g for tls 1.2 aes-gcm record
> layer encryption by passing additional context information via the
> control interface and calling EVP_Cipher (undocumented, no engine
> support. The analoguously named, undocumented EVP_Digest is just an
> init-update-final wrapper). The same would be possible for tls 1.3
> pakets (it is currently implemented using init-update-final and
> performs worse than tls 1.2 record encryption on some s390 hardware).
>
> I would suggest to add (engine supported) interfaces that can process a
> paket with 2 calls (i.e. init-enc/dec/hash), at least for crypto
> primitives that are often used in a non-streaming context, like aead
> constructions in modern tls (This would also make it possible to move
> tls specific code like nonce setup to libssl. Such interfaces already
> exist in boringssl[1] and libressl[2]).
>
> What do you think ?

The one-shot EVP_DigestSign() and EVP_DigestVerify() APIs were added to
support the PureEdDSA algorithm, which is incapable of performing
init/update/final signatures.  That seems like precedent for adding such
APIs for the other types of EVP functionality, though getting a
non-wrapper implementation that actually allows ENGINE implementations
would be some amount of work.

-Ben
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: evp cipher/digest - add alternative to init-update-final interface

Peter Waltenberg
In reply to this post by Patrick Steuer
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 <[hidden email]>
To:        openssl-dev <[hidden email]>
Date:        18/01/2018 04:10
Subject:        [openssl-dev] evp cipher/digest - add alternative to        init-update-final interface
Sent by:        "openssl-dev" <[hidden email]>




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
leads to more functions than necessary needing to be called to
process a single paket (user errors). It is also a small paket
performance problem for (possibly engine provided) hardware
implementations for which it enforces a superfluous call to a
coprocessor or adapter.

libssl currently solves the problem, e.g for tls 1.2 aes-gcm record
layer encryption by passing additional context information via the
control interface and calling EVP_Cipher (undocumented, no engine
support. The analoguously named, undocumented EVP_Digest is just an
init-update-final wrapper). The same would be possible for tls 1.3
pakets (it is currently implemented using init-update-final and
performs worse than tls 1.2 record encryption on some s390 hardware).

I would suggest to add (engine supported) interfaces that can process a
paket with 2 calls (i.e. init-enc/dec/hash), at least for crypto
primitives that are often used in a non-streaming context, like aead
constructions in modern tls (This would also make it possible to move
tls specific code like nonce setup to libssl. Such interfaces already
exist in boringssl[1] and libressl[2]).

What do you think ?

Best,
Patrick

[1]
https://urldefense.proofpoint.com/v2/url?u=https-3A__commondatastorage.googleapis.com_chromium-2Dboringssl-2Ddocs_aead.h.html&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=K53ZTnW2gq2IjM1tbpz7kYoHgvTfJ_aR8s4bK_o2xzY&m=dCZ2v-6pJfzfrbfJZcLHkWMH1rQl8LHFyYrTC8IWaDQ&s=upMfA8eZGxh6kmIwqjO38Chm2MNi_BocHjrm84jCvOU&e=
[2]
https://urldefense.proofpoint.com/v2/url?u=http-3A__man.openbsd.org_EVP-5FAEAD-5FCTX-5Finit&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=K53ZTnW2gq2IjM1tbpz7kYoHgvTfJ_aR8s4bK_o2xzY&m=dCZ2v-6pJfzfrbfJZcLHkWMH1rQl8LHFyYrTC8IWaDQ&s=YXrque0c5mOqsKzVMjt2T5m4mIcgo3GVThIqnGLJeRo&e=
--
openssl-dev mailing list
To unsubscribe:
https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=K53ZTnW2gq2IjM1tbpz7kYoHgvTfJ_aR8s4bK_o2xzY&m=dCZ2v-6pJfzfrbfJZcLHkWMH1rQl8LHFyYrTC8IWaDQ&s=-TsrGPSFfFkhWasxuHDt19pNsDGsEW3BQp19rT507Xw&e=





--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: evp cipher/digest - add alternative to init-update-final interface

Patrick Steuer
On 01/18/2018 02:37 AM, Peter Waltenberg wrote:
> 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.

Ctrls for 1-shot aead paket processing like in tls 1.2 would be the
easiest solution for tls 1.3 pakets and i agree it could also be
extended to the general case.

Though aead is in some sense more than a cipher mode of operation.
Providing a dedicated api would have some advantages but i see that
maybe i reopen a discussion:

"We are also evaluating the following new features. -New AEAD API [...]"
https://www.openssl.org/policies/roadmap.html#forthcoming

Was this already evaluated? If yes, what was the result ?
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: evp cipher/digest - add alternative to init-update-final interface

Kurt Roeckx
On Thu, Jan 18, 2018 at 05:34:05PM +0100, Patrick Steuer wrote:
>
> Though aead is in some sense more than a cipher mode of operation. Providing
> a dedicated api would have some advantages but i see that maybe i reopen a
> discussion:
>
> "We are also evaluating the following new features. -New AEAD API [...]"
> https://www.openssl.org/policies/roadmap.html#forthcoming
>
> Was this already evaluated? If yes, what was the result ?

Nobody has had time for this, feel free to make a proposal.


Kurt

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev