Re: [openssl-users] How to compile for ARM-Cortex M4?

[Ajay Garg]

Help please... experts ?!!

On Fri, Nov 10, 2017 at 12:52 PM, Ajay Garg <ajaygargn...@gmail.com> wrote:

> Hi All.
>
> I am using bleeding-edge openssl code, and wish to compile it for
> https://www.digikey.com/product-detail/en/microchip-
> technology/ATSAM4E8CA-AUR/ATSAM4E8CA-AURCT-ND/4140758
>
> What is the best/recommended way to accomplish this?
>
>
> Will be grateful for a reply.
>
>
> Thanks and Regards,
> Ajay
>



-- 
Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] How to compile for ARM-Cortex M4?

[Ajay Garg]

Hi All.

I am using bleeding-edge openssl code, and wish to compile it for
https://www.digikey.com/product-detail/en/microchip-technology/ATSAM4E8CA-AUR/ATSAM4E8CA-AURCT-ND/4140758

What is the best/recommended way to accomplish this?


Will be grateful for a reply.


Thanks and Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Issues while "configuring before compiling" OpenSSL on Raspberry-Pi

[Ajay Garg]

Thanks guys.. that worked.


Seems I screwed up something while copying the 1.0.2_d version into our
framework.
Cloning again from scratch worked in first attempt.


Thanks a ton again for your valuable time !!


Thanks and Regards,
Ajay

On Mon, Feb 13, 2017 at 6:26 AM, Jeffrey Walton <noloa...@gmail.com> wrote:

> On Sun, Feb 12, 2017 at 8:13 AM, Ajay Garg <ajaygargn...@gmail.com> wrote:
> > Any ideas please?
> > Is compiling openssl even possible on Raspberry-Pi?
> >
>
> Try 'config' rather than 'Configure'. It looks like it does the job.
> I'm not sure why the same triplet produces different results. Maybe
> you need to perform a 'make dclean' to clean former artifacts?
>
> $ git clone https://github.com/openssl/openssl
> ...
> $ cd openssl
> ...
>
> $ git checkout OpenSSL_1_0_2d
> Checking out files: 100% (14097/14097), done.
> Note: checking out 'OpenSSL_1_0_2d'.
> ...
>
> $ ./config
> Operating system: armv7l-whatever-linux2
> Configuring for linux-armv4
> Configuring for linux-armv4
> no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128 (skip
> dir)
> no-gmp  [default]  OPENSSL_NO_GMP (skip dir)
> no-jpake[experimental] OPENSSL_NO_JPAKE (skip dir)
> no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5
> no-libunbound   [experimental] OPENSSL_NO_LIBUNBOUND (skip dir)
> no-md2  [default]  OPENSSL_NO_MD2 (skip dir)
> no-rc5  [default]  OPENSSL_NO_RC5 (skip dir)
> no-rfc3779  [default]  OPENSSL_NO_RFC3779 (skip dir)
> no-sctp [default]  OPENSSL_NO_SCTP (skip dir)
> no-shared   [default]
> no-ssl-trace[default]  OPENSSL_NO_SSL_TRACE (skip dir)
> no-store[experimental] OPENSSL_NO_STORE (skip dir)
> no-unit-test[default]  OPENSSL_NO_UNIT_TEST (skip dir)
> no-zlib [default]
> no-zlib-dynamic [default]
> ...
>
> created directory `include/openssl'
> e_os2.h => include/openssl/e_os2.h
> making links in crypto...
> make[1]: Entering directory '/home/jwalton/openssl/crypto'
> crypto.h => ../include/openssl/crypto.h
> opensslv.h => ../include/openssl/opensslv.h
> opensslconf.h => ../include/openssl/opensslconf.h
> ebcdic.h => ../include/openssl/ebcdic.h
> symhacks.h => ../include/openssl/symhacks.h
> ossl_typ.h => ../include/openssl/ossl_typ.h
> constant_time_test.c => ../test/constant_time_test.c
> ...
>
> generating dummy tests (if needed)...
> make[1]: Entering directory '/home/jwalton/openssl/test'
> md2test.c => dummytest.c
> rc5test.c => dummytest.c
> jpaketest.c => dummytest.c
> make[1]: Leaving directory '/home/jwalton/openssl/test'
>
> Configured for linux-armv4.
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>



-- 
Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Issues while "configuring before compiling" OpenSSL on Raspberry-Pi

[Ajay Garg]

Any ideas please?
Is compiling openssl even possible on Raspberry-Pi?

On Sat, Jan 28, 2017 at 10:50 AM, Ajay Garg <ajaygargn...@gmail.com> wrote:

> Hi Experts !!!
>
> Any help, please ?!!!
>
> On Sun, Jan 15, 2017 at 9:14 AM, Ajay Garg <ajaygargn...@gmail.com> wrote:
>
>> Hi All.
>>
>> I am getting stuck on the first step of configuring OpenSSL.
>> Following are some of the diagnostics ::
>>
>>
>> OpenSSL-Version : *1.0.2d*
>>
>>
>> #
>> pi@raspberrypi:~/instamsg-c/third_party/openssl $ *uname -a*
>> Linux raspberrypi 4.4.34-v7+ #930 SMP Wed Nov 23 15:20:41 GMT 2016 armv7l
>> GNU/Linux
>> #
>>
>>
>> #
>> pi@raspberrypi:~/instamsg-c/third_party/openssl $ *./Configure
>> linux-armv4*
>> Configuring for linux-armv4
>> no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128
>> (skip dir)
>> no-gmp  [default]  OPENSSL_NO_GMP (skip dir)
>> no-jpake[experimental] OPENSSL_NO_JPAKE (skip dir)
>> no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5
>> no-libunbound   [experimental] OPENSSL_NO_LIBUNBOUND (skip dir)
>> no-md2  [default]  OPENSSL_NO_MD2 (skip dir)
>> no-rc5  [default]  OPENSSL_NO_RC5 (skip dir)
>> no-rfc3779  [default]  OPENSSL_NO_RFC3779 (skip dir)
>> no-sctp [default]  OPENSSL_NO_SCTP (skip dir)
>> no-shared   [default]
>> no-ssl-trace[default]  OPENSSL_NO_SSL_TRACE (skip dir)
>> no-store[experimental] OPENSSL_NO_STORE (skip dir)
>> no-unit-test[default]  OPENSSL_NO_UNIT_TEST (skip dir)
>> no-zlib [default]
>> no-zlib-dynamic [default]
>> IsMK1MF=0
>> CC=gcc
>> CFLAG =-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H
>> -O3 -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM
>> -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM
>> EX_LIBS   =-ldl
>> CPUID_OBJ =armcap.o armv4cpuid.o
>> BN_ASM=bn_asm.o armv4-mont.o armv4-gf2m.o
>> EC_ASM=
>> DES_ENC   =des_enc.o fcrypt_b.o
>> AES_ENC   =aes_cbc.o aes-armv4.o bsaes-armv7.o aesv8-armx.o
>> BF_ENC=bf_enc.o
>> CAST_ENC  =c_enc.o
>> RC4_ENC   =rc4_enc.o rc4_skey.o
>> RC5_ENC   =rc5_enc.o
>> MD5_OBJ_ASM   =
>> SHA1_OBJ_ASM  =sha1-armv4-large.o sha256-armv4.o sha512-armv4.o
>> RMD160_OBJ_ASM=
>> CMLL_ENC  =camellia.o cmll_misc.o cmll_cbc.o
>> MODES_OBJ =ghash-armv4.o ghashv8-armx.o
>> ENGINES_OBJ   =
>> PROCESSOR =
>> RANLIB=/usr/bin/ranlib
>> ARFLAGS   =
>> PERL  =/usr/bin/perl
>> THIRTY_TWO_BIT mode
>> DES_UNROLL used
>> DES_INT used
>> BN_LLONG mode
>> RC4 uses uchar
>> RC4_CHUNK is unsigned long
>> BF_PTR used
>> e_os2.h => include/openssl/e_os2.h
>> making links in crypto...
>> make[1]: Entering directory '/home/pi/instamsg-c/third_par
>> ty/openssl/crypto'
>> crypto.h => ../include/openssl/crypto.h
>> opensslv.h => ../include/openssl/opensslv.h
>> opensslconf.h => ../include/openssl/opensslconf.h
>> ebcdic.h => ../include/openssl/ebcdic.h
>> symhacks.h => ../include/openssl/symhacks.h
>> ossl_typ.h => ../include/openssl/ossl_typ.h
>> constant_time_test.c => ../test/constant_time_test.c
>> making links in crypto/objects...
>> make[2]: Entering directory '/home/pi/instamsg-c/third_par
>> ty/openssl/crypto/objects'
>> objects.h => ../../include/openssl/objects.h
>> obj_mac.h => ../../include/openssl/obj_mac.h
>> make[2]: Leaving directory '/home/pi/instamsg-c/third_par
>> ty/openssl/crypto/objects'
>> making links in crypto/md4...
>> make[2]: Entering directory '/home/pi/instamsg-c/third_par
>> ty/openssl/crypto/md4'
>> md4.h => ../../include/openssl/md4.h
>> md4test.c => ../../test/md4test.c
>> md4.c => ../../apps/md4.c
>> make[2]: Leaving directory '/home/pi/instamsg-c/third_par
>> ty/openssl/crypto/md4'
>> making links in crypto/md5...
>> make[2]: Entering directory '/home/pi/instamsg-c/third_par
>> ty/openssl/crypto/md5'
>> md5.h => ../../include/openssl/md5.h
>> md5test.c => ../../test/md5test.c
>> make[2]: Leaving directory '/home/pi/instamsg-c/third_par
>> ty/openssl/crypto/md5'
>>

Re: [openssl-users] Issues while "configuring before compiling" OpenSSL on Raspberry-Pi

[Ajay Garg]

Hi Experts !!!

Any help, please ?!!!

On Sun, Jan 15, 2017 at 9:14 AM, Ajay Garg <ajaygargn...@gmail.com> wrote:

> Hi All.
>
> I am getting stuck on the first step of configuring OpenSSL.
> Following are some of the diagnostics ::
>
>
> OpenSSL-Version : *1.0.2d*
>
>
> #
> pi@raspberrypi:~/instamsg-c/third_party/openssl $ *uname -a*
> Linux raspberrypi 4.4.34-v7+ #930 SMP Wed Nov 23 15:20:41 GMT 2016 armv7l
> GNU/Linux
> #
>
>
> #
> pi@raspberrypi:~/instamsg-c/third_party/openssl $ *./Configure
> linux-armv4*
> Configuring for linux-armv4
> no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128
> (skip dir)
> no-gmp  [default]  OPENSSL_NO_GMP (skip dir)
> no-jpake[experimental] OPENSSL_NO_JPAKE (skip dir)
> no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5
> no-libunbound   [experimental] OPENSSL_NO_LIBUNBOUND (skip dir)
> no-md2  [default]  OPENSSL_NO_MD2 (skip dir)
> no-rc5  [default]  OPENSSL_NO_RC5 (skip dir)
> no-rfc3779  [default]  OPENSSL_NO_RFC3779 (skip dir)
> no-sctp [default]  OPENSSL_NO_SCTP (skip dir)
> no-shared   [default]
> no-ssl-trace[default]  OPENSSL_NO_SSL_TRACE (skip dir)
> no-store[experimental] OPENSSL_NO_STORE (skip dir)
> no-unit-test[default]  OPENSSL_NO_UNIT_TEST (skip dir)
> no-zlib [default]
> no-zlib-dynamic [default]
> IsMK1MF=0
> CC=gcc
> CFLAG =-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H
> -O3 -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM
> -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM
> EX_LIBS   =-ldl
> CPUID_OBJ =armcap.o armv4cpuid.o
> BN_ASM=bn_asm.o armv4-mont.o armv4-gf2m.o
> EC_ASM=
> DES_ENC   =des_enc.o fcrypt_b.o
> AES_ENC   =aes_cbc.o aes-armv4.o bsaes-armv7.o aesv8-armx.o
> BF_ENC=bf_enc.o
> CAST_ENC  =c_enc.o
> RC4_ENC   =rc4_enc.o rc4_skey.o
> RC5_ENC   =rc5_enc.o
> MD5_OBJ_ASM   =
> SHA1_OBJ_ASM  =sha1-armv4-large.o sha256-armv4.o sha512-armv4.o
> RMD160_OBJ_ASM=
> CMLL_ENC  =camellia.o cmll_misc.o cmll_cbc.o
> MODES_OBJ =ghash-armv4.o ghashv8-armx.o
> ENGINES_OBJ   =
> PROCESSOR =
> RANLIB=/usr/bin/ranlib
> ARFLAGS   =
> PERL  =/usr/bin/perl
> THIRTY_TWO_BIT mode
> DES_UNROLL used
> DES_INT used
> BN_LLONG mode
> RC4 uses uchar
> RC4_CHUNK is unsigned long
> BF_PTR used
> e_os2.h => include/openssl/e_os2.h
> making links in crypto...
> make[1]: Entering directory '/home/pi/instamsg-c/third_par
> ty/openssl/crypto'
> crypto.h => ../include/openssl/crypto.h
> opensslv.h => ../include/openssl/opensslv.h
> opensslconf.h => ../include/openssl/opensslconf.h
> ebcdic.h => ../include/openssl/ebcdic.h
> symhacks.h => ../include/openssl/symhacks.h
> ossl_typ.h => ../include/openssl/ossl_typ.h
> constant_time_test.c => ../test/constant_time_test.c
> making links in crypto/objects...
> make[2]: Entering directory '/home/pi/instamsg-c/third_par
> ty/openssl/crypto/objects'
> objects.h => ../../include/openssl/objects.h
> obj_mac.h => ../../include/openssl/obj_mac.h
> make[2]: Leaving directory '/home/pi/instamsg-c/third_par
> ty/openssl/crypto/objects'
> making links in crypto/md4...
> make[2]: Entering directory '/home/pi/instamsg-c/third_par
> ty/openssl/crypto/md4'
> md4.h => ../../include/openssl/md4.h
> md4test.c => ../../test/md4test.c
> md4.c => ../../apps/md4.c
> make[2]: Leaving directory '/home/pi/instamsg-c/third_par
> ty/openssl/crypto/md4'
> making links in crypto/md5...
> make[2]: Entering directory '/home/pi/instamsg-c/third_par
> ty/openssl/crypto/md5'
> md5.h => ../../include/openssl/md5.h
> md5test.c => ../../test/md5test.c
> make[2]: Leaving directory '/home/pi/instamsg-c/third_par
> ty/openssl/crypto/md5'
> making links in crypto/sha...
> make[2]: Entering directory '/home/pi/instamsg-c/third_par
> ty/openssl/crypto/sha'
> sha.h => ../../include/openssl/sha.h
> shatest.c => ../../test/shatest.c
> sha1test.c => ../../test/sha1test.c
> sha256t.c => ../../test/sha256t.c
> sha512t.c => ../../test/sha512t.c
> make[2]: Leaving directory '/home/pi/instamsg-c/third_par
> ty/openssl/crypto/sha'
> making links in crypto/mdc2...
> make[2]: Entering directory '/home/pi/instamsg-c/third_par
> ty/openssl/crypto/mdc2'
> mdc2.h => ../../include/openss

[openssl-users] Issues while "configuring before compiling" OpenSSL on Raspberry-Pi

[Ajay Garg]

Hi All.

I am getting stuck on the first step of configuring OpenSSL.
Following are some of the diagnostics ::


OpenSSL-Version : *1.0.2d*


#
pi@raspberrypi:~/instamsg-c/third_party/openssl $ *uname -a*
Linux raspberrypi 4.4.34-v7+ #930 SMP Wed Nov 23 15:20:41 GMT 2016 armv7l
GNU/Linux
#


#
pi@raspberrypi:~/instamsg-c/third_party/openssl $ *./Configure linux-armv4*
Configuring for linux-armv4
no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128 (skip
dir)
no-gmp  [default]  OPENSSL_NO_GMP (skip dir)
no-jpake[experimental] OPENSSL_NO_JPAKE (skip dir)
no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5
no-libunbound   [experimental] OPENSSL_NO_LIBUNBOUND (skip dir)
no-md2  [default]  OPENSSL_NO_MD2 (skip dir)
no-rc5  [default]  OPENSSL_NO_RC5 (skip dir)
no-rfc3779  [default]  OPENSSL_NO_RFC3779 (skip dir)
no-sctp [default]  OPENSSL_NO_SCTP (skip dir)
no-shared   [default]
no-ssl-trace[default]  OPENSSL_NO_SSL_TRACE (skip dir)
no-store[experimental] OPENSSL_NO_STORE (skip dir)
no-unit-test[default]  OPENSSL_NO_UNIT_TEST (skip dir)
no-zlib [default]
no-zlib-dynamic [default]
IsMK1MF=0
CC=gcc
CFLAG =-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H
-O3 -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM
-DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM
EX_LIBS   =-ldl
CPUID_OBJ =armcap.o armv4cpuid.o
BN_ASM=bn_asm.o armv4-mont.o armv4-gf2m.o
EC_ASM=
DES_ENC   =des_enc.o fcrypt_b.o
AES_ENC   =aes_cbc.o aes-armv4.o bsaes-armv7.o aesv8-armx.o
BF_ENC=bf_enc.o
CAST_ENC  =c_enc.o
RC4_ENC   =rc4_enc.o rc4_skey.o
RC5_ENC   =rc5_enc.o
MD5_OBJ_ASM   =
SHA1_OBJ_ASM  =sha1-armv4-large.o sha256-armv4.o sha512-armv4.o
RMD160_OBJ_ASM=
CMLL_ENC  =camellia.o cmll_misc.o cmll_cbc.o
MODES_OBJ =ghash-armv4.o ghashv8-armx.o
ENGINES_OBJ   =
PROCESSOR =
RANLIB=/usr/bin/ranlib
ARFLAGS   =
PERL  =/usr/bin/perl
THIRTY_TWO_BIT mode
DES_UNROLL used
DES_INT used
BN_LLONG mode
RC4 uses uchar
RC4_CHUNK is unsigned long
BF_PTR used
e_os2.h => include/openssl/e_os2.h
making links in crypto...
make[1]: Entering directory '/home/pi/instamsg-c/third_party/openssl/crypto'
crypto.h => ../include/openssl/crypto.h
opensslv.h => ../include/openssl/opensslv.h
opensslconf.h => ../include/openssl/opensslconf.h
ebcdic.h => ../include/openssl/ebcdic.h
symhacks.h => ../include/openssl/symhacks.h
ossl_typ.h => ../include/openssl/ossl_typ.h
constant_time_test.c => ../test/constant_time_test.c
making links in crypto/objects...
make[2]: Entering directory '/home/pi/instamsg-c/third_par
ty/openssl/crypto/objects'
objects.h => ../../include/openssl/objects.h
obj_mac.h => ../../include/openssl/obj_mac.h
make[2]: Leaving directory '/home/pi/instamsg-c/third_par
ty/openssl/crypto/objects'
making links in crypto/md4...
make[2]: Entering directory '/home/pi/instamsg-c/third_par
ty/openssl/crypto/md4'
md4.h => ../../include/openssl/md4.h
md4test.c => ../../test/md4test.c
md4.c => ../../apps/md4.c
make[2]: Leaving directory '/home/pi/instamsg-c/third_par
ty/openssl/crypto/md4'
making links in crypto/md5...
make[2]: Entering directory '/home/pi/instamsg-c/third_par
ty/openssl/crypto/md5'
md5.h => ../../include/openssl/md5.h
md5test.c => ../../test/md5test.c
make[2]: Leaving directory '/home/pi/instamsg-c/third_par
ty/openssl/crypto/md5'
making links in crypto/sha...
make[2]: Entering directory '/home/pi/instamsg-c/third_par
ty/openssl/crypto/sha'
sha.h => ../../include/openssl/sha.h
shatest.c => ../../test/shatest.c
sha1test.c => ../../test/sha1test.c
sha256t.c => ../../test/sha256t.c
sha512t.c => ../../test/sha512t.c
make[2]: Leaving directory '/home/pi/instamsg-c/third_par
ty/openssl/crypto/sha'
making links in crypto/mdc2...
make[2]: Entering directory '/home/pi/instamsg-c/third_par
ty/openssl/crypto/mdc2'
mdc2.h => ../../include/openssl/mdc2.h
mdc2test.c => ../../test/mdc2test.c
make[2]: Leaving directory '/home/pi/instamsg-c/third_par
ty/openssl/crypto/mdc2'
making links in crypto/hmac...
make[2]: Entering directory '/home/pi/instamsg-c/third_par
ty/openssl/crypto/hmac'
make[2]: *** No rule to make target 'links'.  Stop.
make[2]: Leaving directory '/home/pi/instamsg-c/third_par
ty/openssl/crypto/hmac'
Makefile:95: recipe for target 'links' failed
make[1]: *** [links] Error 1
make[1]: Leaving directory '/home/pi/instamsg-c/third_party/openssl/crypto'
Makefile:433: recipe for target 'links' failed
make: *** [links] Error 1
#


What am I missing?

Will be grateful for pointers.



Thanks and Regards,
Ajay

[openssl-users] Is there a way to get the numeric-value for a openssl-cipher-suite

[Ajay Garg]

Hi All.

I am using the following script at myu laptop, to test for the available
cipher-suites :


#!/usr/bin/env bash

# OpenSSL requires the port number.
SERVER=server.ip.com:12345
DELAY=1
ciphers=$(openssl ciphers 'ALL:eNULL' | sed -e 's/:/ /g')

echo Obtaining cipher list from $(openssl version).

for cipher in ${ciphers[@]}
do
# echo -n Testing $cipher...
result=$(echo -n | openssl s_client -cipher "$cipher" -connect $SERVER 2>&1)
if [[ "$result" =~ ":error:" ]] ; then
true
else
  if [[ "$result" =~ "Cipher is ${cipher}" || "$result" =~ "Cipher:" ]]
; then
echo ${cipher}
  else
  true
  fi
fi
sleep $DELAY
done



Above script works, and I am able to get the supported-ciphers-listing.
But all those ciphers are in stringified-form.


Is there a way, so that I can get the supported-ciphers in their
corrsponding numeric-values form?
I ask this, because a particular device supports only a restricted set of
ciphers, and I am not able to properly match the cipher-suites using their
stringified-forms.


Looking forward to some help from the experts :)



Thanks and Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Code-Architecture questions while compiling OpenSSL for STM32-processors

[Ajay Garg]

Ping !!!

Upon code-browsing, I am beginning to feel that OpenSSL uses
program-buffer, which is used for malloc/free.
Am I right?

If yes, is there a place where the maximum-size of "in-program-buffer-heap"
is defined?

On Tue, Nov 22, 2016 at 7:33 PM, Ajay Garg <ajaygargn...@gmail.com> wrote:

> Hi All.
>
> I wish to compile openssl libraries for a STM32-processor (which would
> then be linked statically with our application-framework code).
>
>
> Now. I believe that OpenSSL uses tonnes of "malloc"s and "free"s. But for
> bare-metal-systems (without any formal OSes), we generally don't have any
> heap-memory.
>
> So, what is the protocol for compiling OpenSSL for such systems?
> I am sorry, but this is the first time I would be compiling for a non-OS
> entity.
>
>
> Will be thankful for inputs.
>
>
> Thanks and Regards,
> Ajay
>



-- 
Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Code-Architecture questions while compiling OpenSSL for STM32-processors

[Ajay Garg]

Hi All.

I wish to compile openssl libraries for a STM32-processor (which would then
be linked statically with our application-framework code).


Now. I believe that OpenSSL uses tonnes of "malloc"s and "free"s. But for
bare-metal-systems (without any formal OSes), we generally don't have any
heap-memory.

So, what is the protocol for compiling OpenSSL for such systems?
I am sorry, but this is the first time I would be compiling for a non-OS
entity.


Will be thankful for inputs.


Thanks and Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Problem in compiling OpenSSL on Windows-7-32-bit

[Ajay Garg]

Hi Kim.

Thanks for the reply.

On 8 Nov 2016 11:59 a.m., "Kim Gräsman" <kim.gras...@gmail.com> wrote:
>
> On Tue, Nov 8, 2016 at 6:26 AM, Ajay Garg <ajaygargn...@gmail.com> wrote:
> >
> > Is compiling on windows always such a pain? :(
> > On Linux, it compiled perfectly the first time itself.
>
> It's worked well for me in a similar environment. I use DLL builds,
> though, so `ntdll.mak` instead of `nt.mak`.

Unfortunately, I need to link openssl statically to our framework. So DLL
would not help, require .libs

>
> One thing that looks suspicious is this:
>
> > NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio
14.0\VC\
> > N\nasm.EXE"' : return code '0x1'
>
> Have you put nasm.exe inside the Visual Studio install dir? That seems
> like an odd choice, not sure if the spaces in the path maybe confuses
> something?

I doubt, cl.exe is also inside this.

>
> You also don't mention which directory you're in when running these
> commands. I've run everything inside the openssl-1.0.2h (using a
> different version) source directory.

I am running everything from the openssl source directory itself.

Any chance I can get pre-compiled libraries for 1.0.2d, after which I can
link them statically to our framework?

Thanks in advance 

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

Re: [openssl-users] Problem in compiling OpenSSL on Windows-7-32-bit

[Ajay Garg]

I tried configuring with no-asm, and then re-compiled.
Now, I get stuck at

*#error: MDC2 is disabled*
If I then *also* add no-mdc2, I get stuck at *cannot open input file
'out32\ssleay32.lib*'

Is compiling on windows always such a pain? :(
On Linux, it compiled perfectly the first time itself.

On Mon, Nov 7, 2016 at 9:52 PM, Ajay Garg <ajaygargn...@gmail.com> wrote:

> Oops.. sorry.
> OpenSSL-version is 1.0.2d, and nasm-version is 2.12.02.
>
>
>
> On Mon, Nov 7, 2016 at 9:31 PM, Jeremy Farrell <jeremy.farr...@oracle.com>
> wrote:
>
>> What version of OpenSSL? What version of nasm (nasm -v)? People are more
>> likely to be able to help if you provide such basic information.
>>
>> Regards,
>>    jjf
>>
>> On 07/11/2016 11:42, Ajay Garg wrote:
>>
>> Oops... pardon me.
>> The e) step was not done.
>>
>> The errors came right after step d)
>>
>> On 7 Nov 2016 3:36 p.m., "Ajay Garg" <ajaygargn...@gmail.com> wrote:
>>
>>> Hi All.
>>>
>>> Following are the steps I followed :
>>>
>>> 
>>> ###
>>> a)
>>> Downloaded nasm.exe from internet, and placed it in the include-path.
>>>
>>> b)
>>> *perl Configure VC-WIN32*
>>>
>>> c)
>>>
>>>
>>> *ms\do_nasm.bat *
>>> d)
>>>
>>>
>>> * nmake -f ms\nt.mak *
>>> e)
>>> *make*
>>>
>>>
>>>
>>> *###
>>> *
>>> Compilation runs fine for some time, but then I get hundreds of
>>> IDENTICAL errors as follows ::
>>>
>>> 
>>> ###
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *tmp32\sha1-586.asm:3964: warning: `PTR' is not a NASM keyword
>>> tmp32\sha1-586.asm:3964: error: comma, colon, decorator or end of line
>>> expecte after operand tmp32\sha1-586.asm:3970: error: symbol
>>> `__sha1_block_data_order_avx' redefined tmp32\sha1-586.asm:3970: error:
>>> parser: instruction expected tmp32\sha1-586.asm:3972: error: parser:
>>> instruction expected tmp32\sha1-586.asm:3983: error: parser: instruction
>>> expected tmp32\sha1-586.asm:3985: error: parser: instruction expected
>>> tmp32\sha1-586.asm:3986: error: parser: instruction expected
>>> tmp32\sha1-586.asm:3987: warning: label alone on a line without a colon
>>> might  in error NMAKE : fatal error U1077: '"C:\Program Files\Microsoft
>>> Visual Studio 14.0\VC\ N\nasm.EXE"' : return code '0x1' Stop.*
>>>
>>>
>>> *###
>>> *
>>> Any pointers how to solve this?
>>> I will heartfully grateful.
>>>
>>> Thanks and Regards,
>>> Ajay
>>>
>>
>> --
>> J. J. Farrell
>> Not speaking for Oracle
>>
>>
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>>
>
>
> --
> Regards,
> Ajay
>



-- 
Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Problem in compiling OpenSSL on Windows-7-32-bit

[Ajay Garg]

Oops.. sorry.
OpenSSL-version is 1.0.2d, and nasm-version is 2.12.02.



On Mon, Nov 7, 2016 at 9:31 PM, Jeremy Farrell <jeremy.farr...@oracle.com>
wrote:

> What version of OpenSSL? What version of nasm (nasm -v)? People are more
> likely to be able to help if you provide such basic information.
>
> Regards,
>jjf
>
> On 07/11/2016 11:42, Ajay Garg wrote:
>
> Oops... pardon me.
> The e) step was not done.
>
> The errors came right after step d)
>
> On 7 Nov 2016 3:36 p.m., "Ajay Garg" <ajaygargn...@gmail.com> wrote:
>
>> Hi All.
>>
>> Following are the steps I followed :
>>
>> 
>> ###
>> a)
>> Downloaded nasm.exe from internet, and placed it in the include-path.
>>
>> b)
>> *perl Configure VC-WIN32*
>>
>> c)
>>
>>
>> *ms\do_nasm.bat *
>> d)
>>
>>
>> * nmake -f ms\nt.mak *
>> e)
>> *make*
>>
>>
>>
>> *###
>> *
>> Compilation runs fine for some time, but then I get hundreds of IDENTICAL
>> errors as follows ::
>>
>> 
>> ###
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *tmp32\sha1-586.asm:3964: warning: `PTR' is not a NASM keyword
>> tmp32\sha1-586.asm:3964: error: comma, colon, decorator or end of line
>> expecte after operand tmp32\sha1-586.asm:3970: error: symbol
>> `__sha1_block_data_order_avx' redefined tmp32\sha1-586.asm:3970: error:
>> parser: instruction expected tmp32\sha1-586.asm:3972: error: parser:
>> instruction expected tmp32\sha1-586.asm:3983: error: parser: instruction
>> expected tmp32\sha1-586.asm:3985: error: parser: instruction expected
>> tmp32\sha1-586.asm:3986: error: parser: instruction expected
>> tmp32\sha1-586.asm:3987: warning: label alone on a line without a colon
>> might  in error NMAKE : fatal error U1077: '"C:\Program Files\Microsoft
>> Visual Studio 14.0\VC\ N\nasm.EXE"' : return code '0x1' Stop.*
>>
>>
>> *###
>> *
>> Any pointers how to solve this?
>> I will heartfully grateful.
>>
>> Thanks and Regards,
>> Ajay
>>
>
> --
> J. J. Farrell
> Not speaking for Oracle
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>


-- 
Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Problem in compiling OpenSSL on Windows-7-32-bit

[Ajay Garg]

Oops... pardon me.
The e) step was not done.

The errors came right after step d)

On 7 Nov 2016 3:36 p.m., "Ajay Garg" <ajaygargn...@gmail.com> wrote:

> Hi All.
>
> Following are the steps I followed :
>
> 
> ###
> a)
> Downloaded nasm.exe from internet, and placed it in the include-path.
>
> b)
> *perl Configure VC-WIN32*
>
> c)
>
>
> *ms\do_nasm.bat*
> d)
>
>
> *nmake -f ms\nt.mak*
> e)
> *make*
>
>
>
>
>
>
> *###*
> Compilation runs fine for some time, but then I get hundreds of IDENTICAL
> errors as follows ::
>
> 
> ###
>
>
>
>
>
>
>
>
>
>
>
>
>
> *tmp32\sha1-586.asm:3964: warning: `PTR' is not a NASM
> keywordtmp32\sha1-586.asm:3964: error: comma, colon, decorator or end of
> line expecteafter operandtmp32\sha1-586.asm:3970: error: symbol
> `__sha1_block_data_order_avx' redefinedtmp32\sha1-586.asm:3970: error:
> parser: instruction expectedtmp32\sha1-586.asm:3972: error: parser:
> instruction expectedtmp32\sha1-586.asm:3983: error: parser: instruction
> expectedtmp32\sha1-586.asm:3985: error: parser: instruction
> expectedtmp32\sha1-586.asm:3986: error: parser: instruction
> expectedtmp32\sha1-586.asm:3987: warning: label alone on a line without a
> colon might in errorNMAKE : fatal error U1077: '"C:\Program Files\Microsoft
> Visual Studio 14.0\VC\N\nasm.EXE"' : return code '0x1'Stop.*
>
>
>
>
> *###*
> Any pointers how to solve this?
> I will heartfully grateful.
>
>
>
> Thanks and Regards,
> Ajay
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Problem in compiling OpenSSL on Windows-7-32-bit

[Ajay Garg]

Hi All.

Following are the steps I followed :

###
a)
Downloaded nasm.exe from internet, and placed it in the include-path.

b)
*perl Configure VC-WIN32*

c)


*ms\do_nasm.bat*
d)


*nmake -f ms\nt.mak*
e)
*make*





*###*
Compilation runs fine for some time, but then I get hundreds of IDENTICAL
errors as follows ::

###













*tmp32\sha1-586.asm:3964: warning: `PTR' is not a NASM
keywordtmp32\sha1-586.asm:3964: error: comma, colon, decorator or end of
line expecteafter operandtmp32\sha1-586.asm:3970: error: symbol
`__sha1_block_data_order_avx' redefinedtmp32\sha1-586.asm:3970: error:
parser: instruction expectedtmp32\sha1-586.asm:3972: error: parser:
instruction expectedtmp32\sha1-586.asm:3983: error: parser: instruction
expectedtmp32\sha1-586.asm:3985: error: parser: instruction
expectedtmp32\sha1-586.asm:3986: error: parser: instruction
expectedtmp32\sha1-586.asm:3987: warning: label alone on a line without a
colon might in errorNMAKE : fatal error U1077: '"C:\Program Files\Microsoft
Visual Studio 14.0\VC\N\nasm.EXE"' : return code '0x1'Stop.*



*###*
Any pointers how to solve this?
I will heartfully grateful.



Thanks and Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Where to find definitions of certain functions

[Ajay Garg]

I guess we need to look at OpenWrt for MIPS-versions of the libraries.

We do have a device running on MIPS, and linking the OpenWrt-versions of
libcrypto.a and libssl.a (with our framework-binary) works like a charm.


Thanks and Regards,
Ajay

On Mon, Oct 17, 2016 at 7:30 PM, craig_we...@trendmicro.com <
craig_we...@trendmicro.com> wrote:

> I’m interested in the rest of this story.  Does compiling a separate
> library for linking work for you now?  Our product runs on two platforms:
> one Pentium-based and one Mips-based. The Pentium build works fine but the
> Mips build fails at link time with unresolved function references.
>
>
>
> *From:* openssl-users [mailto:openssl-users-boun...@openssl.org] *On
> Behalf Of *Ajay Garg
> *Sent:* Sunday, October 16, 2016 10:16 PM
> *To:* openssl-users@openssl.org
> *Subject:* Re: [openssl-users] Where to find definitions of certain
> functions
>
>
>
> Aah... I guess I was being an idiot.
>
> I just realize that the recommended/best/easier way is to compile openssl
> as a separate library (enabling/disabling/removing features as required),
> and then link this library to our application-binary.
>
> Thanks a ton Salz, you have saved me a LOT of hours :)
>
> Thanks and Regards,
>
> Ajay
>
>
>
> On Sun, Oct 16, 2016 at 10:09 PM, Salz, Rich <rs...@akamai.com> wrote:
>
>
> > Also, I am not using Makefiles, rather compiling each "c unit" using gcc
> using first-principles.
> > Could that be an issue?
>
> Probably.
>
> Only "make" is supported.  You are on your own.
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
>
>
> --
>
> Regards,
> Ajay
>
> TREND MICRO EMAIL NOTICE
> The information contained in this email and any attachments is confidential
> and may be subject to copyright or other intellectual property protection.
> If you are not the intended recipient, you are not authorized to use or
> disclose this information, and we request that you notify us by reply mail or
> telephone and delete the original message from your mail system.
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>


-- 
Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Where to find definitions of certain functions

[Ajay Garg]

Aah... I guess I was being an idiot.

I just realize that the recommended/best/easier way is to compile openssl
as a separate library (enabling/disabling/removing features as required),
and then link this library to our application-binary.


Thanks a ton Salz, you have saved me a LOT of hours :)


Thanks and Regards,
Ajay

On Sun, Oct 16, 2016 at 10:09 PM, Salz, Rich  wrote:

>
> > Also, I am not using Makefiles, rather compiling each "c unit" using gcc
> using first-principles.
> > Could that be an issue?
>
> Probably.
>
> Only "make" is supported.  You are on your own.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>



-- 
Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Where to find definitions of certain functions

[Ajay Garg]

I am bringing in the relevant sources from the cloned openssl-repository,
and comping each "c unit" separately.
Also, I am not using Makefiles, rather compiling each "c unit" using gcc
using first-principles.

Could that be an issue?

On Sun, Oct 16, 2016 at 8:10 PM, Salz, Rich  wrote:

> > ex_data.c:(.text+0xaa6): undefined reference to `sk_num'
>
> Something seems wrong in your build environment.  Make sure you are
> starting with a completely empty build tree.
> -rich salz
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>



-- 
Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Where to find definitions of certain functions

[Ajay Garg]

Thanks Salz.

I get a lot of linking-errors like ::

ex_data.c:(.text+0xaa6): undefined reference to `sk_num'
ex_data.c:(.text+0xb06): undefined reference to `sk_value'
ex_data.c:(.text+0xc5e): undefined reference to `sk_free'


Doing,



*nm -o /usr/lib/i386-linux-gnu/libssl.a | grep
sk_num*/usr/lib/i386-linux-gnu/libssl.a:s3_srvr.o:
U sk_num
/usr/lib/i386-linux-gnu/libssl.a:s3_clnt.o: U sk_num
/usr/lib/i386-linux-gnu/libssl.a:s3_lib.o: U sk_num
/usr/lib/i386-linux-gnu/libssl.a:s23_clnt.o: U sk_num
/usr/lib/i386-linux-gnu/libssl.a:t1_lib.o: U sk_num
/usr/lib/i386-linux-gnu/libssl.a:d1_srtp.o: U sk_num
/usr/lib/i386-linux-gnu/libssl.a:ssl_lib.o: U sk_num
/usr/lib/i386-linux-gnu/libssl.a:ssl_cert.o: U sk_num
/usr/lib/i386-linux-gnu/libssl.a:ssl_ciph.o: U sk_num


Now, if I see, for example in "openssl/ssl/s3_clnt.c", I do not get any
strings for "sk_num", but I do get the strings of the form
"sk_SSL_COMP_num".


Also, I tried doing the following, but could not see any correlation :



*grep -r "define SSL_COMP"
~/openssl/openssl/*/home/ajay/openssl/openssl/crypto/symhacks.h:#
define SSL_COMP_get_compression_methodsSSL_COMP_get_compress_methods
/home/ajay/openssl/openssl/crypto/symhacks.h:#  define
SSL_COMP_set0_compression_methods   SSL_COMP_set0_compress_methods
/home/ajay/openssl/openssl/crypto/symhacks.h:#  define
SSL_COMP_free_compression_methods   SSL_COMP_free_compress_methods
/home/ajay/openssl/openssl/ssl/ssl_ciph.c:#define SSL_COMP_NULL_IDX   0
/home/ajay/openssl/openssl/ssl/ssl_ciph.c:#define SSL_COMP_ZLIB_IDX   1
/home/ajay/openssl/openssl/ssl/ssl_ciph.c:#define SSL_COMP_NUM_IDX2



What's this mystery?



On Sat, Oct 15, 2016 at 10:55 PM, Salz, Rich  wrote:

> > Hardly helps :(
>
> ➢ /usr/lib/i386-linux-gnu/libcrypto.a:a_time.o:0230 T
> ASN1_TIME_to_generalizedtime
>
> Sure it does.  You know it's in a_time.c, which is crypto/asn1/a_time.c
> And if you look in that file you see "IMPLEMENT_ASN1_FJUNCTIONS" with an
> ASN1_TIME argument.  So, start digging.
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>



-- 
Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Where to find definitions of certain functions

[Ajay Garg]

Hardly helps :(

*nm -o /usr/lib/i386-linux-gnu/libcrypto.a  | grep ASN1_TIME_t*
nm: ebcdic.o: no symbols
/usr/lib/i386-linux-gnu/libcrypto.a:a_time.o:0230 T
ASN1_TIME_to_generalizedtime
/usr/lib/i386-linux-gnu/libcrypto.a:ocsp_srv.o: U
ASN1_TIME_to_generalizedtime

On Sat, Oct 15, 2016 at 9:08 PM, Salz, Rich  wrote:

> > grep -r ASN1_TIME\( ~/openssl/openssl/
> > /home/ajay/openssl/openssl/crypto/asn1/a_time.c:int
> i2d_ASN1_TIME(ASN1_TIME *a, unsigned char **pp)
>
> > How to search for such symbols in the cloned source-code?
>
> Much of the ASN1 data structures are created by macros and it will not be
> immediately obvious to newcomers how it works.
>
> Your best bet is to use "nm -o" on the library and find the file, and then
> work backward from there.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>



-- 
Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Where to find definitions of certain functions

[Ajay Garg]

Thanks Matt.


That helped.


However, I am now searching for symbols like ASN_TIME_it, but I get nothing
useful ::

*grep -r ASN1_TIME_it ~/openssl/openssl/*
/home/ajay/openssl/openssl/util/libeay.num:ASN1_TIME_it2715
EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:
/home/ajay/openssl/openssl/util/libeay.num:ASN1_TIME_it2715
EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION:

*grep -r ASN1_TIME\( ~/openssl/openssl/*
/home/ajay/openssl/openssl/crypto/asn1/a_time.c:int i2d_ASN1_TIME(ASN1_TIME
*a, unsigned char **pp)


How to search for such symbols in the cloned source-code?

On Sat, Oct 15, 2016 at 6:20 PM, Matt Caswell <m...@openssl.org> wrote:

>
>
> On 15/10/16 13:43, Ajay Garg wrote:
> > Hi All.
> >
> > I plan to integrate openssl in our client-side-framework, so that we can
> > remove all the unneeded stuff (as the TLS-versions, and
> > certificate-management is controlled by the server only, which is only a
> > limited subset amongst the vast feature-set of openssl).
> >
> > As part of this, I am first bringing in *all* code into our framework,
> > to the extent that the code compiles as the first stage.
> > My progress is going mostly fine, however I am stuck as I am unable to
> > retrieve the definitions of certain symbols (macros I guess), such as ::
> >
> >   ASN1_OCTET_STRING_free
> >   ASN1_OCTET_STRING_new
> >
> >
> > There are others too, but I guess that if I can be known how to retrieve
> > the above definitions, then others will follow similarly.
> > So, will be grateful to hear from you experts :)
>
> See:
>
> https://github.com/openssl/openssl/blob/master/crypto/asn1/tasn_typ.c
>
> Matt
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>



-- 
Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Where to find definitions of certain functions

[Ajay Garg]

Hi All.

I plan to integrate openssl in our client-side-framework, so that we can
remove all the unneeded stuff (as the TLS-versions, and
certificate-management is controlled by the server only, which is only a
limited subset amongst the vast feature-set of openssl).

As part of this, I am first bringing in *all* code into our framework, to
the extent that the code compiles as the first stage.
My progress is going mostly fine, however I am stuck as I am unable to
retrieve the definitions of certain symbols (macros I guess), such as ::

  ASN1_OCTET_STRING_free
  ASN1_OCTET_STRING_new


There are others too, but I guess that if I can be known how to retrieve
the above definitions, then others will follow similarly.
So, will be grateful to hear from you experts :)


Thanks and Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Questions on internal-buffers being used

[Ajay Garg]

Thanks Ben for the reply.

I tried the following, and the code hits the block as commented ::


###
static char inter_bio_buf[1000];
static char network_bio_buf[1000];

{
BIO *inter_bio_buf_bio = NULL, *network_bio_buf_bio = NULL;

inter_bio_buf_bio = BIO_new_mem_buf(inter_bio_buf,
sizeof(inter_bio_buf));
if(inter_bio_buf_bio == NULL)
{
/* Control does not reach here. */
}

network_bio_buf_bio = BIO_new_mem_buf(network_bio_buf,
sizeof(network_bio_buf));
if(network_bio_buf_bio == NULL)
{
/* Control does not reach here. */
}

if(!BIO_make_bio_pair(inter_bio_buf_bio, network_bio_buf_bio))
{
/* CONTROL REACHES HERE. */
}
}


What am I doing wrong?

On Wed, Oct 12, 2016 at 12:59 AM, Benjamin Kaduk <bka...@akamai.com> wrote:

> On 10/11/2016 02:06 PM, Ajay Garg wrote:
>
> Hi All.
>
>
> a)
> In the call,
>
>   int BIO_new_bio_pair(BIO **bio1, size_t writebuf1, BIO 
> **bio2, size_t writebuf2);
>
> are internal-buffers malloc'ed for each of "bio1" and "bio2"?
>
> If yes, is there a way to pass buffers from the application-layer?
> I ask this, because not all systems possess dynamic-memory allocation (or at 
> least "malloc" is not available on all systems).
>
>
> b)
> Irrespective of the values of "writebuf1" and "writebuf2" in a), I see that 
> everything works perfect.
> So, there's got to be some internal-buffer that manages the complete 
> ssl-packet, most probably instantiated via the call
>
>   BIO* BIO_new(BIO_f_ssl());
>
>
> Here too, is it possible to pass the buffer from application-layer (because 
> of same reasons as above)?
>
>
>
> You should be able to produce the desired effect with BIO_new_mem_buf()
> (twice) and attaching the resulting BIOs to each other with
> BIO_make_bio_pair().
>
> -Ben
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>


-- 
Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Questions on internal-buffers being used

[Ajay Garg]

Hi All.


a)
In the call,

  int BIO_new_bio_pair(BIO **bio1, size_t
writebuf1, BIO **bio2, size_t writebuf2);

are internal-buffers malloc'ed for each of "bio1" and "bio2"?

If yes, is there a way to pass buffers from the application-layer?
I ask this, because not all systems possess dynamic-memory allocation
(or at least "malloc" is not available on all systems).

b)
Irrespective of the values of "writebuf1" and "writebuf2" in a), I see
that everything works perfect.
So, there's got to be some internal-buffer that manages the complete
ssl-packet, most probably instantiated via the call

  BIO* BIO_new(BIO_f_ssl());

Here too, is it possible to pass the buffer from application-layer
(because of same reasons as above)?


Will be grateful for pointers.

Thanks and Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Getting the retry reason for a "failed" BIO_write/BIO_read

[Ajay Garg]

On Mon, Oct 10, 2016 at 2:47 PM, Ajay Garg <ajaygargn...@gmail.com> wrote:

>
>
> On Mon, Oct 10, 2016 at 1:31 PM, Viktor Dukhovni <
> openssl-us...@dukhovni.org> wrote:
>
>>
>> > On Oct 10, 2016, at 3:52 AM, Ajay Garg <ajaygargn...@gmail.com> wrote:
>> >
>> > If(BIO_should_read(socket->ssl_bio) != 0)
>> >
>> > If(BIO_should_write(socket->ssl_bio) != 0)
>>
>> In Postfix, we don't bother with the application layer ssl_bio,
>> and just do SSL_read()/SSL_write() directly.  You only need this
>> if you specifically want a BIO API to SSL.
>>
>
I am sorry, but I don't get this :(


In broad words, is there anything wrong in ::

int rc = BIO_write(socket->ssl_bio) / BIO_read(socket->ssl)

followed by

if(rc < 0)
{
  If(BIO_should_read(socket->ssl_bio) != 0)
  {
  }
  If(BIO_should_write(socket->ssl_bio) != 0)
  {
  }
 }

?


>
>> > With this, I could get the entire end-to-end workflow to work 
>>
>> You might not be done yet.  Is the client verifying the server
>> certificate including name checks?  Just doing TLS, without
>> certificate checks, only protects against passive attacks.
>>
>
> Thanks Viktor.
>
> I will add this "enhancement", once I complete the code, in a manner that
> is portable across "any" device.
> Please expect a few questions from me on other threads :P
>
>
> Thanks and Regards,
> Ajay
>
>>
>> --
>> Viktor.
>>
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>
>
>
> --
> Regards,
> Ajay
>



-- 
Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Getting the retry reason for a "failed" BIO_write/BIO_read

[Ajay Garg]

On Mon, Oct 10, 2016 at 1:31 PM, Viktor Dukhovni <openssl-us...@dukhovni.org
> wrote:

>
> > On Oct 10, 2016, at 3:52 AM, Ajay Garg <ajaygargn...@gmail.com> wrote:
> >
> > If(BIO_should_read(socket->ssl_bio) != 0)
> >
> > If(BIO_should_write(socket->ssl_bio) != 0)
>
> In Postfix, we don't bother with the application layer ssl_bio,
> and just do SSL_read()/SSL_write() directly.  You only need this
> if you specifically want a BIO API to SSL.
>
> > With this, I could get the entire end-to-end workflow to work 
>
> You might not be done yet.  Is the client verifying the server
> certificate including name checks?  Just doing TLS, without
> certificate checks, only protects against passive attacks.
>

Thanks Viktor.

I will add this "enhancement", once I complete the code, in a manner that
is portable across "any" device.
Please expect a few questions from me on other threads :P


Thanks and Regards,
Ajay

>
> --
> Viktor.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>



-- 
Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Root-Level queries while using SSL-connections wrapping "sockets"

[Ajay Garg]

Hi All.

I guess all my theories are bang on, as the entire framework was integrated
seamlessly making use of the above "theories".

Thanks a ton to everyone, and extra thanks to Viktor 

Thanks and Regards,
Ajay

On 10 Oct 2016 6:34 a.m., "Ajay Garg" <ajaygargn...@gmail.com> wrote:

> Thanks Michael for the reply.
>
> And yes, your points are absolutely valid.
>
> We do not assume anything at the client/server as such, we just read
> the byte-streams, and generate (MQTT) packets out of bytestreams as
> and when the starting- and ending- boundaries of a (new) MQTT-packet
> are received.
>
>
> Still, I believe all my 3 questions (step a, step b, and the 8-point
> story in step c) are independent of this, and would like to hear from
> you experts as to if my understanding of all those 3 steps is correct,
> including the all important assumption
>
> *Implicit in this workflow is my assumption that SSL too builds up a
> packet for every BIO_write done over "bio1". *
>
> I say it the most important, because our application is MQTT-based,
> and all our communication is request/response based; we send a packet,
> and expect an acknowledgement.
>
> In other words, if my implicit assumption is correct, then every
> "BIO_write(bio1)" would generate a complete SSL-packet, which would be
> available at "bio2" instantly and synchronously - ready to be
> transferred over the wire.
>
>
> Again, would be thankful from the bottom of my heart, to hear
> confirmations/rejections regarding my theories in step a), step b) and
> 8-point-story in step c) as per my previous email.
>
>
>
> Thanks and Regards,
> Ajay
>
> On Mon, Oct 10, 2016 at 2:39 AM, Michael Wojcik
> <michael.woj...@microfocus.com> wrote:
> >> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
> Behalf
> >> Of Ajay Garg
> >> Sent: Sunday, October 09, 2016 14:12
> >>
> >> Also, for all my cases, Nagle's algorithm has been disabled on the
> >> client as well as the server, so every write (at client/server)
> >> constitutes a packet-transferred.
> >
> > This assumption is incorrect. Nagle is not the only factor which
> interferes with a 1-to-1 mapping between application sends and (IP) packets
> on the wire. The peer's receive window, the interface and path MTUs,
> fragmentation, transient network failures ... many  things can either split
> an application message into multiple IP packets or even multiple TCP
> segments, or cause multiple application messages to be coalesced into a
> single TCP segment (which usually is also a single IP packet, now that path
> MTU determination usually works properly).
> >
> > You should never assume TCP is anything other than a byte-stream
> service. An application that makes any assumptions about how its send
> operations translate into TCP segments or IP packets is asking for trouble.
> >
> > --
> > Michael Wojcik
> > Distinguished Engineer, Micro Focus
> >
> >
> >
> > --
> > openssl-users mailing list
> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
>
> --
> Regards,
> Ajay
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Getting the retry reason for a "failed" BIO_write/BIO_read

[Ajay Garg]

Following works :

If(BIO_should_read(socket->ssl_bio) != 0)

If(BIO_should_write(socket->ssl_bio) != 0)

With this, I could get the entire end-to-end workflow to work 

Thanks a ton for all the help !!!

On Mon, Oct 10, 2016 at 11:50 AM, Ajay Garg <ajaygargn...@gmail.com> wrote:

> Hi All.
>
> Taking the socket-structure as ::
>
> 
> #
>SSL *ssl;
>
>BIO *ssl_bio; // app-payload-bytes will be
> written by app into it.
>BIO *inter_bio;   // intermediate-bio, have no idea
> what it really is used for.
>BIO *network_bio;  // app-payload-encrypted-bytes will
> "emerge" from this bio, ready to be written over the wire
> 
> #
>
>
>
>
> and assuming all initialization went fine, what is the correct way to get
> the retry-reason ::
>
> 
> #
> if(BIO_should_retry(socket->ssl_bio) != 0)
> {
>   int reason =  BIO_get_retry_reason(socket->ssl_bio);
> }
>
>   OR
>
> if(BIO_should_retry(socket->ssl_bio) != 0)
> {
>   int reason = 
> BIO_get_retry_reason(BIO_get_retry_BIO(socket->ssl_bio,
> NULL));
> }
> 
> #
>
>
> Right now, I am receiving 0 (zero) as the reason in both the cases, and
> none of SSL_ERROR_WANT_WRITE or SSL_ERROR_WANT_READ (in either case).
>
>
> Thanks and Regards,
> Ajay
>
>
>
> --
> Regards,
> Ajay
>



-- 
Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Getting the retry reason for a "failed" BIO_write/BIO_read

[Ajay Garg]

Hi Viktor,

I am already setting that.

   socket->ssl_bio = BIO_new(BIO_f_ssl());
if (!(socket->ssl_bio))
{
HANDLE_CATASTROPHIC_INIT_ERROR("client-ssl-bio")
return;
}

SSL_set_connect_state(socket->ssl);
SSL_set_bio(socket->ssl, socket->inter_bio, socket->inter_bio);
BIO_set_ssl(socket->ssl_bio, socket->ssl, BIO_NOCLOSE);


On Mon, Oct 10, 2016 at 12:19 PM, Viktor Dukhovni <
openssl-us...@dukhovni.org> wrote:

>
> > On Oct 10, 2016, at 2:20 AM, Ajay Garg <ajaygargn...@gmail.com> wrote:
> >
> >BIO *inter_bio;   // intermediate-bio, have no
> idea what it really is used for.
>
> The internal BIO from BIO_new_bio_pair must be attached to the SSL
> handle via:
>
> SSL_set_bio(ssl, internal_bio, internal_bio);
>
> When SSL writes ciphertext to the internal bio, you can read that via
> the network_bio.  When you write to the network_bio, SSL can read the
> data via the internal_bio.
>
> --
> Viktor.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>



-- 
Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Getting the retry reason for a "failed" BIO_write/BIO_read

[Ajay Garg]

Hi All.

Taking the socket-structure as ::


#
   SSL *ssl;

   BIO *ssl_bio; // app-payload-bytes will be
written by app into it.
   BIO *inter_bio;   // intermediate-bio, have no idea
what it really is used for.
   BIO *network_bio;  // app-payload-encrypted-bytes will
"emerge" from this bio, ready to be written over the wire

#




and assuming all initialization went fine, what is the correct way to get
the retry-reason ::


#
if(BIO_should_retry(socket->ssl_bio) != 0)
{
  int reason =  BIO_get_retry_reason(socket->ssl_bio);
}

  OR

if(BIO_should_retry(socket->ssl_bio) != 0)
{
  int reason =
BIO_get_retry_reason(BIO_get_retry_BIO(socket->ssl_bio, NULL));
}

#


Right now, I am receiving 0 (zero) as the reason in both the cases, and
none of SSL_ERROR_WANT_WRITE or SSL_ERROR_WANT_READ (in either case).


Thanks and Regards,
Ajay



-- 
Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] [Version-2] Sequence of steps to initialize a ssl-session (only client-mode)

[Ajay Garg]

Damn the semicolon at the end :(
Sorry for the noise.


Thanks and Regards,
Ajay

On Mon, Oct 10, 2016 at 11:23 AM, Ajay Garg <ajaygargn...@gmail.com> wrote:

> [Thanks Viktor, I made the change as suggested by you in the other
> incomplete email that I sent accidentally].
>
>
> Hi All.
>
> We are just dealing with the client-side, and following are the steps ::
>
> 
> #
> SSL_library_init();
> OpenSSL_add_ssl_algorithms();
> OpenSSL_add_all_algorithms();
> SSL_load_error_strings();
> ERR_load_crypto_strings();
>
> solitary_ssl_ctx = SSL_CTX_new(SSLv23_client_method());
> if(solitary_ssl_ctx == NULL)
> {
> // Control does not reach here.
> }
>
> if(!SSL_CTX_use_certificate_file(solitary_ssl_ctx,
> "/path/of/certificate", SSL_FILETYPE_PEM))
> {
> // Control does not reach here.
> }
>
> if(!SSL_CTX_use_PrivateKey_file(solitary_ssl_ctx, "/path/of/key",
> SSL_FILETYPE_PEM))
> {
> // Control does not reach here.
> }
>
> socket->ssl = SSL_new(solitary_ssl_ctx);
> if(socket->ssl == NULL)
> {
> // Control does not reach here.
> }
>
> if (!BIO_new_bio_pair(&(socket->inter_bio), SSL_BUFFER_SIZE,
> &(socket->network_bio), SSL_BUFFER_SIZE));
> {
> // *CONTROL REACHES HERE*
> }
>
> socket->ssl_bio = BIO_new(BIO_f_ssl());
> if (!(socket->ssl_bio))
> {
> // Status Unknown
> }
>
> SSL_set_connect_state(socket->ssl);
> SSL_set_bio(socket->ssl, socket->inter_bio, socket->inter_bio);
> (void)BIO_set_ssl(socket->ssl_bio, socket->ssl, BIO_NOCLOSE);
> 
> #
>
>
>
>
> The socket structure has the following ::
>
> 
> #
>SSL *ssl;
>
>BIO *ssl_bio; // app-payload-bytes will be
> written by app into it.
>BIO *inter_bio;   // intermediate-bio, have no idea
> what it really is used for.
>BIO *network_bio;  // app-payload-encrypted-bytes will
> "emerge" from this bio, ready to be written over the wire
> 
> #
>
>
>
> I have followed the minimal steps (only for client-mode) as per
> http://opensource.apple.com/source/OpenSSL096/OpenSSL096-
> 6.2/openssl/ssl/ssltest.c
> So, what am I missing which is causing
>
>BIO_new_bio_pair
>
> to fail?
>
>
> Thanks and Regards,
> Ajay
>
>


-- 
Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] [Version-2] Sequence of steps to initialize a ssl-session (only client-mode)

[Ajay Garg]

[Thanks Viktor, I made the change as suggested by you in the other
incomplete email that I sent accidentally].


Hi All.

We are just dealing with the client-side, and following are the steps ::

#
SSL_library_init();
OpenSSL_add_ssl_algorithms();
OpenSSL_add_all_algorithms();
SSL_load_error_strings();
ERR_load_crypto_strings();

solitary_ssl_ctx = SSL_CTX_new(SSLv23_client_method());
if(solitary_ssl_ctx == NULL)
{
// Control does not reach here.
}

if(!SSL_CTX_use_certificate_file(solitary_ssl_ctx,
"/path/of/certificate", SSL_FILETYPE_PEM))
{
// Control does not reach here.
}

if(!SSL_CTX_use_PrivateKey_file(solitary_ssl_ctx, "/path/of/key",
SSL_FILETYPE_PEM))
{
// Control does not reach here.
}

socket->ssl = SSL_new(solitary_ssl_ctx);
if(socket->ssl == NULL)
{
// Control does not reach here.
}

if (!BIO_new_bio_pair(&(socket->inter_bio), SSL_BUFFER_SIZE,
&(socket->network_bio), SSL_BUFFER_SIZE));
{
// *CONTROL REACHES HERE*
}

socket->ssl_bio = BIO_new(BIO_f_ssl());
if (!(socket->ssl_bio))
{
// Status Unknown
}

SSL_set_connect_state(socket->ssl);
SSL_set_bio(socket->ssl, socket->inter_bio, socket->inter_bio);
(void)BIO_set_ssl(socket->ssl_bio, socket->ssl, BIO_NOCLOSE);
#




The socket structure has the following ::

#
   SSL *ssl;

   BIO *ssl_bio; // app-payload-bytes will be
written by app into it.
   BIO *inter_bio;   // intermediate-bio, have no idea
what it really is used for.
   BIO *network_bio;  // app-payload-encrypted-bytes will
"emerge" from this bio, ready to be written over the wire
#



I have followed the minimal steps (only for client-mode) as per
http://opensource.apple.com/source/OpenSSL096/OpenSSL096-6.2/openssl/ssl/ssltest.c
So, what am I missing which is causing

   BIO_new_bio_pair

to fail?


Thanks and Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Sequence of steps to initialize a ssl-session (only client-mode)

[Ajay Garg]

Hi All.

We are just dealing with the client-side, and following are the steps ::

SSL_library_init();
OpenSSL_add_ssl_algorithms();
OpenSSL_add_all_algorithms();
SSL_load_error_strings();
ERR_load_crypto_strings();

solitary_ssl_ctx = SSL_CTX_new(TLSv1_2_client_method());
if(solitary_ssl_ctx == NULL)
{

HANDLE_CATASTROPHIC_INIT_ERROR("SSL-Context")
resetDevice();
}

if(!SSL_CTX_use_certificate_file(solitary_ssl_ctx,
"/home/sensegrow/cert", SSL_FILETYPE_PEM))
{
HANDLE_CATASTROPHIC_INIT_ERROR("SSL-Context-Certificate")
resetDevice();
}

if(!SSL_CTX_use_PrivateKey_file(solitary_ssl_ctx,
"/home/sensegrow/key", SSL_FILETYPE_PEM))
{
HANDLE_CATASTROPHIC_INIT_ERROR("SSL-Context-Key")
resetDevice();
}

ssl_init_successful = 1;



-- 
Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] [PLEASE IGNORE] Re: Sequence of steps to initialize a ssl-session (only client-mode)

[Ajay Garg]

Sorry, the "send" button was clicked accidentally :(

On Mon, Oct 10, 2016 at 10:55 AM, Ajay Garg <ajaygargn...@gmail.com> wrote:
> Hi All.
>
> We are just dealing with the client-side, and following are the steps ::
>
> SSL_library_init();
> OpenSSL_add_ssl_algorithms();
> OpenSSL_add_all_algorithms();
> SSL_load_error_strings();
> ERR_load_crypto_strings();
>
> solitary_ssl_ctx = SSL_CTX_new(TLSv1_2_client_method());
> if(solitary_ssl_ctx == NULL)
> {
>
> HANDLE_CATASTROPHIC_INIT_ERROR("SSL-Context")
> resetDevice();
> }
>
> if(!SSL_CTX_use_certificate_file(solitary_ssl_ctx,
> "/home/sensegrow/cert", SSL_FILETYPE_PEM))
> {
> HANDLE_CATASTROPHIC_INIT_ERROR("SSL-Context-Certificate")
> resetDevice();
> }
>
> if(!SSL_CTX_use_PrivateKey_file(solitary_ssl_ctx,
> "/home/sensegrow/key", SSL_FILETYPE_PEM))
> {
> HANDLE_CATASTROPHIC_INIT_ERROR("SSL-Context-Key")
> resetDevice();
> }
>
> ssl_init_successful = 1;
>
>
>
> --
> Regards,
> Ajay



-- 
Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Root-Level queries while using SSL-connections wrapping "sockets"

[Ajay Garg]

Thanks Michael for the reply.

And yes, your points are absolutely valid.

We do not assume anything at the client/server as such, we just read
the byte-streams, and generate (MQTT) packets out of bytestreams as
and when the starting- and ending- boundaries of a (new) MQTT-packet
are received.


Still, I believe all my 3 questions (step a, step b, and the 8-point
story in step c) are independent of this, and would like to hear from
you experts as to if my understanding of all those 3 steps is correct,
including the all important assumption

*Implicit in this workflow is my assumption that SSL too builds up a
packet for every BIO_write done over "bio1". *

I say it the most important, because our application is MQTT-based,
and all our communication is request/response based; we send a packet,
and expect an acknowledgement.

In other words, if my implicit assumption is correct, then every
"BIO_write(bio1)" would generate a complete SSL-packet, which would be
available at "bio2" instantly and synchronously - ready to be
transferred over the wire.


Again, would be thankful from the bottom of my heart, to hear
confirmations/rejections regarding my theories in step a), step b) and
8-point-story in step c) as per my previous email.



Thanks and Regards,
Ajay

On Mon, Oct 10, 2016 at 2:39 AM, Michael Wojcik
<michael.woj...@microfocus.com> wrote:
>> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
>> Of Ajay Garg
>> Sent: Sunday, October 09, 2016 14:12
>>
>> Also, for all my cases, Nagle's algorithm has been disabled on the
>> client as well as the server, so every write (at client/server)
>> constitutes a packet-transferred.
>
> This assumption is incorrect. Nagle is not the only factor which interferes 
> with a 1-to-1 mapping between application sends and (IP) packets on the wire. 
> The peer's receive window, the interface and path MTUs, fragmentation, 
> transient network failures ... many  things can either split an application 
> message into multiple IP packets or even multiple TCP segments, or cause 
> multiple application messages to be coalesced into a single TCP segment 
> (which usually is also a single IP packet, now that path MTU determination 
> usually works properly).
>
> You should never assume TCP is anything other than a byte-stream service. An 
> application that makes any assumptions about how its send operations 
> translate into TCP segments or IP packets is asking for trouble.
>
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



-- 
Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Root-Level queries while using SSL-connections wrapping "sockets"

[Ajay Garg]

On Sun, Oct 9, 2016 at 10:55 PM, Viktor Dukhovni
<openssl-us...@dukhovni.org> wrote:
>
>> On Oct 9, 2016, at 10:47 AM, Ajay Garg <ajaygargn...@gmail.com> wrote:
>>
>>> However, it might sometimes return SSL_ERROR_WANT_READ, in which
>>> case, the SSL layer wants to read, even though the application
>>> wants to write.  Your job is to do the read on the SSL layer's
>>> behalf, and then retry the write.
>>
>> For this particular sub-case, let's say SSL-layer wants to obtain "n"
>> bytes from the socket/wire.
>>
>> So, in this case, is it ok to do a blocking-read on the socket, unless
>> "n" bytes are received (of course, a socket "error" will be handled in
>> the blocking-call; it's just that any socket-timeouts will not be
>> considered).
>
> Yes, you can do a blocking read (provided you have already flushed all
> pending writes).

Thanks a ton Viktor for the reply.

(Yes, in the above case I mentioned, all pending writes would have
been flushed).


Also, I will be grateful if you could let me know if ANY of the
sub-flows in ANY of the flows below is wrong, remembering that "bio1"
is the SSL-BIO where the app-payload-bytes are written in, and "bio2"
is the IN-MEMORY-BIO where the app-payload-encrypted-bytes emerge.

app   <==>   bio1   <==>bio2   <==>   socket

Also, for all my cases, Nagle's algorithm has been disabled on the
client as well as the server, so every write (at client/server)
constitutes a packet-transferred.


a)
Can

   BIO_write(bio1, buf, n)

return a positive, non-zero return-value other than "n"?
In other words, is it possible that only partial-bytes are written?


b)
Let's say

   BIO_write(bio1, buf, n)

was successful in writing "n" bytes to "bio1".

So, will ALL the app-payload-encrypted-bytes be available at "bio2"
immediately in a synchronous manner (so that they can be immediately
sent to the server over the wire) ?

Implicit in this workflow is my assumption that SSL too builds up a
packet for every BIO_write done over "bio1".


c)
Will the following sequence happen exactly as follows ::

   i)
   App wants to read some bytes, but in a probing manner (bytes
may/may-not have been sent by server).

   ii)
   Now, currently, "bio1", "bio2", "socket" are in clean-state.
   Nothing is pending "in the real sense" to be written/read anywhere.

   iii)
   When app does

   BIO_read(bio1)

   SSL_ERROR_WANT_READ would be returned (after all, "bio1" cannot
provide any app-payload-bytes unless it
   has received any app-payload-encrypted-bytes from server).

   iv)
   Doing

   BIO_get_read_request(bio2)

   would return 0.


   v)
   So, we try reading 1 byte from the socket (in a non-blocking
manner, obviously).
   I successful, we write the 1 byte into "bio2" (and so, "bio1"
will get the smell of a new encrypted packet).


   vi)
   Thereafter, when app again does

  BIO_read(bio1),

   (assuming we do not hit any re-negotiation case in this cycle) this time,

  BIO_get_read_request(bio2)

   will return a non-zero value "n".


  vii)
  We read the "n" bytes over the wire, and write them to "bio2".


  viii)
  Finally, the "m" decrypted-packet-bytes will be available at "bio1",
from the encrypted-packet
  of length "n+1" bytes.

Is my story of 8-points in case c) correct? :)


I am sorry for bothering you so much, but I can take comfort from the
fact that such idiotic questions will help noobs like me integrate
openssl faster, with better understanding of the internals, which will
obviously lead to slicker code.


Thanks again to everyone for the help so far 


Thanks and Regards,
Ajay






>
> --
> Viktor.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



-- 
Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Root-Level queries while using SSL-connections wrapping "sockets"

[Ajay Garg]

Hi Viktor.

On Fri, Oct 7, 2016 at 11:17 PM, Viktor Dukhovni
<openssl-us...@dukhovni.org> wrote:
> On Fri, Oct 07, 2016 at 10:30:06PM +0530, Ajay Garg wrote:
>
>> Ok, so for sending app-payload-bytes, we do a bio_write() to "bio1",
>> and if "bio1" requires reading from bio2/peer, bio_write() will return
>> SSL_ERROR_WANT_READ (even for blocking sockets). We then read-in some
>> app-payload-encrypted-bytes from device-socket,
>
> No, it will *usually* return SSL_ERROR_WANT_WRITE, that's when you
> write "some" (based on pending data amount from bio2) to the network
> that you read from bio2.  Those writes might be written via a buffer
> you interpose, however it is important to flush that buffer as
> much as possible before attempting any network reads (flush fully
> if the network reads are potentially blocking).
>
> However, it might sometimes return SSL_ERROR_WANT_READ, in which
> case, the SSL layer wants to read, even though the application
> wants to write.  Your job is to do the read on the SSL layer's
> behalf, and then retry the write.

For this particular sub-case, let's say SSL-layer wants to obtain "n"
bytes from the socket/wire.

So, in this case, is it ok to do a blocking-read on the socket, unless
"n" bytes are received (of course, a socket "error" will be handled in
the blocking-call; it's just that any socket-timeouts will not be
considered).



I hope the following is NOT happening internally ::

*
SSL-layer "advertises" that it wants "n" bytes from socket/wire.

*
However, in reality, it first wants "x" bytes from socket/wire, then
actually wants to send "m" bytes, and then finally wants to receive
the remaining "n-x" bytes from socket/wire.


I am sure it is not happening, just want to confirm :)

>
> Where "some" is obtained by queried bio2 for the amount of pending
> data.  You can loop reading/sending smaller amounts that if the
> entire amount is too big to write to the target in one go without
> blocking.  Otherwise, you need a large enough write buffer downstream.
> If you can't fully drain bio2's output in one go, just keep the
> socket selected for write and try again later when more space is
> available.
>
>> put them into "bio2"
>> (thus internally fulfilling bio1's need for read), and then again try
>> bio_write() to "bio1" WITH IDENTICAL APP-PAYLOAD-BYTES. If it again
>> returns SSL_ERROR_WANT_READ, we repeat the cycle.
>
> Well, you may not fulfill that need, if you don't drain all the
> pending data, and so the SSL_ERROR_WANT_... may repeat.  What you
> do with bio2 has no direct relationship on the direction of the
> I/O in bio1.  Just keep track of whether the crypto wants to read
> or write, and whether either bio2 or any buffer you interpose
> downstream has pending data.  Then move data between the network
> and bio2 as appropriate.
>
>> For reading app-payload-bytes, we do a bio_read() from "bio1", and if
>> "bio1" requires writing bytes to bio2/peer, bio_read() will return
>> SSL_ERROR_WANT_WRITE (even for blocking sockets).
>
> No, it will *usually* return SSL_ERROR_WANT_READ, that's when you
> read "some" (based on desired read size from bio2) from the network
> and write the results to bio2.  Those reads might be satisfied from
> a buffer you interpose.
>
> However, it might sometimes return SSL_ERROR_WANT_WRITE, in which
> case, the SSL layer wants to write, even though the application wants
> to read.  Your job is to do the write on the SSL layer's behalf,
> and then retry the read.
>
>> We then pick up the
>> app-payload-encrypted-bytes from "bio2", transfer them over the wire
>> via device-specific-socket (thus fulfilling bio1's need to send bytes
>> to peer), and then again try bio_read() from "bio1" WITH IDENTICAL
>> APP-PAYLOAD-BYTES. If it again returns SSL_ERROR_WANT_WRITE, we repeat
>> the cycle.
>
> When retrying app-layer reads, you do not need to provide the same
> buffer or read request size on subsequent attempts.
>
>> Obviously, for the above two sub-plots, the only chance of failure if
>> reading/writing bytes fails over the wire.
>> But that is not the norm; if it does happen, then everything will be
>> restarted from scratch (at least by me).
>
>> If yes, then it seems everything can be done fully synchronously for
>> blocking-sockets,
>
> No, synchronous operation will not work.  The network may not be
> ready to receive more data when you're ready to write (network
> layer data), or have more data when you're ready to read.  Use of
> bio-pairs with bl

Re: [openssl-users] Root-Level queries while using SSL-connections wrapping "sockets"

[Ajay Garg]

Thanks Viktor.

On all our device-types, we are using blocking-sockets, but reads can
signal that no data is available (equivalent to SO_RCVTIMEO value set
as the socket-option on linux-like systems).

It seems you have provided me enough insight to get my hands dirty :)


Thanks and Regards,
Ajay

On Fri, Oct 7, 2016 at 11:17 PM, Viktor Dukhovni
<openssl-us...@dukhovni.org> wrote:
> On Fri, Oct 07, 2016 at 10:30:06PM +0530, Ajay Garg wrote:
>
>> Ok, so for sending app-payload-bytes, we do a bio_write() to "bio1",
>> and if "bio1" requires reading from bio2/peer, bio_write() will return
>> SSL_ERROR_WANT_READ (even for blocking sockets). We then read-in some
>> app-payload-encrypted-bytes from device-socket,
>
> No, it will *usually* return SSL_ERROR_WANT_WRITE, that's when you
> write "some" (based on pending data amount from bio2) to the network
> that you read from bio2.  Those writes might be written via a buffer
> you interpose, however it is important to flush that buffer as
> much as possible before attempting any network reads (flush fully
> if the network reads are potentially blocking).
>
> However, it might sometimes return SSL_ERROR_WANT_READ, in which
> case, the SSL layer wants to read, even though the application
> wants to write.  Your job is to do the read on the SSL layer's
> behalf, and then retry the write.
>
> Where "some" is obtained by queried bio2 for the amount of pending
> data.  You can loop reading/sending smaller amounts that if the
> entire amount is too big to write to the target in one go without
> blocking.  Otherwise, you need a large enough write buffer downstream.
> If you can't fully drain bio2's output in one go, just keep the
> socket selected for write and try again later when more space is
> available.
>
>> put them into "bio2"
>> (thus internally fulfilling bio1's need for read), and then again try
>> bio_write() to "bio1" WITH IDENTICAL APP-PAYLOAD-BYTES. If it again
>> returns SSL_ERROR_WANT_READ, we repeat the cycle.
>
> Well, you may not fulfill that need, if you don't drain all the
> pending data, and so the SSL_ERROR_WANT_... may repeat.  What you
> do with bio2 has no direct relationship on the direction of the
> I/O in bio1.  Just keep track of whether the crypto wants to read
> or write, and whether either bio2 or any buffer you interpose
> downstream has pending data.  Then move data between the network
> and bio2 as appropriate.
>
>> For reading app-payload-bytes, we do a bio_read() from "bio1", and if
>> "bio1" requires writing bytes to bio2/peer, bio_read() will return
>> SSL_ERROR_WANT_WRITE (even for blocking sockets).
>
> No, it will *usually* return SSL_ERROR_WANT_READ, that's when you
> read "some" (based on desired read size from bio2) from the network
> and write the results to bio2.  Those reads might be satisfied from
> a buffer you interpose.
>
> However, it might sometimes return SSL_ERROR_WANT_WRITE, in which
> case, the SSL layer wants to write, even though the application wants
> to read.  Your job is to do the write on the SSL layer's behalf,
> and then retry the read.
>
>> We then pick up the
>> app-payload-encrypted-bytes from "bio2", transfer them over the wire
>> via device-specific-socket (thus fulfilling bio1's need to send bytes
>> to peer), and then again try bio_read() from "bio1" WITH IDENTICAL
>> APP-PAYLOAD-BYTES. If it again returns SSL_ERROR_WANT_WRITE, we repeat
>> the cycle.
>
> When retrying app-layer reads, you do not need to provide the same
> buffer or read request size on subsequent attempts.
>
>> Obviously, for the above two sub-plots, the only chance of failure if
>> reading/writing bytes fails over the wire.
>> But that is not the norm; if it does happen, then everything will be
>> restarted from scratch (at least by me).
>
>> If yes, then it seems everything can be done fully synchronously for
>> blocking-sockets,
>
> No, synchronous operation will not work.  The network may not be
> ready to receive more data when you're ready to write (network
> layer data), or have more data when you're ready to read.  Use of
> bio-pairs with blocking sockets is highly risky, you'll probably
> dead-lock with some regularity.
>
>> thus eliminating the need of multiple threads,
>
> You don't need threads, an event loop will do.  Indeed an event
> loop is generally better, don't know whether the same bio-pair is
> safe for use by multiple threads.
>
> You just need to be able to perform the equivalent of
>
> select()/poll()/...
>
> on whatever interface you have for moving data to/from
> the network.
>
> --
> Viktor.
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



-- 
Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Root-Level queries while using SSL-connections wrapping "sockets"

[Ajay Garg]

Thanks for the reply Viktor.

On Fri, Oct 7, 2016 at 8:27 PM, Jakob Bohm <jb-open...@wisemo.com> wrote:
> On 07/10/2016 16:35, Ajay Garg wrote:
>>
>> Hi Viktor.
>>
>> Thanks for your reply, and I am sorry for being idiotic, OpenSSL does
>> seem daunting, but I am learning :)
>>
>> Also, let's not bother too much about the APIs/methods as such.
>> I will be grateful if you could confirm/reject my
>> architectural-understanding so far.
>>
>> Let's say "bio1" is the SSL-BIO, and "bio2" is the In-Memory-BIO, and
>> they have been made a pair, with the architecture being ::
>>
>> App <=> bio1 <=> bio2 <=> device-specific-socket
>>
> One caveat for both scenarios below:
>
> RW2a: During step R2 or W2, the SSL/TLS protocol may need to
> transmit some data in the opposite direction in order to handle
> automatically setting or changing the encryption keys etc.  Thus
> during W2, some data may be read from bio2 and during R2, some
> data may be written to bio2.
>
> This doesn't happen every time, but it always happens for the
> first app-payload-bytes, and it may happen at any later time
> subject to changes as the protocol and/or library are improved.

Ok, so for sending app-payload-bytes, we do a bio_write() to "bio1",
and if "bio1" requires reading from bio2/peer, bio_write() will return
SSL_ERROR_WANT_READ (even for blocking sockets). We then read-in some
app-payload-encrypted-bytes from device-socket, put them into "bio2"
(thus internally fulfilling bio1's need for read), and then again try
bio_write() to "bio1" WITH IDENTICAL APP-PAYLOAD-BYTES. If it again
returns SSL_ERROR_WANT_READ, we repeat the cycle.

For reading app-payload-bytes, we do a bio_read() from "bio1", and if
"bio1" requires writing bytes to bio2/peer, bio_read() will return
SSL_ERROR_WANT_WRITE (even for blocking sockets). We then pick up the
app-payload-encrypted-bytes from "bio2", transfer them over the wire
via device-specific-socket (thus fulfilling bio1's need to send bytes
to peer), and then again try bio_read() from "bio1" WITH IDENTICAL
APP-PAYLOAD-BYTES. If it again returns SSL_ERROR_WANT_WRITE, we repeat
the cycle.

Obviously, for the above two sub-plots, the only chance of failure if
reading/writing bytes fails over the wire.
But that is not the norm; if it does happen, then everything will be
restarted from scratch (at least by me).


Is my understanding correct (especially for the case if
blocking-sockets are being used throughout)?

If yes, then it seems everything can be done fully synchronously for
blocking-sockets, thus eliminating the need of multiple threads, and
thus enabling us to integrate OpenSSL seamlessly in our already
existing framework across all devices that we have ported our
framework to (devices with/without operating-systems, with/without
GPRS/Wifi).

So, eagerly awaiting your reply :)



Thanks a ton for the lightning-quick help so far 



Thanks and Regards,
Ajay


>
>
>> So, for writes, following steps can be made to happen synchronously
>> (even with blocking device-specific-sockets) ::
>>
>> W1. App writes x app-payload-bytes to bio1.
>>
>> W2. Internally, x app-payload-bytes (at bio1) become y
>> app-payload-encrypted-bytes (at bio2).
>>
>> W3. Thereafter, the y app-payload-encrypted-bytes are transferred
>> over the wire via the device-specific-socket.
>>
>> I think W2 is the key-step architecturally.
>>
>>
>> For reads, following steps can be made to happen synchronously (even
>> with blocking device-specific-sockets, carrying read-timeout feature)
>> ::
>>
>>R1. App wants x app-payload-bytes.
>>
>>R2. If bio1 can produce at least x app-payload-bytes, then we are done.
>>
>>  Else, we read some (let's say n) app-payload-encrypted-bytes
>> from device-specific-socket, write them into bio2, and
>>  again enquire if bio1 can now produce at least x
>> app-payload-bytes.
>>
>>  If still not, we keep reading n app-payload-encrypted-bytes
>> from device-specific-socket and writing them into bio2, until
>>  bio1 can produce at least x app-payload-bytes.
>>
>>R3. Finally, App reads x app-payload-bytes.
>>
>> Here too, I think R2 is the key-step architecturally.
>>
>>
>>
>> Is my above architectural-understanding of the workflow between App
>> and Device-Specific-Socket correct?
>>
>>
>> Anyway, thanks for your help so far.
>>
>>
>> Thanks and Regards,
>> Ajay
>>
>>
>>
>>
>> On Fri, Oct 7, 

Re: [openssl-users] Root-Level queries while using SSL-connections wrapping "sockets"

[Ajay Garg]

Hi Viktor.

Thanks for your reply, and I am sorry for being idiotic, OpenSSL does
seem daunting, but I am learning :)

Also, let's not bother too much about the APIs/methods as such.
I will be grateful if you could confirm/reject my
architectural-understanding so far.

Let's say "bio1" is the SSL-BIO, and "bio2" is the In-Memory-BIO, and
they have been made a pair, with the architecture being ::

App <=> bio1 <=> bio2 <=> device-specific-socket


So, for writes, following steps can be made to happen synchronously
(even with blocking device-specific-sockets) ::

   W1. App writes x app-payload-bytes to bio1.

   W2. Internally, x app-payload-bytes (at bio1) become y
app-payload-encrypted-bytes (at bio2).

   W3. Thereafter, the y app-payload-encrypted-bytes are transferred
over the wire via the device-specific-socket.

I think W2 is the key-step architecturally.


For reads, following steps can be made to happen synchronously (even
with blocking device-specific-sockets, carrying read-timeout feature)
::

  R1. App wants x app-payload-bytes.

  R2. If bio1 can produce at least x app-payload-bytes, then we are done.

Else, we read some (let's say n) app-payload-encrypted-bytes
from device-specific-socket, write them into bio2, and
again enquire if bio1 can now produce at least x app-payload-bytes.

If still not, we keep reading n app-payload-encrypted-bytes
from device-specific-socket and writing them into bio2, until
bio1 can produce at least x app-payload-bytes.

  R3. Finally, App reads x app-payload-bytes.

Here too, I think R2 is the key-step architecturally.



Is my above architectural-understanding of the workflow between App
and Device-Specific-Socket correct?


Anyway, thanks for your help so far.


Thanks and Regards,
Ajay




On Fri, Oct 7, 2016 at 3:25 PM, Viktor Dukhovni
<openssl-us...@dukhovni.org> wrote:
> On Fri, Oct 07, 2016 at 12:28:46PM +0530, Ajay Garg wrote:
>
>> I realise I am still stuck with the original issue.
>
> Failure to read the documentation closely.
>
>> Also, how do "bio1" and "bio2" communicate in case of non-ideal
>> scenarios (timeouts, errors)?
>
> They don't, you move all the data.  All reads/writes by OpenSSL will
> return SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE when the requisite
> data is not already buffered.  At that point you do the requsite
> I/O and copy data into and out of the network bio.
>
> First, do all pending writes:
>
> BIO_ctrl_pending(network_bio)
> BIO_read(network_bio, ...)
>
> ... write the opaque ciphertext to the underlying socket-like
> ... thing when it is writable, take to not block or drop
> ... the ciphertext on the floor if you do.
>
> then if SSL_ERROR_WANT_READ, find out how much OpenSSL wants to
> read, and read that much data from the underlying socket-like thing
> and copy its (opaque ciphertext) into the network bio:
>
> BIO_ctrl_get_read_request(network_bio)
> BIO_write(network_bio, ...)
>
> A double-buffer (separate read/write) between the socket and SSL
> may make the logic simpler, but the write side must be flushed
> whenever to the SSL network BIO becomes empty, to avoid deadlock.
> And of course avoid blocking on reads when it is OpenSSL's turn to
> write.  In general you have an event loop, a non-blocking socket
> thingy, and select/poll/... read/write or both depending on
> SSL_ERROR_WANT_READ/WRITE and the state of any intermediate buffers
> you're managing.
>
> A careful read of the manpage will expose all these facilities.
>
> --
> Viktor.
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



-- 
Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Root-Level queries while using SSL-connections wrapping "sockets"

[Ajay Garg]

Victor,

I realise I am still stuck with the original issue.

Taking "bio1" as the SSL-facing-bio, and "bio2" as the
network-facing-bio, how do we write-into/read-from "bio2"?
Are there callbacks available that will allow ::

   * Writing to network via "bio2" (after "bio1" has
internally-transferred the bytes to "bio2") ?
   * Reading from network via "bio2" (after which "bio1" can
internally-pick-up the bytes from "bio2") ?

Also, how do "bio1" and "bio2" communicate in case of non-ideal
scenarios (timeouts, errors)?

On Fri, Oct 7, 2016 at 10:09 AM, Ajay Garg <ajaygargn...@gmail.com> wrote:
> On Fri, Oct 7, 2016 at 9:19 AM, Viktor Dukhovni
> <openssl-us...@dukhovni.org> wrote:
>> On Fri, Oct 07, 2016 at 08:51:24AM +0530, Ajay Garg wrote:
>>
>>> However, I am a bit unsure about certain implementations.
>>> In particular (let's talk only about the client-side), I wonder how do
>>> the following methods work internally ::
>>>
>>>
>>>   * SSL_connect (implicitly involving underlying-socket-reads and
>>> underlying-socket-writes)
>>
>> Correct.
>>
>>>   * SSL_write (involving underlying-socket-writes)
>>
>> This can also involve socket reads, e.g. when the peer requests
>> renegotiation.  Hence, on non-blocking sockets this can fail with
>> SSL_ERROR_WANT_READ.  The application should then retry the write
>> (generally with the identitical data) when the socket becomes
>> *readable*.
>>
>>>   * SSL_read (involving underlying-socket-reads)
>>
>> This can also involve socket writes, e.g. when the peer requests
>> renegotiation.  Hence, on non-blocking sockets this can fail with
>> SSL_ERROR_WANT_WRITE.  The application should then retry the read
>> when the socket becomes *writable*.
>>
>>> We have a framework which we have ported to a variety of devices,
>>> involving GPRS-connectivity, and devices without operating-systems.
>>> I know that there is "no one universal socket-write" and "no one
>>> universal socket-read" implementations.
>>
>> No idea what "root-level" means.  Perhaps you mean something
>> analogous to a system-call?  If so OpenSSL can either be handed
>> the socket to use, or plugged into some other way of moving data
>> via the BIO pair interface.
>>
>> https://www.openssl.org/docs/manmaster/crypto/BIO_s_bio.html
>
>
> A let me have a look.. I think this will fit in :)
>
>>
>> --
>> Viktor.
>> --.
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
>
> --
> Regards,
> Ajay



-- 
Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Root-Level queries while using SSL-connections wrapping "sockets"

[Ajay Garg]

On Fri, Oct 7, 2016 at 9:19 AM, Viktor Dukhovni
<openssl-us...@dukhovni.org> wrote:
> On Fri, Oct 07, 2016 at 08:51:24AM +0530, Ajay Garg wrote:
>
>> However, I am a bit unsure about certain implementations.
>> In particular (let's talk only about the client-side), I wonder how do
>> the following methods work internally ::
>>
>>
>>   * SSL_connect (implicitly involving underlying-socket-reads and
>> underlying-socket-writes)
>
> Correct.
>
>>   * SSL_write (involving underlying-socket-writes)
>
> This can also involve socket reads, e.g. when the peer requests
> renegotiation.  Hence, on non-blocking sockets this can fail with
> SSL_ERROR_WANT_READ.  The application should then retry the write
> (generally with the identitical data) when the socket becomes
> *readable*.
>
>>   * SSL_read (involving underlying-socket-reads)
>
> This can also involve socket writes, e.g. when the peer requests
> renegotiation.  Hence, on non-blocking sockets this can fail with
> SSL_ERROR_WANT_WRITE.  The application should then retry the read
> when the socket becomes *writable*.
>
>> We have a framework which we have ported to a variety of devices,
>> involving GPRS-connectivity, and devices without operating-systems.
>> I know that there is "no one universal socket-write" and "no one
>> universal socket-read" implementations.
>
> No idea what "root-level" means.  Perhaps you mean something
> analogous to a system-call?  If so OpenSSL can either be handed
> the socket to use, or plugged into some other way of moving data
> via the BIO pair interface.
>
> https://www.openssl.org/docs/manmaster/crypto/BIO_s_bio.html


A let me have a look.. I think this will fit in :)

>
> --
> Viktor.
> --.
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



-- 
Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Root-Level queries while using SSL-connections wrapping "sockets"

[Ajay Garg]

Hi All.

I understand the basic gist of setting up SSL-connections using
OpenSSL, as per
http://stackoverflow.com/questions/7698488/turn-a-simple-socket-into-an-ssl-socket

However, I am a bit unsure about certain implementations.
In particular (let's talk only about the client-side), I wonder how do
the following methods work internally ::


  * SSL_connect (implicitly involving underlying-socket-reads and
underlying-socket-writes)
  * SSL_write (involving underlying-socket-writes)
  * SSL_read (involving underlying-socket-reads)


We have a framework which we have ported to a variety of devices,
involving GPRS-connectivity, and devices without operating-systems.
I know that there is "no one universal socket-write" and "no one
universal socket-read" implementations.

With the above in mind, I wonder how the "SSL_connect", "SSL_write",
"SSL_read" actually handle the root-level writes/reads (given that we
do not pass any "root-level-socket-write" and "root-level-socket-read"
callbacks before "SSL_write" and "SSL_read").


Looking forward to some help; I will be grateful for any pointers.


Thanks and Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Are double-quotes valid characters in certifcates/keys?

[Ajay Garg]

Thanks everyone for the quick and generous help !!
I am really thankful to everyone's time.


Thanks and Regards,
Ajay

On Tue, Apr 12, 2016 at 7:08 PM, Salz, Rich  wrote:
>
>> Except when you want more people (usually everybody) access to the CRT,
>> but few people (usually one or two trusted server
>> processes) access to the private KEY.
>>
>> Then using two different files will make a lot of sense.
>
> Oh yes, absolutely!  Don't give out the private kkey :)
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



-- 
Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Are double-quotes valid characters in certifcates/keys?

[Ajay Garg]

Hi All.

Thanks for the help.

The certificate is a ".crt.pem".
Key is a ".key".

Anyhow, earlier I was thinking of saving the certificate+key in a
file, where double-quotes were delimiters.
But, I have rejected that idea; instead saving them in their respective files :)

So, the question becomes obsolete.


Anyhow, I am thanks (and sorry at the same time) for everyone's time.



Thanks and Regards,
Ajay

On Mon, Apr 11, 2016 at 8:56 PM, Viktor Dukhovni
<openssl-us...@dukhovni.org> wrote:
> On Mon, Apr 11, 2016 at 10:01:33AM +0530, Ajay Garg wrote:
>
> [ Subject: Are double-quotes valid characters in certifcates/keys? ]
>
>> Could not find a definitive answer on google, so thought it would be
>> best to ask the experts :)
>
> The question is ill-formed.  Are you asking about allowed characters
> in some field of the underlying canonical ASN.1 DER form of a
> certificate, or about some particular encoding of the certificate
> (e.g. PEM)?
>
> If the former, X.509v3 certificates are complicated objects, which
> part of the certificate are you asking about?
>
> As for keys, in their ASN.1 DER encoding they are "binary" data,
> and all octets are a priori valid in a public key.  A public key
> algorithm that prohibits 0x22 seems unlikely.
>
> --
> Viktor.
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



-- 
Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Are double-quotes valid characters in certifcates/keys?

[Ajay Garg]

Hi.

Could not find a definitive answer on google, so thought it would be
best to ask the experts :)


Thanks and Regards,
Ajay
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] SSL Signalling

[Ajay Garg]

Hi All.

We wish to exhange data over sockets in embedded-environments, and
unfortunately can't afford to use the de-facto openssl implementation,
which I believe uses dynamic memory allocations/deallocations in its code
(we intend to deploy our solution using bare-metal C, in environments where
even no RTOS are available).

I googled a lot, but somehow managed to fail in finding the native
SSL-signalling steps.
We are wishing to gain some information on native SSL-signalling, much like
what GET/POST/PUT/DELETE are for HTTP.

Since OpenSSL is the de-facto/expert in this field, may I please put
forward my earnest request for directing us to some literature in this
regard, wherein we can set up a SSL-context using absolute native
SS7-signalling.


Our plan is pretty straighforward ::

1)
Connect to a nginix-erver on its HTTPS port.

2)
Set up SSL-context using native SS7-signalling, on the same socket of step
1

3)
Just before what would have been a normal socket send, we encrypt the
data using the server-public-key obtained from step 2, and then send the
encrypted data (over the socket of step 1).

4)
Just after what would have been a normal socket recv, we decrypt the data
(obtained from the socket of step 1) using the client-private-key obtained
from step 2, and then have it available to the client's software.



Looking forward to some pointers...


Thanks and Regards,
Ajay
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] SSL Signalling

[Ajay Garg]

Hi Viktor.

Thanks for the reply.

Yes, we need our (embedded-)clients to talk to our TLS-server.

We are using Vertx2 as our server.
Its SSL-support APIs are in SSLSupport class at
http://vertx.io/vertx2/api/java/index.html

Going by the APIs, it is not exactly clear what TLS-Algorithm and
Cipher-Suites are used in Vertx2 (I have put an email on the Vertx2
mailing-list with this query, will let know as soon as I have some answers).



So, in the interim, I will be grateful if you guys could let us know the
generic native SSL-signalling steps (if at all there are any steps that are
independent of the TLS-Algorithm and Cipher-Suite).

I know I sound incredibly clueless, kindly bear with me ...


Thanks and Regards,
Ajay

On Sun, Aug 16, 2015 at 11:08 PM, Viktor Dukhovni 
openssl-us...@dukhovni.org wrote:

 On Sun, Aug 16, 2015 at 02:44:54PM +0530, Ajay Garg wrote:

  We wish to exhange data over sockets in embedded-environments, and
  unfortunately can't afford to use the de-facto openssl implementation,
  which I believe uses dynamic memory allocations/deallocations in its code
  (we intend to deploy our solution using bare-metal C, in environments
 where
  even no RTOS are available).

 Why do you want to use TLS?  Is this a closed communication protocol
 only betweent these devices?  Or do you need this to interoperate
 with with other TLS clients or servers?

 For closed environments, there are simpler secure communications
 options than TLS, DJBs crypto box comes to mind:

 http://nacl.cr.yp.to/features.html
 http://nacl.cr.yp.to/box.html

 --
 Viktor.
 ___
 openssl-users mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users




-- 
Regards,
Ajay
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Query in EVP_PKEY_cmp for a particular value of .crt and .key

[Ajay Garg]

Hi all.

I have been trying lately to debug a startup issue in APACHE's httpd
service; and the last logs I receive in /etc/httpd/logs_error_log is

#
[error] SSL Library Error: 185073780 error:0B080074:x509 certificate
routines:X509_check_private_key:key values mismatch
#






As part of some desperate attempts, I downloaded source-rpms of httpd and
openssl, and tracked down the source from where error-emanates.
Following is the code-snippet from crypto/x509/x509_cmp.c

##
int X509_check_private_key(X509 *x, EVP_PKEY *k)
{
EVP_PKEY *xk;
int ret;

xk=X509_get_pubkey(x);

if (xk)
ret = EVP_PKEY_cmp(xk, k);
else
ret = -2;

switch (ret)
{
case 1:
break;
case 0:
X509err(X509_F_X509_CHECK_PRIVATE_KEY,X509_R_KEY_VALUES_MISMATCH);
break;
case -1:
X509err(X509_F_X509_CHECK_PRIVATE_KEY,X509_R_KEY_TYPE_MISMATCH);
break;
case -2:
X509err(X509_F_X509_CHECK_PRIVATE_KEY,X509_R_UNKNOWN_KEY_TYPE);
}
if (xk)
EVP_PKEY_free(xk);
if (ret  0)
return 1;
return 0;
}
##

After the call to  ret = EVP_PKEY_cmp(xk, k);, 0 is being returned as
return value.

So, my query is ::

_What do the parameters X509 *x, EVP_PKEY *k correspond to_ ?


My guess is that x corresponds to a .crt file, while k corresponds to
a key file.
The values at my side are ::



ssl.crt
-


###
-BEGIN CERTIFICATE-
MIICUDCCAbmgAwIBAgIJAOupq9QBcIRCMA0GCSqGSIb3DQEBBQUAMEExFjAUBgNV
BAMMDWFqYXkuZ2FyZy5jb20xJzAlBgkqhkiG9w0BCQEWGGFqYXlAYWN0aXZpdHlj
ZW50cmFsLmNvbTAeFw0xMjAzMjIxNDAwMzVaFw0xMzAzMjIxNDAwMzVaMEExFjAU
BgNVBAMMDWFqYXkuZ2FyZy5jb20xJzAlBgkqhkiG9w0BCQEWGGFqYXlAYWN0aXZp
dHljZW50cmFsLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAntF9ouTD
HNXB4k/phcTbyAp6EP0a3r6CjEGFrD424Yi8eeOgXCwo4s/hh9tadl/8uLxw50y+
0kQz+IGDCZMmfm3HjBgSM6E14Ju3exQE9VD+1W61FD2nwAXBNIXRUd01/E+OEk28
9nVHm7iSEsLOGEBjpbQnim3o0iBLsdAg/y8CAwEAAaNQME4wHQYDVR0OBBYEFOd+
nLQpcOK2zq5+wZwf5uV2/UngMB8GA1UdIwQYMBaAFOd+nLQpcOK2zq5+wZwf5uV2
/UngMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADgYEAUsx+2loW96Aq6fG5
/TBx99Uwnf0p3b52RQ+99CQQj3MQqiuvvvkn1w3joGLK51Xc3sR7/T6bn5BR1vBk
p2g/HmmAHZlTLOJeV9fEofyGf0/Gv7OqpO4NAtBfCd6crdrv3Q37SPppsQ0dkLOs
wQAMLtx4u7QQWze0P7FPCAjE+ZQ=
-END CERTIFICATE-
###





ssl.key
--


-BEGIN PRIVATE KEY-
MIICdQIBADANBgkqhkiG9w0BAQEFAASCAl8wggJbAgEAAoGBAJ7RfaLkwxzVweJP
6YXE28gKehD9Gt6+goxBhaw+NuGIvHnjoFwsKOLP4YfbWnZf/Li8cOdMvtJEM/iB
gwmTJn5tx4wYEjOhNeCbt3sUBPVQ/tVutRQ9p8AFwTSF0VHdNfxPjhJNvPZ1R5u4
khLCzhhAY6W0J4pt6NIgS7HQIP8vAgMBAAECgYApRPrGx3dEGO/G5Ukjb6JE+yP5
IixHUW4PED+yIICWXrfLXLEhAoClX6uVaBS7yfmb76vPDwxPC1YN72mjpU9NBmDt
DxGloXEulrHyCtULykVfpWFxQ/sDgxyve7OhmDJPANELkyUKz4bCfcItML3jY3Si
wyjfA/xyCmmOt1xOQQJBAMv5WDFqmk0r9HCM0RHaxxKvPtH37CJjtkzQMVacneZT
0gePS+pwmTTvh58h4vND+IBIfsVfrqFPRx9fXUKPstECQQDHU6r8pr8iFtmPe/Ka
TiiZ/YsWEC9zcObn3os4iglwy/1RWDYTMmtQImm3LVbCtz+/vrM/TJdUShT1Bgxx
vhH/AkAt8cpFx0deXqo+t9lX9jmlIcg6r2eHD4K+pp6Wbcy7VuIWRdbJxfccj1+z
HoTqWsMc0jeL6dOCDkNs86QkHA4hAkA0QH6mVJ/uM8c8keV7Bdom5Aw98Gg//uzJ
A9HDNIxdAVyaomEqjyEKlLrZxgzkZl1Tyo36nf1dnz33LWq9tnHJAkBO2h8KJbWh
9SzvU0xH9neKRVGRL7XppIVGrNOVKIok4zvm5I9SoC/3u9vbG+LtlBdbRKTn5s0E
IvP7lBIUuBOg
-END PRIVATE KEY-



So, is a return value of 0 expected for these?


Looking forward to a reply.


Thanks and Regards,
Ajay

Re: Query in EVP_PKEY_cmp for a particular value of .crt and .key

[Ajay Garg]

Thanks Marek for the reply.

I hope that it is ok if the key and cert files are with .key and .crt
extensions (instead of pem).


If yes, then fortunately (or unfortunately) the modulus matches.

###
[ajay@ajay certs]$ openssl rsa -in ssl.key -noout -modulus
Modulus=9ED17DA2E4C31CD5C1E24FE985C4DBC80A7A10FD1ADEBE828C4185AC3E36E188BC79E3A05C2C28E2CFE187DB5A765FFCB8BC70E74CBED24433F881830993267E6DC78C181233A135E09BB77B1404F550FED56EB5143DA7C005C13485D151DD35FC4F8E124DBCF675479BB89212C2CE184063A5B4278A6DE8D2204BB1D020FF2F
[ajay@ajay certs]$ openssl x509 -in ssl.crt -noout -modulus
Modulus=9ED17DA2E4C31CD5C1E24FE985C4DBC80A7A10FD1ADEBE828C4185AC3E36E188BC79E3A05C2C28E2CFE187DB5A765FFCB8BC70E74CBED24433F881830993267E6DC78C181233A135E09BB77B1404F550FED56EB5143DA7C005C13485D151DD35FC4F8E124DBCF675479BB89212C2CE184063A5B4278A6DE8D2204BB1D020FF2F
###




So, Marek ::

a)
Could there be any other reason, where a return value of 0 may be
returned?

b)
The permissions for server.key and server.crt are 0755. I hope, these
are valid permissions.

c)
Finally, I would appreciate if you could send me a pair of key and crt
files, generated from your end (or alternatively, send me the command to
generate these files), THAT WOULD GUARANTEE THAT EVP_PKEY_cmp(xk, k)
RETURNS 1 (as the success value).


Thanks again.

Regards,
Ajay

On Fri, Mar 23, 2012 at 8:40 PM, marek.marc...@malkom.pl wrote:

 Hello,

 owner-openssl-us...@openssl.org wrote on 03/23/2012 03:10:47 PM:

  Ajay Garg ajaygargn...@gmail.com
  Sent by: owner-openssl-us...@openssl.org
 
 
  Hi all.
 
  I have been trying lately to debug a startup issue in APACHE's httpd
 service; and the
  last logs I receive in /etc/httpd/logs_error_log is
 
 

 #
  [error] SSL Library Error: 185073780 error:0B080074:x509 certificate
  routines:X509_check_private_key:key values mismatch
 

 #

 Just do:
  $ openssl rsa -in key.pem -noout -modulus
  Modulus=E43E2DAB15DA7E70FC2E2149FC00481816650E799AAEC...
  $ openssl x509 -in crt.pem -noout -modulus
  Modulus=E43E2DAB15DA7E70FC2E2149FC00481816650E799AAEC...
 and check if output maches.

 Best regards,
 --
 Marek Marcola marek.marc...@malkom.pl

 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org