[openssl-dev] evp cipher/digest - add alternative to init-update-final interface
Peter Waltenberg
pwalten at au1.ibm.com
Thu Jan 18 01:37:29 UTC 2018
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 <psteuer at mail.de>
To: openssl-dev <openssl-dev at 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-bounces at 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&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=
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180118/cb641d1b/attachment.html>
More information about the openssl-dev
mailing list