Re: [openssl-dev] evp cipher/digest - add alternative to init-update-final interface
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
Re: [openssl-dev] evp cipher/digest - add alternative to init-update-final interface
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
Re: [openssl-dev] evp cipher/digest - add alternative to init-update-final interface
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 <pste...@mail.de> To: openssl-dev <openssl-dev@openssl.org> Date: 18/01/2018 04:10 Subject: [openssl-dev] evp cipher/digest - add alternative to init-update-final interface Sent by:"openssl-dev" <openssl-dev-boun...@openssl.org> 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=DwICAg=jf_iaSHvJObTbx-siA1ZOg=K53ZTnW2gq2IjM1tbpz7kYoHgvTfJ_aR8s4bK_o2xzY=dCZ2v-6pJfzfrbfJZcLHkWMH1rQl8LHFyYrTC8IWaDQ=upMfA8eZGxh6kmIwqjO38Chm2MNi_BocHjrm84jCvOU= [2] https://urldefense.proofpoint.com/v2/url?u=http-3A__man.openbsd.org_EVP-5FAEAD-5FCTX-5Finit=DwICAg=jf_iaSHvJObTbx-siA1ZOg=K53ZTnW2gq2IjM1tbpz7kYoHgvTfJ_aR8s4bK_o2xzY=dCZ2v-6pJfzfrbfJZcLHkWMH1rQl8LHFyYrTC8IWaDQ=YXrque0c5mOqsKzVMjt2T5m4mIcgo3GVThIqnGLJeRo= -- openssl-dev mailing list To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=jf_iaSHvJObTbx-siA1ZOg=K53ZTnW2gq2IjM1tbpz7kYoHgvTfJ_aR8s4bK_o2xzY=dCZ2v-6pJfzfrbfJZcLHkWMH1rQl8LHFyYrTC8IWaDQ=-TsrGPSFfFkhWasxuHDt19pNsDGsEW3BQp19rT507Xw= -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] evp cipher/digest - add alternative to init-update-final interface
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
[openssl-dev] evp cipher/digest - add alternative to init-update-final interface
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
