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