Re: [openssl-project] to fully overlap or not to

[Richard Levitte]

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, , 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

[Matt Caswell]

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, , 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

[Andy Polyakov]

>>> 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, , 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

[Matt Caswell]

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, , 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

[openssl-project] Travel reimbursement policy

[Salz, Rich]

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] to fully overlap or not to

[Andy Polyakov]

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, , 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