Re: evp cipher/digest - add alternative to init-update-final interface
"Peter Waltenberg" <[email protected]> Thu, 18 Jan 2018 11:37:29 +1000
| Newsgroups | gmane.comp.encryption.openssl.devel |
|---|---|
| Message-ID | <OF43BB2F4F.0D3DF25E-ON00258219.0008A50B-4A258219.00093FCF@notes.na.collabserv.com> |
--===============3370292105487188074== Content-Type: multipart/alternative; boundary="=_alternative 00093F674A258219_=" --=_alternative 00093F674A258219_= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="US-ASCII" Or just add another EVP=5FCIPHER=5FCTX=5Fctrl() option (EVP=5FCTRL=5FCIPHER= =5FONE=5FSHOT=20 or similar.) and handle it the way CCM does now and finish the operation=20 on the first data update. That doesn't require a new API and would probably simplify some existing=20 code. Peter From: Patrick Steuer <[email protected]> To: openssl-dev <[email protected]> Date: 18/01/2018 04:10 Subject: [openssl-dev] evp cipher/digest - add alternative to=20 init-update-final interface Sent by: "openssl-dev" <[email protected]> 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=5FCipher (undocumented, no engine support. The analoguously named, undocumented EVP=5FDigest 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]=20 https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A=5F=5Fcommondatastorag= e.googleapis.com=5Fchromium-2Dboringssl-2Ddocs=5Faead.h.html&d=3DDwICAg&c= =3Djf=5FiaSHvJObTbx-siA1ZOg&r=3DK53ZTnW2gq2IjM1tbpz7kYoHgvTfJ=5FaR8s4bK=5Fo= 2xzY&m=3DdCZ2v-6pJfzfrbfJZcLHkWMH1rQl8LHFyYrTC8IWaDQ&s=3DupMfA8eZGxh6kmIwqj= O38Chm2MNi=5FBocHjrm84jCvOU&e=3D [2]=20 https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A=5F=5Fman.openbsd.org= =5FEVP-5FAEAD-5FCTX-5Finit&d=3DDwICAg&c=3Djf=5FiaSHvJObTbx-siA1ZOg&r=3DK53Z= TnW2gq2IjM1tbpz7kYoHgvTfJ=5FaR8s4bK=5Fo2xzY&m=3DdCZ2v-6pJfzfrbfJZcLHkWMH1rQ= l8LHFyYrTC8IWaDQ&s=3DYXrque0c5mOqsKzVMjt2T5m4mIcgo3GVThIqnGLJeRo&e=3D --=20 openssl-dev mailing list To unsubscribe:=20 https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A=5F=5Fmta.openssl.org= =5Fmailman=5Flistinfo=5Fopenssl-2Ddev&d=3DDwICAg&c=3Djf=5FiaSHvJObTbx-siA1Z= Og&r=3DK53ZTnW2gq2IjM1tbpz7kYoHgvTfJ=5FaR8s4bK=5Fo2xzY&m=3DdCZ2v-6pJfzfrbfJ= ZcLHkWMH1rQl8LHFyYrTC8IWaDQ&s=3D-TsrGPSFfFkhWasxuHDt19pNsDGsEW3BQp19rT507Xw= &e=3D --=_alternative 00093F674A258219_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="US-ASCII" <font size=3D2 face=3D"sans-serif">Or just add another EVP=5FCIPHER=5FCTX= =5Fctrl() option (EVP=5FCTRL=5FCIPHER=5FONE=5FSHOT or similar.) and handle it the way= CCM does now and finish the operation on the first data update.</font><br><br><= font size=3D2 face=3D"sans-serif">That doesn't require a new API and would probably simplify some existing code.</font><br><br><font size=3D2 face=3D"= sans-serif">Peter</font><br><br><br><br><br><font size=3D1 color=3D#5f5f5f = face=3D"sans-serif">From: </font><font size=3D1 face=3D"sans-serif">Patrick Steuer <psteuer@= mail.de></font><br><font size=3D1 color=3D#5f5f5f face=3D"sans-serif">To= : </font><font size=3D1 face=3D"sans-serif">openssl-dev <openssl-dev= @openssl.org></font><br><font size=3D1 color=3D#5f5f5f face=3D"sans-seri= f">Date: </font><font size=3D1 face=3D"sans-serif">18/01/2018 04:10</font><br>= <font size=3D1 color=3D#5f5f5f face=3D"sans-serif">Subject: </font><font size=3D1 face=3D"sans-serif">[openssl-dev] evp cipher/digest - add alternative to init-upda= te-final interface</font><br><font size=3D1 color=3D#5f5f5f face=3D"sans-serif">Sent= by: </font><font size=3D1 face=3D"sans-serif">"openssl-dev&qu= ot; <[email protected]></font><br><hr noshade><br><br><br><= tt><font size=3D2>libcrypto's interface for ciphers and digests implements a flexible<br>init-update(s)-final calling sequence that supports streaming= of<br>arbitrary sized message chunks.<br><br>Said flexibility comes at a p= rice in the "non-streaming" case: The<br>operation must be "artificially" split between update/fina= l. This<br>leads to more functions than necessary needing to be called to<br>p= rocess a single paket (user errors). It is also a small paket<br>performanc= e problem for (possibly engine provided) hardware<br>implementations for wh= ich it enforces a superfluous call to a<br>coprocessor or adapter.<br><br>l= ibssl currently solves the problem, e.g for tls 1.2 aes-gcm record<br>layer= encryption by passing additional context information via the<br>control in= terface and calling EVP=5FCipher (undocumented, no engine<br>support. The a= naloguously named, undocumented EVP=5FDigest is just an<br>init-update-fina= l wrapper). The same would be possible for tls 1.3<br>pakets (it is current= ly implemented using init-update-final and<br>performs worse than tls 1.2 r= ecord encryption on some s390 hardware).<br><br>I would suggest to add (eng= ine supported) interfaces that can process a<br>paket with 2 calls (i.e. in= it-enc/dec/hash), at least for crypto<br>primitives that are often used in = a non-streaming context, like aead<br>constructions in modern tls (This wou= ld also make it possible to move<br>tls specific code like nonce setup to l= ibssl. Such interfaces already<br>exist in boringssl[1] and libressl[2]).<b= r><br>What do you think ?<br><br>Best,<br>Patrick<br><br>[1] <br></font></t= t><a href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A=5F=5Fcom= mondatastorage.googleapis.com=5Fchromium-2Dboringssl-2Ddocs=5Faead.h.html&a= mp;d=3DDwICAg&c=3Djf=5FiaSHvJObTbx-siA1ZOg&r=3DK53ZTnW2gq2IjM1tbpz7= kYoHgvTfJ=5FaR8s4bK=5Fo2xzY&m=3DdCZ2v-6pJfzfrbfJZcLHkWMH1rQl8LHFyYrTC8I= WaDQ&s=3DupMfA8eZGxh6kmIwqjO38Chm2MNi=5FBocHjrm84jCvOU&e=3D"><tt><f= ont size=3D2>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A=5F=5Fcom= mondatastorage.googleapis.com=5Fchromium-2Dboringssl-2Ddocs=5Faead.h.html&a= mp;d=3DDwICAg&c=3Djf=5FiaSHvJObTbx-siA1ZOg&r=3DK53ZTnW2gq2IjM1tbpz7= kYoHgvTfJ=5FaR8s4bK=5Fo2xzY&m=3DdCZ2v-6pJfzfrbfJZcLHkWMH1rQl8LHFyYrTC8I= WaDQ&s=3DupMfA8eZGxh6kmIwqjO38Chm2MNi=5FBocHjrm84jCvOU&e=3D</font><= /tt></a><tt><font size=3D2><br>[2] </font></tt><a href=3D"https://urldefens= e.proofpoint.com/v2/url?u=3Dhttp-3A=5F=5Fman.openbsd.org=5FEVP-5FAEAD-5FCTX= -5Finit&d=3DDwICAg&c=3Djf=5FiaSHvJObTbx-siA1ZOg&r=3DK53ZTnW2gq2= IjM1tbpz7kYoHgvTfJ=5FaR8s4bK=5Fo2xzY&m=3DdCZ2v-6pJfzfrbfJZcLHkWMH1rQl8L= HFyYrTC8IWaDQ&s=3DYXrque0c5mOqsKzVMjt2T5m4mIcgo3GVThIqnGLJeRo&e=3D"= ><tt><font size=3D2>https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A=5F= =5Fman.openbsd.org=5FEVP-5FAEAD-5FCTX-5Finit&d=3DDwICAg&c=3Djf=5Fia= SHvJObTbx-siA1ZOg&r=3DK53ZTnW2gq2IjM1tbpz7kYoHgvTfJ=5FaR8s4bK=5Fo2xzY&a= mp;m=3DdCZ2v-6pJfzfrbfJZcLHkWMH1rQl8LHFyYrTC8IWaDQ&s=3DYXrque0c5mOqsKzV= Mjt2T5m4mIcgo3GVThIqnGLJeRo&e=3D</font></tt></a><tt><font size=3D2><br>= -- <br>openssl-dev mailing list<br>To unsubscribe: </font></tt><a href=3D"h= ttps://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A=5F=5Fmta.openssl.org= =5Fmailman=5Flistinfo=5Fopenssl-2Ddev&d=3DDwICAg&c=3Djf=5FiaSHvJObT= bx-siA1ZOg&r=3DK53ZTnW2gq2IjM1tbpz7kYoHgvTfJ=5FaR8s4bK=5Fo2xzY&m=3D= dCZ2v-6pJfzfrbfJZcLHkWMH1rQl8LHFyYrTC8IWaDQ&s=3D-TsrGPSFfFkhWasxuHDt19p= NsDGsEW3BQp19rT507Xw&e=3D"><tt><font size=3D2>https://urldefense.proofp= oint.com/v2/url?u=3Dhttps-3A=5F=5Fmta.openssl.org=5Fmailman=5Flistinfo=5Fop= enssl-2Ddev&d=3DDwICAg&c=3Djf=5FiaSHvJObTbx-siA1ZOg&r=3DK53ZTnW= 2gq2IjM1tbpz7kYoHgvTfJ=5FaR8s4bK=5Fo2xzY&m=3DdCZ2v-6pJfzfrbfJZcLHkWMH1r= Ql8LHFyYrTC8IWaDQ&s=3D-TsrGPSFfFkhWasxuHDt19pNsDGsEW3BQp19rT507Xw&e= =3D</font></tt></a><tt><font size=3D2><br><br></font></tt><br><br><BR> --=_alternative 00093F674A258219_=-- --===============3370292105487188074== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev --===============3370292105487188074==--