[openssl-project] to fully overlap or not to
Hi, I'd like to request more opinions on https://github.com/openssl/openssl/pull/5427. Key dispute question is whether or not following fragment should work unsigned char *inp = buf, *out = buf; for (i = 0; i < sizeof(buf); i++) { EVP_EncryptUpdate(ctx, out, &outl, inp++, 1); out += outl; } [Just in case, corresponding corner case is effectively exercised in evp_test.] Bernd argues that this is unreasonable, which I counter with assertion that it doesn't matter how unreasonable this snippet is, because since we support in-place processing, it's reasonable to expect stream-cipher-like semantic as above to work even with block ciphers. As it stands now, suggested modified code would accept in-place calls only on block boundaries. Collateral question also is whether or not it would be appropriate to make this kind of change in minor release. Just in case, to give a bit of more general background. Benrd has shown that current checks are not sufficient to catch all corner cases of partially overlapping buffers. It was discussed that partially overlapping is not same as fully overlapping, a.k.a. in-place processing, with latter being in fact supported. And even though above snippet can be formally viewed as a stretch, it's argued that it does exhibit "legitimate intention" that deserves to be recognized and supported. At least it was so far, in sense that it's not exactly a coincidence that it currently works. [The fact that other corner cases are not recognized as invalid is of course a bug, but there is no contradiction, as fixing the bug doesn't have to mean that specific corner case is no longer recognized.] Thanks in advance. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] to fully overlap or not to
> Collateral question also is whether or not it would > be appropriate to make this kind of change in minor release. One can wonder if this is actually more burning question. But keep in mind that ... > ... there is no > contradiction, as fixing the bug doesn't have to mean that specific > corner case is no longer recognized.] In sense that fixing the bug, i.e. passing cases *other* than one in question as valid, doesn't [necessarily] conflict with compatibility goals. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
[openssl-project] Travel reimbursement policy
By a vote of 6-0-2 the OMC adopted the following travel reimbursement policy. On a related matter, the OMC voted to hold a face-to-face meeting May 5-6 in Ottawa, just before the ICMC conference. The travel policy will now be subject to ruthless html’ization and posted to the website. The OpenSSL project may pay travel expenses for OMC members when pre-approved by the OMC or when it is an official OMC meeting (as determined by vote). Project members may seek to be reimbursed if their employer is not covering the expense. The requirements for reimbursement are: - An email sent to openssl-omc, including scanned attachments of all receipts over 30 Euros. - Barring exceptional circumstances, for an all-day meeting the project will pay for arrival the day before and departure the following morning. - When presenting at a conference, the project will pay the expenses for the entire conference provided the attendee agrees to act as representative of the project during that time. - Reasonable lodging and meal expenses during the travel time will be covered. - Barring exceptional circumstances, room service, minibar, in-room movies, and other similar amenities are not covered. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
[openssl-project] Coding style updates
Please look at https://github.com/openssl/web/pull/43 I want to have an OMC vote on this soon, like within a week. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] to fully overlap or not to
> On Feb 28, 2018, at 5:39 AM, Andy Polyakov wrote: > > I'd like to request more opinions on > https://github.com/openssl/openssl/pull/5427. Key dispute question is > whether or not following fragment should work > >unsigned char *inp = buf, *out = buf; > >for (i = 0; i < sizeof(buf); i++) { >EVP_EncryptUpdate(ctx, out, &outl, inp++, 1); > out += outl; >} This should work. -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] to fully overlap or not to
> On Feb 28, 2018, at 11:25 AM, Viktor Dukhovni > wrote: > >> I'd like to request more opinions on >> https://github.com/openssl/openssl/pull/5427. Key dispute question is >> whether or not following fragment should work >> >> unsigned char *inp = buf, *out = buf; >> >> for (i = 0; i < sizeof(buf); i++) { >> EVP_EncryptUpdate(ctx, out, &outl, inp++, 1); >> out += outl; >> } > > This should work. On second thought, perhaps not. A block cipher cannot provide output synchronously on byte boundaries. -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] to fully overlap or not to
On 28/02/18 16:32, Viktor Dukhovni wrote: > > >> On Feb 28, 2018, at 11:25 AM, Viktor Dukhovni >> wrote: >> >>> I'd like to request more opinions on >>> https://github.com/openssl/openssl/pull/5427. Key dispute question is >>> whether or not following fragment should work >>> >>> unsigned char *inp = buf, *out = buf; >>> >>> for (i = 0; i < sizeof(buf); i++) { >>> EVP_EncryptUpdate(ctx, out, &outl, inp++, 1); >>> out += outl; >>> } >> >> This should work. > > On second thought, perhaps not. A block cipher cannot provide output > synchronously on byte boundaries. > It should still work IMO. With a block size of 16 you should get 15 invocations of EVP_EncryptUpdate where outl is set to 0 afterwards, followed by 1 invocation where outl is set to 16 afterwards. This should still be the case for in-place encryption. Matt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] to fully overlap or not to
> On Feb 28, 2018, at 11:32 AM, Viktor Dukhovni > wrote: > >>> I'd like to request more opinions on >>> https://github.com/openssl/openssl/pull/5427. Key dispute question is >>> whether or not following fragment should work >>> >>> unsigned char *inp = buf, *out = buf; >>> >>> for (i = 0; i < sizeof(buf); i++) { >>> EVP_EncryptUpdate(ctx, out, &outl, inp++, 1); >>> out += outl; >>> } >> >> This should work. > > On second thought, perhaps not. A block cipher cannot provide output > synchronously on byte boundaries. Time to stop composing email on the train... I see that the code supports 0-length output, so the block cipher can buffer internally, and periodically output a block. So, back to the first message, it should work, with internal input buffering in the block cipher context until a full block is obtained or EVP_EncryptFinal() is called. Unless that has prohibitive performance impact on existing callers. -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] to fully overlap or not to
>>> I'd like to request more opinions on >>> https://github.com/openssl/openssl/pull/5427. Key dispute question is >>> whether or not following fragment should work >>> >>> unsigned char *inp = buf, *out = buf; >>> >>> for (i = 0; i < sizeof(buf); i++) { >>> EVP_EncryptUpdate(ctx, out, &outl, inp++, 1); >>> out += outl; >>> } >> >> This should work. > > On second thought, perhaps not. It seems that double-clarification is appropriate. As it stands now it *does* work. So question is rather if it should keep working [and if not, is it appropriate that stops working in minor release]. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] to fully overlap or not to
On 28/02/18 17:09, Andy Polyakov wrote: I'd like to request more opinions on https://github.com/openssl/openssl/pull/5427. Key dispute question is whether or not following fragment should work unsigned char *inp = buf, *out = buf; for (i = 0; i < sizeof(buf); i++) { EVP_EncryptUpdate(ctx, out, &outl, inp++, 1); out += outl; } >>> >>> This should work. >> >> On second thought, perhaps not. > > It seems that double-clarification is appropriate. As it stands now it > *does* work. So question is rather if it should keep working [and if > not, is it appropriate that stops working in minor release]. It should continue to work and must not stop in a minor release. Matt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] to fully overlap or not to
In message <39cb0562-d313-c2d7-8d84-58badaaaf...@openssl.org> on Wed, 28 Feb 2018 18:09:38 +0100, Andy Polyakov said: appro> >>> I'd like to request more opinions on appro> >>> https://github.com/openssl/openssl/pull/5427. Key dispute question is appro> >>> whether or not following fragment should work appro> >>> appro> >>> unsigned char *inp = buf, *out = buf; appro> >>> appro> >>> for (i = 0; i < sizeof(buf); i++) { appro> >>> EVP_EncryptUpdate(ctx, out, &outl, inp++, 1); appro> >>> out += outl; appro> >>> } appro> >> appro> >> This should work. appro> > appro> > On second thought, perhaps not. appro> appro> It seems that double-clarification is appropriate. As it stands now it appro> *does* work. So question is rather if it should keep working [and if appro> not, is it appropriate that stops working in minor release]. I'll side with that it should continue to work... and most definitely should NOT stop working in a minor release. -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] to fully overlap or not to
On 02/28/18 17:25, Viktor Dukhovni wrote: > > >> On Feb 28, 2018, at 5:39 AM, Andy Polyakov wrote: >> >> I'd like to request more opinions on >> https://github.com/openssl/openssl/pull/5427. Key dispute question is >> whether or not following fragment should work >> >> unsigned char *inp = buf, *out = buf; >> >> for (i = 0; i < sizeof(buf); i++) { >> EVP_EncryptUpdate(ctx, out, &outl, inp++, 1); >> out += outl; >> } > > This should work. > It does only work, if you know that ctx->buf_len == 0 before the loop is entered. It does not work with CFB1, CCM, XTS and WRAP modes. There is no access function to get the internal state of the cipher context. I the documentation does not cover this at all, and most of all I really wonder how the wording could look like. Bernd. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project