>>> 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's naturally implied that ctx is used *consistently*. I mean it's not like it's suggested that you can just use the above snippet in random place. Application would have to adhere to above pattern all along, for the life time of in-place processing "session". [I write "session" in quotes, because there might be better term.] > It does not work with CFB1, CCM, XTS and WRAP modes. Yes, some modes are so to say "one-shot", i.e. you have to pass all the data there is at once, no increments are allowed. But what does it have to do with question at hand, question about in-place processing that is? These two things are independent. So that question is rather should the snippet work in cases when incremental processing is an option. Related thing to recognize in the context is that *disputable* condition, the one that triggered this discussion, is exercised only when ctx->block_size is larger than 1, because then ctx->buf_len remains 0. Note that ctx->block_size for CFB1, CCM and XTS is 1. As for WRAP, yeah, it's special... > There is no access function to get the internal state of the cipher > context. But there is notion of in-place processing "session". > I the documentation does not cover this at all, and most of > all I really wonder how the wording could look like. That in-place processing "session" would be customarily tied up with call to EVP_EncryptFinal[_ex]? _______________________________________________ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
