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 SteuerTo: openssl-dev Date: 18/01/2018 04:10 Subject:[openssl-dev] evp cipher/digest - add alternative to init-update-final interface Sent by:"openssl-dev" 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
Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)
Matt Caswellwrote: >> 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 a new >> socket on which to receive new connections, or it can open >> a new >> socket on which to communicate with the new client. The second >> >> method is better for reason (b) below. Either way, it socket to >> >> communicate with the client needs to be bind(2) to the address that >> >> the client used to communicate with the server, and DTLSv1_listen() >> >> didn't collect or return that information. >> >> > The second way is what is intended. >> >> Unfortunately, there remains a race condition because we have to call >> bind() before connect() on the new socket. Under load, if a packet is >> received between the bind() and the connect(), it might go onto the >> wrong socket queue. So some packets that could have been processed >> will get dropped and have to be retransmitted by the client. > This seems like a non-issue to me. At this point in the handshake the > client will have sent its ClientHello and won't progress until it gets > the server's flight back (ServerHello etc), i.e. in the vast majority > of cases it won't be sending anything. *That* client will be waiting, but other clients may be sending new ClientHello messages (with or without cookies). >> The address of the remote client is returned ("getpeername()") by >> DTLSv1_listen(). That's all that recvfrom() gives you. >> >> recvfrom() was a reasonable API for SunOS 3.x machines with a single >> 10Mb/s interface with a single IPv4 address. I loved all that at the >> time... But it doesn't work that well when we might have a dozen >> different kind of IPv6 addresses on each virtual interface. >> >> The address that I'm talking about needing is the one the remote >> client used to reach us. That's the destination IP of the incoming >> packet ("getsockname()" in TCP speak). > Ahhhits the *server's* address you are after. This requirement > seems more reasonable. I think the API is designed to expect you to > only bind to a single IP. I'd be interested in Richard Levitte's > opinion on this. okay. binding to a single IP is not scalable in many applications. > It seems like a fairly simple solution could solve this. Currently we > have BIO_dgram_get_peer() which returns the peer's address for the last > message read from a BIO. You could imagine a new call being introduced > to get our own address. You could then call that immediately after a > successful DTLSv1_listen() call. Obviously we'd have to change the > dgram BIO to use recvmsg for this to work. That's here: https://github.com/mcr/openssl/commit/f764151782b4b32a752b4016336c0ceafa98ed5c https://github.com/mcr/openssl/commit/50692219afe92762e85338b8d947e7ac732d2cde and: https://github.com/mcr/openssl/commit/bb6f6b2cc860f25eb2b08aa109d1c7dc9ea94323 -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [EXTERNAL] Re: PKCS12 safecontents bag type deviation from spec
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 encoding rules) > > > > > > > > Well, a SEQUENCE uses tag 16 while a SET uses tag 17, according to a > quick reference I found. So that could be an interoperability > concern. > But maybe this is the first actual use of nested safecontents, since > this difference flew under the radar for so long :) Would it be possible to allow for loading the safecontents bag with both correct and incorrect tag? But we should always write the correct one. -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev