In-place encryption/decryption via the EVP_* APIs

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

In-place encryption/decryption via the EVP_* APIs

Terry Chong
Hi, I am planning on using EVP_* APIs to encrypt/decrypt my data.  One thing I am wondering about is whether I can do in-place encryption, meaning I don't have to pay the price of an extra memory buffer to store my cipher text and a potential memcpy back to the source buffer.

I tried that with the EVP_* APIs by essentially passing in the same buffer to the plaintext and cipher text input pointers, and it seems to work. I am using AES XTS mode, and I understand that that may not work if I were to use a different mode.

I am wondering if this behavior for AES XTS that allows in-place encryption/decryption is going to stay?

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: In-place encryption/decryption via the EVP_* APIs

Richard Levitte - VMS Whacker-2
In message <[hidden email]> on Tue, 6 Nov 2018 14:46:52 -0800, Terry Chong <[hidden email]> said:

> Hi, I am planning on using EVP_* APIs to encrypt/decrypt my data. One thing I am wondering
> about is whether I can do in-place encryption, meaning I don't have to pay the price of an extra
> memory buffer to store my cipher text and a potential memcpy back to the source buffer.
>
> I tried that with the EVP_* APIs by essentially passing in the same buffer to the plaintext and cipher
> text input pointers, and it seems to work. I am using AES XTS mode, and I understand that that
> may not work if I were to use a different mode.
>
> I am wondering if this behavior for AES XTS that allows in-place encryption/decryption is going to
> stay?

test/evp_test.c does a number of tests on all ciphers we have test
vectors for, including overlapping buffers (i.e. input and output
buffer are the same).  So that is to say that if that behaviour ever
stopped working, we would certainly notice.

Does that help?

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: In-place encryption/decryption via the EVP_* APIs

Terry Chong
Yes it does, thank you Richard!

Regards,
Terry

> On Nov 6, 2018, at 11:12 PM, Richard Levitte <[hidden email]> wrote:
>
> In message <[hidden email]> on Tue, 6 Nov 2018 14:46:52 -0800, Terry Chong <[hidden email]> said:
>
>> Hi, I am planning on using EVP_* APIs to encrypt/decrypt my data. One thing I am wondering
>> about is whether I can do in-place encryption, meaning I don't have to pay the price of an extra
>> memory buffer to store my cipher text and a potential memcpy back to the source buffer.
>>
>> I tried that with the EVP_* APIs by essentially passing in the same buffer to the plaintext and cipher
>> text input pointers, and it seems to work. I am using AES XTS mode, and I understand that that
>> may not work if I were to use a different mode.
>>
>> I am wondering if this behavior for AES XTS that allows in-place encryption/decryption is going to
>> stay?
>
> test/evp_test.c does a number of tests on all ciphers we have test
> vectors for, including overlapping buffers (i.e. input and output
> buffer are the same).  So that is to say that if that behaviour ever
> stopped working, we would certainly notice.
>
> Does that help?
>
> Cheers,
> Richard
>
> --
> Richard Levitte         [hidden email]
> OpenSSL Project         http://www.openssl.org/~levitte/
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users