Re: an oldie but a goodie .. ISO C90 does not support 'long long'

[raf via openssl-users]

On Wed, Nov 02, 2022 at 06:29:45PM +, Michael Wojcik via openssl-users 
 wrote:

> > From: openssl-users  On Behalf Of Phillip
> > Susi
> > Sent: Wednesday, 2 November, 2022 11:45
> > 
> > The only thing to fix is don't put your compiler in strict C90 mode.
> 
> I'm inclined to agree. While there's an argument for backward compatibility,
> C99 was standardized nearly a quarter of a century ago. OpenSSL 1.x is
> younger than C99. It doesn't seem like an unreasonable requirement.
> 
> But as Tomas wrote, anyone who thinks it is can submit a pull request.
> 
> -- 
> Michael Wojcik

Would this be a choice between backwards-compatibility with C90
compilers and compatibility with 32-bit architectures?

Is there another way to get 64-bit integers on 32-bit systems?

I suspect that that there are more 32-bit systems than there are
C90 compilers.

cheers,
raf

Using OpenSSL with Kernel TLS

[Michael Elf]

I'd like to use OpenSSL with KTLS for websocket protocol, mainly for
receiving but also transmit. I'm using the latest version of OpenSSL from
source, with Ubuntu 20.04 and 22.04.

I currently use the regular SSL_read() and SSL_write() functions to receive
and transmit bytes. I have not used BIO interfaces before and do not
currently have one.

I saw an Issue on the Github page discussing KTLS:

https://github.com/openssl/openssl/issues/14595

In particular:

-   -   -   --   -   -   --   -   -   --   -   -   --   -
 -   --   -   -   --   -   -   --   -   -   --   -   -   -
  -   -   -   --   -   -   --

*KTLS will be used ifYou are using a suitable KTLS aware
BIO (BIO_s_connect(), or BIO_s_socket())You don't need to do anything
special in your code. SSL_write will just do the right thing if the above
conditions are met. *
-   -   -   --   -   -   --   -   -   --   -   -   --   -
 -   --   -   -   --   -   -   --   -   -   --   -   -   -
  -   -   -   --   -   -   --

The last part suggests SSL_write() will work out-of-the-box, so long as we
have a BIO interface.

1) Will SSL_read() work with KTLS too?

2) If we can still call SSL_read() and SSL_write() with KTLS, what is the
purpose/requirement for the BIO interface?

3) If we cannot use SSL_read() and SSL_write() I assume we have to use
BIO_read() and BIO_write(). I read somewhere to receive a packet I must
read bytes from the BIO and pass to the SSL layer. For KTLS this seems odd,
the whole idea is we want all processing performed in the kernel. Have I
misunderstood this?

4) Are there any significant performance differences (between Linux
distributions) for KTLS + OpenSSL?

Thank you in advance,

(SOLVED) Re: OpenSSL 3.0.7 make failure on Debian 10 (buster)

[John Boxall]

On 2022-11-04 09:14, Michael Wojcik via openssl-users wrote:


Specifically, limits.h is part of the C standard library (see e.g. ISO 
9899:1999 7.10). This is a GCC issue; there's something wrong with John's GCC 
installation, or how his environment configures it.

GCC often appears to have adopted "too clever by half" as a design goal.

Thanks Matt and Michael. I just did a build in a clean Buster VM and it 
is working fine. I'll have to clean up my system and retry.

--
Regards,

John Boxall

RE: OpenSSL 3.0.7 make failure on Debian 10 (buster)

[Michael Wojcik via openssl-users]

> From: openssl-users  On Behalf Of Matt
> Caswell
> Sent: Friday, 4 November, 2022 06:43
> 
> This looks like something environmental rather than a problem with
> OpenSSL itself. /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed/limits.h
> is clearly a system include file, trying to include some other system
> include file ("recurse down to the real one") which it is failing to find.

Specifically, limits.h is part of the C standard library (see e.g. ISO 
9899:1999 7.10). This is a GCC issue; there's something wrong with John's GCC 
installation, or how his environment configures it.

GCC often appears to have adopted "too clever by half" as a design goal.

-- 
Michael Wojcik

Re: OpenSSL 3.0.7 make failure on Debian 10 (buster)

[Matt Caswell]

On 04/11/2022 12:06, John Boxall wrote:


apps/lib/libapps-lib-app_libctx.o apps/lib/app_libctx.c
In file included from 
/usr/lib/gcc/x86_64-linux-gnu/8/include-fixed/syslimits.h:7,
  from 
/usr/lib/gcc/x86_64-linux-gnu/8/include-fixed/limits.h:34,

  from include/openssl/types.h:14,
  from apps/include/app_libctx.h:13,
  from apps/lib/app_libctx.c:9:
/usr/lib/gcc/x86_64-linux-gnu/8/include-fixed/limits.h:194:15: fatal 
error: limits.h: No such file or directory

  #include_next   /* recurse down to the real one */
    ^~
compilation terminated.
make[1]: *** [Makefile:4256: apps/lib/libapps-lib-app_libctx.o] Error 1


This looks like something environmental rather than a problem with 
OpenSSL itself. /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed/limits.h 
is clearly a system include file, trying to include some other system 
include file ("recurse down to the real one") which it is failing to find.


Matt

OpenSSL 3.0.7 make failure on Debian 10 (buster)

[John Boxall]

It has been quite a while since I worked with OpenSSL and the first time 
I have experienced a build failure.


This is some of the system info:

uname -a
Linux jdblt1 4.19.0-22-amd64 #1 SMP Debian 4.19.260-1 (2022-09-29) 
thx86_64 GNU/Linux



The following is the output from the configure and make.

+ ./Configure --prefix=/opt/openssl --openssldir=/usr/local/ssl
Configuring OpenSSL version 3.0.7 for target linux-x86_64
Using os-specific seed configuration
Created configdata.pm
Running configdata.pm
Created Makefile.in
Created Makefile
Created include/openssl/configuration.h

**
******
***   OpenSSL has been successfully configured ***
******
***   If you encounter a problem while building, please open an***
***   issue on GitHub   ***
***   and include the output from the following command:   ***
******
***   perl configdata.pm --dump***
******
***   (If you are new to OpenSSL, you might want to consult the***
***   'Troubleshooting' section in the INSTALL.md file first)  ***
******
**



+ make
/usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" "-oMakefile" 
include/crypto/bn_conf.h.in > include/crypto/bn_conf.h
/usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" "-oMakefile" 
include/crypto/dso_conf.h.in > include/crypto/dso_conf.h
/usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" "-oMakefile" 
include/openssl/asn1.h.in > include/openssl/asn1.h
/usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" "-oMakefile" 
include/openssl/asn1t.h.in > include/openssl/asn1t.h
/usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" "-oMakefile" 
include/openssl/bio.h.in > include/openssl/bio.h
/usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" "-oMakefile" 
include/openssl/cmp.h.in > include/openssl/cmp.h
/usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" "-oMakefile" 
include/openssl/cms.h.in > include/openssl/cms.h
/usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" "-oMakefile" 
include/openssl/conf.h.in > include/openssl/conf.h
/usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" "-oMakefile" 
include/openssl/crmf.h.in > include/openssl/crmf.h
/usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" "-oMakefile" 
include/openssl/crypto.h.in > include/openssl/crypto.h
/usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" "-oMakefile" 
include/openssl/ct.h.in > include/openssl/ct.h
/usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" "-oMakefile" 
include/openssl/err.h.in > include/openssl/err.h
/usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" "-oMakefile" 
include/openssl/ess.h.in > include/openssl/ess.h
/usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" "-oMakefile" 
include/openssl/fipskey.h.in > include/openssl/fipskey.h
/usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" "-oMakefile" 
include/openssl/lhash.h.in > include/openssl/lhash.h
/usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" "-oMakefile" 
include/openssl/ocsp.h.in > include/openssl/ocsp.h
/usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" "-oMakefile" 
include/openssl/opensslv.h.in > include/openssl/opensslv.h
/usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" "-oMakefile" 
include/openssl/pkcs12.h.in > include/openssl/pkcs12.h
/usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" "-oMakefile" 
include/openssl/pkcs7.h.in > include/openssl/pkcs7.h
/usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" "-oMakefile" 
include/openssl/safestack.h.in > include/openssl/safestack.h
/usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" "-oMakefile" 
include/openssl/srp.h.in > include/openssl/srp.h
/usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" "-oMakefile" 
include/openssl/ssl.h.in > include/openssl/ssl.h
/usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" "-oMakefile" 
include/openssl/ui.h.in > include/openssl/ui.h
/usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" "-oMakefile" 
include/openssl/x509.h.in > include/openssl/x509.h
/usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" "-oMakefile" 
include/openssl/x509_vfy.h.in > include/openssl/x509_vfy.h
/usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" "-oMakefile" 
include/openssl/x509v3.h.in > include/openssl/x509v3.h
/usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" "-oMakefile" 
test/provider_internal_test.cnf.in > test/provider_internal_test.cnf

make depend && make _build_sw
make[1]: Entering directory '/home/jboxall/OpenSSL/openssl-3.0.7'
make[1]: Leaving directory '/home/jboxall/OpenSSL/openssl-3.0.7'
make[1]: Entering directory '/home/jboxall/OpenSSL/openssl-3.0.7'
gcc  -I. -Iinclude 

Re: Output buffer length in EVP_EncryptUpdate for ECB mode

[Wiktor Kwapisiewicz via openssl-users]

Matt,

EVP_EncryptUpdate() can be called repeatedly, incrementally feeding in 
the data to be encrypted. The ECB mode (when used with AES-128) will 
encrypt input data 16 bytes at a time, and the output size will also be 
16 bytes per input block. If the data that you feed in to 
EVP_EncryptUpdate() is not a multiple of 16 bytes then the amount of 
data that is over a multiple of 16 bytes will be cached until a 
subsequent call where it does have 16 bytes.


Let's say you call EVP_EncryptUpdate() with 15 bytes of data. In that 
case all 15 bytes will be cached and 0 bytes will be output.


If you then call it again with 17 bytes of data, then added to the 15 
bytes already cached we have a total of 32 bytes. This is a multiple of 
16, so 2 blocks (32 bytes) will be output, so:


(inl + cipher_block_size - 1) = (17 + 16 - 1) = 32


This explanation makes perfect sense. Thank you!

The context I asked is that the rust-openssl wrapper always requires the 
output buffer to be at least as big as the input buffer + the cipher's 
block size [0] (assuming pessimistic case). That is even if I always 
feed the EVP_EncryptUpdate with blocks exactly 16 bytes long the wrapper 
requires 32 byte output buffers, while, based on your description 16 
byte output buffers should be sufficient.


Thank you for your time!

Kind regards,
Wiktor

[0]: https://docs.rs/openssl/latest/src/openssl/cipher_ctx.rs.html#504