[openssl-dev] Default installation of OpenSSL

[Dmitry Belyavsky]

Hello,

I get problems building and installing OpenSSL 1.1.0g from source.

After running ./config; make; make test; sudo make install

I call  /usr/local/bin/openssl

I get an error

/usr/local/bin/openssl: error while loading shared libraries:
libssl.so.1.1: cannot open shared object file: No such file or directory

$ ldd /usr/local/bin/openssl
libssl.so.1.1 => not found
libcrypto.so.1.1 => not found

This behavior differs from the one for version 1.1.0b, where everything
works fine. Is this changed behavior intended?

Thank you!

-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

[Dmitry Belyavsky]

Hello,

On Tue, Jan 23, 2018 at 3:00 PM, Hubert Kario <hka...@redhat.com> wrote:

> On Friday, 19 January 2018 18:34:57 CET Salz, Rich via openssl-dev wrote:
> > There’s a new blog post at
> > https://www.openssl.org/blog/blog/2018/01/18/f2f-london/
>
> > We decided to increase our use of GitHub. In addition to asking that all
> bug
> > reports and enhancement requests be reported as issues, we now want all
> > major code proposals to be discussed as issues before a large pull
> request
> > shows up. This will let the community discuss the feature, offer input on
> > design and such, before having code to look at. We hope this will let us
> > all first look at the bigger picture, before getting bogged down in the
> > weeds of line-by-line code reviews.
>
> does that mean I have to subscribe to all notifications from the openssl
> github project to notice them? that's really suboptimal
>

Totally agree.


-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

[Dmitry Belyavsky]

Dear William,

Does SPECK implementation need to be a part of the OpenSSL bundle itself?
It can be added as engine, similar to Russian GOST support, with minimal
patches providing OIDs/NIDs if necessary.

On Fri, Jan 5, 2018 at 9:52 PM, William Bathurst <wbath...@gmail.com> wrote:

> Hello All,
>
> We have open sourced our work in regards to integrating the Speck Cipher
> with OpenSSL. Basic information about this cipher can be found here.
>
> https://en.wikipedia.org/wiki/Speck_(cipher) <
> https://en.wikipedia.org/wiki/Speck_%28cipher%29>
>
> SPECK is a lightweight block ciphers each of which comes in a variety of
> widths and key sizes and is targeted towards resource constrained devices
> and environments. This implementation is currently implemented using the
> 128 and 256 block sizes.
>
> We are currently modifying the source from Apache to OpenSSL open source
> licensing for the Speck/OpenSSL integration. Related repositories such as
> the cipher itself will remain under the Apache license. We would love input
> on the following items:
>
> 1) Community interest in such a lightweight cipher.
> 2) Committers willing to help on the code for improvements.
> 3) Information on how to make this available as a patch.
>
> We have currently integrated Speck with OpenSSL 1.1. We also have an Speck
> Client software available for people who wish to test this software. Future
> ports will be to mbedTLS.
>
> We have listed making it available as an issue:
>
> https://github.com/openssl/openssl/issues
>
> OpenSSL/Speck Integration open source repositories:
>
> https://github.com/m2mi/openssl_speck
> https://github.com/m2mi/open_speck
>
> Feel free to contact to to discuss the cipher and uses.
>
> With Regards,
> Bill
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>



-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Certificate Limitation Profile

[Dmitry Belyavsky]

Dear Victor,

On Tue, Nov 28, 2017 at 11:14 PM, Viktor Dukhovni <
openssl-us...@dukhovni.org> wrote:

> On Tue, Nov 28, 2017 at 07:18:48PM +, Blumenthal, Uri - 0553 - MITLL
> wrote:
>
> > I think it makes perfect sense to sign CLP, because it allows you to
> > separate trust in the server you�re downloading the content from and the
> > content itself.
>
> The problem with "data at rest" signatures is that it then becomes
> difficult to ascertain freshness.  How do you know that you're not
> usign a much too stale version of the CLP, that fails to include a
> recently deprecated trust anchor.
>
> Therefore, one needs to be careful to not rely *solely* on the
> signature of the CLP payload.  It is still important to get a fresh
> copy from a trusted source sufficiently often.
>

Thank you. It seems reasonable to add nextUpdate field to
the header of CLP to avoid problems related to using stale CLP.

I expect that fresh CLPs in most cases are delivered via update procedures
of applications, and update mechanism allows fresh enough CLP.

On the other hand enforcing freshness can cause difficulties in situation
when an application becomes unsupported on a specific version of platform
(e.g. stale version of Android/iOS).

-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Certificate Limitation Profile

[Dmitry Belyavsky]

Dear Kurt,

On Tue, Nov 28, 2017 at 3:25 PM, Kurt Roeckx <k...@roeckx.be> wrote:

> On Mon, Nov 27, 2017 at 07:56:00PM +0300, Dmitry Belyavsky wrote:
> > Here is the link to the draft:
> > https://datatracker.ietf.org/doc/draft-belyavskiy-
> certificate-limitation-policy/
>
> I'm wondering how you think that policy will be distributed and
> why it needs signed. I expect that there will always be some way
> of authenticating the document if you download it without requiring
> that the document is signed itself. For instance it might come
> as part of some software distribution (like a browser), and either
> you trust all the files in that distribution or you don't.
>

I agree that an unsigned variant of CLP makes sense.
But it seems to me that if CLP is signed by the certificate that can be
verified using standard chain of trust, it has some advantages.


> If it's signed, who will be signing it, and how does the
> application know which key to use to verify the signature?
>

I think that if the CLP is native for the application, the key/cert
should be hard coded in the app itself.

If we use an external one (e.g. issued by Mozilla or Chrome), we can
specify the certificate in app's config and verify the certificate after
constructing the chain of trust from the roots.


>
> I can also imagine that users might wish to modify that file,
> for instance add an internal CA or certificate, not trust some
> CA, ... They could of course generate their own key, and tell the
> software to use that key.
>

Yes, it's a possible mode of operation. But if we allow unsigned CLPs,
the own key can become unnecessary.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Certificate Limitation Profile

[Dmitry Belyavsky]

Hello,

I'm working on an internet draft describing application-level analog of
CRLs.
I named the proposed file format Certificate Limitation Profile.

I think that current model of trust when only CAs can revoke the
certificates
issued by them does not fit current situation, and we also need app-level
limitations,
as browser vendors (Google, Mozilla) already do.

Currently such limitations are hard coded into the particular software.
Being standardized, it will be possible to reuse such limitations across
various applications and avoid hard-coding.

Here is the link to the draft:
https://datatracker.ietf.org/doc/draft-belyavskiy-certificate-limitation-policy/

The current version of the draft (hopefully) describes necessary ASN.1
structures
that are enough for the most practical cases. I have middle-term plans to
provide a support of the draft in OpenSSL, if the idea seems interesting
enough.

Any feedback is welcome.

Thank you!

-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Problems building openssl on Solaris

[Dmitry Belyavsky]

Hello,

On Fri, Nov 17, 2017 at 2:21 PM, Richard Levitte 
wrote:

> Ah, sorry, I didn't read the output properly.
>
> Regarding the STV_PROTECTED warnings, I don't know at all...  I did a
> bit of a search and saw that this has been discussed before, a little
> more than a year ago.  See
> https://mta.openssl.org/pipermail/openssl-dev/2016-August/008192.html
>
> As for the missing symbols, that tells me something went horribly
> wrong when compiling assembler stuff.  The quick fix is to use the
> 'no-asm' configuration option.  However, if you want to help getting
> assembler to compile, I suggest doing this (no configuration change):
>
> rm crypto/sparccpuid.o
> make build_generated
> make crypto/sparccpuid.o
>

No errors.


> (note: there are other assembler files that seem to fail as well, for
> example those for the bignum library, so this is clearly an assembler
> issue)
>

Sure...


>
> Cheers,
> Richard
>
> In message 

Re: [openssl-dev] Problems building openssl on Solaris

[Dmitry Belyavsky]

Dear Richard,

Adding no-threads just removes gcc complaint about -pthreads.

On Fri, Nov 17, 2017 at 1:23 PM, Richard Levitte <levi...@openssl.org>
wrote:

> I suggest adding 'no-threads' to the OpenSSL configuration options, at
> least as a first step.  That should at least take away gcc's complaint
> about '-pthread'...  I cannot say if that'll fix the rest, I don't
> know Solaris enough.
>
> Cheers,
> Richard
>
> In message <CADqLbzKeQXGaFWGGAz5GyrQP9XGEwjfj2fVTkLN9sRNReJ+kVw@mail.
> gmail.com> on Fri, 17 Nov 2017 11:08:34 +0300, Dmitry Belyavsky <
> beld...@gmail.com> said:
>
> beldmit> Hello,
> beldmit>
> beldmit> We experience problems building OpenSSL on Solaris.
> beldmit>
> beldmit> /usr/local/src/openssl-1.1.0g>uname -a
> beldmit>
> beldmit> SunOS pooh.tcinet.ru 5.10 Generic_147147-26 sun4u sparc
> SUNW,SPARC-Enterprise
> beldmit>
> beldmit> /usr/local/src/openssl-1.1.0g>gcc -v
> beldmit>
> beldmit> Reading specs from /usr/local/lib/gcc/sparc-sun-
> solaris2.10/3.4.6/specs
> beldmit> Configured with: ../configure --with-as=/usr/ccs/bin/as
> --with-ld=/usr/ccs/bin/ld --enable-shared
> beldmit> --enable-languages=c,c++,f77
> beldmit> Thread model: posix
> beldmit> gcc version 3.4.6
> beldmit>
> beldmit> OpenSSL 1.1.0g is configured via
> beldmit> ./Configure solaris64-sparcv9-gcc
> beldmit>
> beldmit> Here is the end of output:
> beldmit>
> beldmit> ...
> beldmit>
> beldmit> 
> LD_LIBRARY_PATH=.:/usr/local/ssl/lib:/usr/sfw/lib/sparcv9:/usr/local/lib
> gcc -DDSO_DLFCN
> beldmit> -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS
> -DOPENSSL_NO_STATIC_ENGINE
> beldmit> -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m
> -DSHA1_ASM
> beldmit> -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM
> -DECP_NISTZ256_ASM
> beldmit> -DPOLY1305_ASM -DOPENSSLDIR="/usr/local/ssl"
> -DENGINESDIR="/usr/local/lib/engines-1.1" -m64
> beldmit> -mcpu=ultrasparc -Wall -DB_ENDIAN -DBN_DIV2W -O3 -pthread
> -DFILIO_H -o apps/openssl
> beldmit> apps/app_rand.o apps/apps.o apps/asn1pars.o apps/ca.o
> apps/ciphers.o apps/cms.o apps/crl.o
> beldmit> apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o
> apps/dsaparam.o apps/ec.o apps/ecparam.o
> beldmit> apps/enc.o apps/engine.o apps/errstr.o apps/gendsa.o
> apps/genpkey.o apps/genrsa.o apps/nseq.o
> beldmit> apps/ocsp.o apps/openssl.o apps/opt.o apps/passwd.o apps/pkcs12.o
> apps/pkcs7.o apps/pkcs8.o
> beldmit> apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o apps/prime.o
> apps/rand.o apps/rehash.o apps/req.o
> beldmit> apps/rsa.o apps/rsautl.o apps/s_cb.o apps/s_client.o
> apps/s_server.o apps/s_socket.o apps/s_time.o
> beldmit> apps/sess_id.o apps/smime.o apps/speed.o apps/spkac.o apps/srp.o
> apps/ts.o apps/verify.o
> beldmit> apps/version.o apps/x509.o -L. -lssl -L. -lcrypto -lsocket -lnsl
> -ldl
> beldmit> gcc: unrecognized option `-pthread'
> beldmit> ld: warning: relocation warning: R_SPARC_COPY: file
> ./libcrypto.so: symbol PBEPARAM_it: relocation
> beldmit> bound to a symbol with STV_PROTECTED visibility
> beldmit> ld: warning: relocation warning: R_SPARC_COPY: file
> ./libcrypto.so: symbol PBE2PARAM_it:
> beldmit> relocation bound to a symbol with STV_PROTECTED visibility
> beldmit> ld: warning: relocation warning: R_SPARC_COPY: file
> ./libcrypto.so: symbol PBKDF2PARAM_it:
> beldmit> relocation bound to a symbol with STV_PROTECTED visibility
> beldmit> Undefined first referenced
> beldmit> symbol in file
> beldmit> _sparcv9_rdtick ./libcrypto.so
> beldmit> bn_add_words ./libcrypto.so
> beldmit> _sparcv9_vis1_instrument ./libcrypto.so
> beldmit> bn_sub_words ./libcrypto.so
> beldmit> bn_sqr_words ./libcrypto.so
> beldmit> OPENSSL_cleanse apps/apps.o
> beldmit> _sparcv9_rdcfr ./libcrypto.so
> beldmit> _sparcv9_vis1_instrument_bus2 ./libcrypto.so
> beldmit> _sparcv9_vis3_probe ./libcrypto.so
> beldmit> bn_mul_words ./libcrypto.so
> beldmit> _sparcv9_vis2_probe ./libcrypto.so
> beldmit> _sparcv9_vis1_probe ./libcrypto.so
> beldmit> ChaCha20_ctr32 ./libcrypto.so
> beldmit> _sparcv9_vis1_instrument_bus ./libcrypto.so
> beldmit> bn_mul_comba4 ./libcrypto.so
> beldmit> bn_mul_comba8 ./libcrypto.so
> beldmit> bn_sqr_comba4 ./libcrypto.so
> beldmit> bn_sqr_comba8 ./libcrypto.so
> beldmit> _sparcv9_fmadd_probe ./libcrypto.so
> beldmit> CRYPTO_memcmp ./libssl.so
> beldmit> bn_mul_add_words ./libcrypto.so
> beldmit> bn_div_words ./libcrypto.so
> beldmit> _sparcv9_fjaesx_probe ./libcrypto.so
> beldmit> ld: fatal: symbol referencing errors. No output written to
> apps/openssl
> beldmit> collect2: ld returned 1 exit status
> beldmit> *** Error code 1
> beldmit>
> beldmit> What can we do to fix it?
> beldmit>
> beldmit> Thank you!
> beldmit>
> beldmit> --
> beldmit> SY, Dmitry Belyavsky
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>



-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Problems building openssl on Solaris

[Dmitry Belyavsky]

Hello,

We experience problems building OpenSSL on Solaris.


/usr/local/src/openssl-1.1.0g>uname -a

SunOS pooh.tcinet.ru 5.10 Generic_147147-26 sun4u sparc
SUNW,SPARC-Enterprise


/usr/local/src/openssl-1.1.0g>gcc -v

Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.10/3.4.6/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld --enable-shared --enable-languages=c,c++,f77
Thread model: posix
gcc version 3.4.6

OpenSSL 1.1.0g is configured via
./Configure solaris64-sparcv9-gcc

Here is the end of output:

...

LD_LIBRARY_PATH=.:/usr/local/ssl/lib:/usr/sfw/lib/sparcv9:/usr/local/lib
gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS
-DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
-DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM
-DOPENSSLDIR="/usr/local/ssl" -DENGINESDIR="/usr/local/lib/engines-1.1"
-m64 -mcpu=ultrasparc -Wall -DB_ENDIAN -DBN_DIV2W -O3 -pthread -DFILIO_H -o
apps/openssl apps/app_rand.o apps/apps.o apps/asn1pars.o apps/ca.o
apps/ciphers.o apps/cms.o apps/crl.o apps/crl2p7.o apps/dgst.o
apps/dhparam.o apps/dsa.o apps/dsaparam.o apps/ec.o apps/ecparam.o
apps/enc.o apps/engine.o apps/errstr.o apps/gendsa.o apps/genpkey.o
apps/genrsa.o apps/nseq.o apps/ocsp.o apps/openssl.o apps/opt.o
apps/passwd.o apps/pkcs12.o apps/pkcs7.o apps/pkcs8.o apps/pkey.o
apps/pkeyparam.o apps/pkeyutl.o apps/prime.o apps/rand.o apps/rehash.o
apps/req.o apps/rsa.o apps/rsautl.o apps/s_cb.o apps/s_client.o
apps/s_server.o apps/s_socket.o apps/s_time.o apps/sess_id.o apps/smime.o
apps/speed.o apps/spkac.o apps/srp.o apps/ts.o apps/verify.o apps/version.o
apps/x509.o -L. -lssl -L. -lcrypto -lsocket -lnsl -ldl
gcc: unrecognized option `-pthread'
ld: warning: relocation warning: R_SPARC_COPY: file ./libcrypto.so: symbol
PBEPARAM_it: relocation bound to a symbol with STV_PROTECTED visibility
ld: warning: relocation warning: R_SPARC_COPY: file ./libcrypto.so: symbol
PBE2PARAM_it: relocation bound to a symbol with STV_PROTECTED visibility
ld: warning: relocation warning: R_SPARC_COPY: file ./libcrypto.so: symbol
PBKDF2PARAM_it: relocation bound to a symbol with STV_PROTECTED visibility
Undefined   first referenced
 symbol in file
_sparcv9_rdtick ./libcrypto.so
bn_add_words./libcrypto.so
_sparcv9_vis1_instrument./libcrypto.so
bn_sub_words./libcrypto.so
bn_sqr_words./libcrypto.so
OPENSSL_cleanse apps/apps.o
_sparcv9_rdcfr  ./libcrypto.so
_sparcv9_vis1_instrument_bus2   ./libcrypto.so
_sparcv9_vis3_probe ./libcrypto.so
bn_mul_words./libcrypto.so
_sparcv9_vis2_probe ./libcrypto.so
_sparcv9_vis1_probe ./libcrypto.so
ChaCha20_ctr32  ./libcrypto.so
_sparcv9_vis1_instrument_bus./libcrypto.so
bn_mul_comba4   ./libcrypto.so
bn_mul_comba8   ./libcrypto.so
bn_sqr_comba4   ./libcrypto.so
bn_sqr_comba8   ./libcrypto.so
_sparcv9_fmadd_probe./libcrypto.so
CRYPTO_memcmp   ./libssl.so
bn_mul_add_words./libcrypto.so
bn_div_words./libcrypto.so
_sparcv9_fjaesx_probe   ./libcrypto.so
ld: fatal: symbol referencing errors. No output written to apps/openssl
collect2: ld returned 1 exit status
*** Error code 1

What can we do to fix it?

Thank you!

-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] New crypto algorithms in openSSL engine

[Dmitry Belyavsky]

On Mon, Oct 23, 2017 at 4:54 PM, Salz, Rich via openssl-dev <
openssl-dev@openssl.org> wrote:

> ➢ Really, about a ten years ago, when we first developed GOST engine, we
> have made patches, that allow to add ciphersuites dynamically.
> Unfortunately, that time core team haven't accepted these patches.
>
> Do you still have them available?  We might make a different choice now …
>

Well, as now there are separate structures for key exchange and auth, these
patches seem to have almost no sense.

-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] X509_cmp_time (possible) bug

[Dmitry Belyavsky]

Hello,

The X509_cmp_time function is documented as returning -1 or 1 on success
and 0 on error.

In fact it returns result of strcmp:
int X509_cmp_time(const ASN1_TIME *ctm, time_t *cmp_time) {
...
i = strcmp(buff1, buff2);
if (i == 0) /* wait a second then return younger */
return -1;
else
return i;
}

According to documentation to the strcmp,

The strcmp() and strncmp() functions return an integer less than, equal to,
or greater than  zero  if  s1 (or the first n bytes thereof) is found,
respectively, to be less than, to match, or be greater than s2.

It means (and have been met in practice) that X509_cmp_time() returns other
values than 1/-1.
So it seems reasonable to either update documentation or fix the behavior.

Thank you!

-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Compiler requirements

[Dmitry Belyavsky]

Hello,

What is the minimal version of the compiler to build openssl?
Is it still required C89 compatibility or C99 standard can be used?

Unfortunately, I did not find these requirements in documentation.

Thank you!

-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Dmitry Belyavsky]

Dear Rich,

On Mon, Jun 26, 2017 at 3:49 PM, Salz, Rich via openssl-dev <
openssl-dev@openssl.org> wrote:

> We are starting to work on a new cryptographically strong pseudo random
> number generator for OpenSSL, known as CSPRNG or PRNG or RNG.
>
>
>
> Please take a look at GitHub pull request https://github.com/openssl/
> openssl/pull/3758 which is the start of a series.  In particular, please
> take a look at some detailed comments from one of our committers, at
> https://github.com/openssl/openssl/pull/3758#issuecomment-310938562, and
> the followon.
>
>
>
> We welcome your input.
>

Will the new architecture still allow engine-defined RNG methods? It's a
critical requirement for our products.
Thank you!


-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Private key size in req output

[Dmitry Belyavsky]

Hello,

Currently the req command prints key size before generating the private
key. If the key size can't be determined from the specified parameters, it
prints the default value.

For some algorithms (e.g GOST ones) the key bits value is fixed and can't
be extracted from the parameters. In such situations we have either
hardcode number of bits for GOST algorithms or (and it seems better to me)
 print the information after the key generation when we have the EVP_PKEY
object and can print the exact value.

What do you think about it?

Thank you!

-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Internationalized Email Addresses in X.509 certificates

[Dmitry Belyavsky]

Here is a patch designed for the support of the https://tools.ietf.org/html/
draft-ietf-lamps-eai-addresses-06 draft which is in the last call phase of
the Lamps WG.


The patch https://github.com/openssl/openssl/pull/2560 implements the
support of the SmtpUtf8 OTHERNAME value.


Current problems related to the patch:


   1. It requires libidn with its own memory management.
   2. The support via config is not provided yet.
   3. It does not implement the canonicalization of the unicode string
   4. It does not have tests for the chain verification.


We have a preliminary specification of the tests, but currently I am unable
to implement them
=
I can give you an outline of a spec.  Hopefully that's enough to work with:
1. Local-part
  a. Internationalized i.e. non-ascii email Local-part is encoded as UTF8
in smtputf8Name.  Given a test certificate in ASN.1, the UTF8 Local-part
should be extractable and tested.
  b. Though not recommended, ascii email Local-part may also be
represented.  So a test certificate in ASN.1 could encode an ascii email
local-part, and the ascii should be extractable and tested.  Certificate
generation through openssl should opt to use rfc822Name for ascii
Local-part though.
2. Domain
  a. U-label in smtputf8Name shall be supported.  Given a test certificate
in ASN.1, a U-label domain should be extracted and tested.
  b. A-label in smtputf8Name must not be supported.  Given a test
certificate in ASN.1, the A-label domain should be rejected.
3. Name constraints
  a. CA certificate with smtputf8Name name constraint should constrain an
entity certificate with smtputf8Name.  Given an intermediate CA cert in
ASN.1 with a full email address excluded name constraint in smtputf8Name,
it can constraint an entity certificate with smtputf8Name.
  b. CA certificate with rfc822Name name constraint should not constrain an
entity certicate with smtputf8Name.  Given an intermediate CA cert in ASN.1
with a full email address excluded name constraint in rfc822Name, it does
*not* constraint an entity certificate with smtputf8Name.
  c. CA certificate with smtputf8Name name constraint should not constrain
an entity certificiate with rfc822Name.  Given an intermediate CA cert in
ASN.1 with a full email address excluded name constraint in smtputf8Name,
it does *not* constraint an entity certificate with rfc822Name.
=

So could I cooperate with the OpenSSL team to finalize this work and submit
the patch to upstream?

-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Add a new algorithm in "crypto" dir, how to add the source code into the build system

[Dmitry Belyavsky]

Dear Wei,

You will need hardcoded NIDs for many protocols implemented in OpenSSL
(TLS, PKCS12).

For most other purposes the dynamic allocation of objects using OBJ_
functions works fine,
but some years ago I had problems with some applications when I used engine
that allocated objects dynamically.
I hope that it was my fault.


On Fri, Dec 23, 2016 at 5:28 AM, Wei, Changzheng <changzheng@intel.com>
wrote:

> It works. Thanks a lot!
>
>
>
> *From:* openssl-dev [mailto:openssl-dev-boun...@openssl.org] *On Behalf
> Of *Peter Waltenberg
> *Sent:* Friday, December 23, 2016 8:56 AM
>
> *To:* openssl-dev@openssl.org
> *Subject:* Re: [openssl-dev] Add a new algorithm in "crypto" dir, how to
> add the source code into the build system
>
>
>
> It's changed in recent OpenSSL.
>
> 1.1.0c the directories are in Configure.
>
> # Top level directories to build
> $config{dirs} = [ "crypto", "ssl", "engines", "apps", "test", "util",
> "tools", "
> fuzz" ];
> # crypto/ subdirectories to build
> $config{sdirs} = [
> "objects",
> "md2", "md4", "md5", "sha", "mdc2", "hmac", "ripemd", "whrlpool",
> "poly1305"
> , "blake2",
> "des", "aes", "rc2", "rc4", "rc5", "idea", "bf", "cast", "camellia",
> "seed",
>  "chacha", "modes",
> "bn", "ec", "rsa", "dsa", "dh", "dso", "engine",
> "buffer", "bio", "stack", "lhash", "rand", "err",
> "evp", "asn1", "pem", "x509", "x509v3", "conf", "txt_db", "pkcs7",
> "pkcs12",
>  "comp", "ocsp", "ui",
> "cms", "ts", "srp", "cmac", "ct", "async", "kdf", "sha3"  <  Added
> sha3 to the list
> ];
>
> Persist, it can be done but there was quite a bit of trial and error
> before I got it working.
>
> Peter
>
>
>
> From:"Wei, Changzheng" <changzheng@intel.com>
> To:"openssl-dev@openssl.org" <openssl-dev@openssl.org>
> Date:23/12/2016 10:41
> Subject:Re: [openssl-dev] Add a new algorithm in "crypto" dir,
> how to add the source code into the build system
> Sent by:"openssl-dev" <openssl-dev-boun...@openssl.org>
> --
>
>
>
>
> Hi
> Thanks for your reply.
> My question is that, I add a new subdir(named *abc*) in openssl/crypto/
> *abc*, and implement codes , Makefile and build.info in the crypt/abc
> directory, but when I re-build OpenSSL, I found that this new added sub dir
> is not involved into the build system, any source file in this subdir is
> not compiled. So I want to know how to compile these new added files in
> OpenSSL build system.
>
> Thanks
>
> *From:* openssl-dev [mailto:openssl-dev-boun...@openssl.org
> <openssl-dev-boun...@openssl.org>] *On Behalf Of *Short, Todd
> * Sent:* Friday, December 23, 2016 5:14 AM
> * To:* openssl-dev@openssl.org
> * Subject:* Re: [openssl-dev] Add a new algorithm in "crypto" dir, how to
> add the source code into the build system
>
> Easiest way is to fork the OpenSSL Github repo and then clone it down to
> your local machine where you can do the work locally. Once you are happy,
> push it back up to your forked Github repo, and then make a pull request
> back to the OpenSSL repo.
>
> There are lots of places you can get information on git and Github; but
> this list isn’t one of them.
> --
> -Todd Short
> // tsh...@akamai.com
> // "One if by land, two if by sea, three if by the Internet."
>
> On Dec 22, 2016, at 8:12 AM, Wei, Changzheng <changzheng@intel.com>
> wrote:
>
> Hi,
> I want to implement some new algorithm. To make my future work smoothly, I
> want to add a new algorithm method like “RSA_METHOD” in OpenSSL framework
> so as to I can use an “engine” to support such algorithm.
> So I add a new subdir in “crypto” and implement the code and build.inforefer
> to “crypto/rsa”.
> My question is how to add my new source code into the build system?
>
> Thanks in advance!
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>  --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>


-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Typo in BUF_reverse manual

[Dmitry Belyavsky]

Sorry, my fault :(

On Tue, Dec 13, 2016 at 12:11 PM, Matt Caswell <m...@openssl.org> wrote:

>
>
> On 12/12/16 18:11, Dmitry Belyavsky wrote:
> > Dear Matt,
> > Shouldn't the fix also be applied to 1.1.0 branch?
>
> Err, it was?
>
> Matt
>
> >
> > On Mon, Dec 12, 2016 at 3:44 PM, Dmitry Belyavsky <beld...@gmail.com
> > <mailto:beld...@gmail.com>> wrote:
> >
> > Hello Matt,
> >
> > https://github.com/openssl/openssl/pull/2075
> > <https://github.com/openssl/openssl/pull/2075>
> >
> > On Mon, Dec 12, 2016 at 3:17 PM, Matt Caswell <m...@openssl.org
> > <mailto:m...@openssl.org>> wrote:
> >
> > Could you open that as an issue in GitHub? Or even better a PR
> > to fix it ;-)
> >
> > Thanks
> >
> > Matt
> >
> >
> > On 12/12/16 12:16, Dmitry Belyavsky wrote:
> > > Hello!
> > >
> > > I found a typo in the BUF_reverse manual
> > >
> > (https://www.openssl.org/docs/man1.1.0/crypto/BUF_MEM_new_
> ex.html <https://www.openssl.org/docs/man1.1.0/crypto/BUF_MEM_new_ex.html
> >)
> > >
> > > The manual says:
> > >
> > > BUF_reverse() reverses size bytes at in into out. If out is
> > NULL, the
> > > array is reversed in-place.
> > >
> > > But in fact in-place reverse is done when the in ptr is NULL.
> > >
> > > Thank you!
> >     >
> > > --
> >     > SY, Dmitry Belyavsky
> > >
> > >
> > --
> > openssl-dev mailing list
> > To unsubscribe:
> > https://mta.openssl.org/mailman/listinfo/openssl-dev
> > <https://mta.openssl.org/mailman/listinfo/openssl-dev>
> >
> >
> >
> >
> > --
> > SY, Dmitry Belyavsky
> >
> >
> >
> >
> > --
> > SY, Dmitry Belyavsky
> >
> >
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>



-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Typo in BUF_reverse manual

[Dmitry Belyavsky]

Dear Matt,
Shouldn't the fix also be applied to 1.1.0 branch?

On Mon, Dec 12, 2016 at 3:44 PM, Dmitry Belyavsky <beld...@gmail.com> wrote:

> Hello Matt,
>
> https://github.com/openssl/openssl/pull/2075
>
> On Mon, Dec 12, 2016 at 3:17 PM, Matt Caswell <m...@openssl.org> wrote:
>
>> Could you open that as an issue in GitHub? Or even better a PR to fix it
>> ;-)
>>
>> Thanks
>>
>> Matt
>>
>>
>> On 12/12/16 12:16, Dmitry Belyavsky wrote:
>> > Hello!
>> >
>> > I found a typo in the BUF_reverse manual
>> > (https://www.openssl.org/docs/man1.1.0/crypto/BUF_MEM_new_ex.html)
>> >
>> > The manual says:
>> >
>> > BUF_reverse() reverses size bytes at in into out. If out is NULL, the
>> > array is reversed in-place.
>> >
>> > But in fact in-place reverse is done when the in ptr is NULL.
>> >
>> > Thank you!
>> >
>> > --
>> > SY, Dmitry Belyavsky
>> >
>> >
>> --
>> openssl-dev mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>>
>
>
>
> --
> SY, Dmitry Belyavsky
>



-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Typo in BUF_reverse manual

[Dmitry Belyavsky]

Hello Matt,

https://github.com/openssl/openssl/pull/2075

On Mon, Dec 12, 2016 at 3:17 PM, Matt Caswell <m...@openssl.org> wrote:

> Could you open that as an issue in GitHub? Or even better a PR to fix it
> ;-)
>
> Thanks
>
> Matt
>
>
> On 12/12/16 12:16, Dmitry Belyavsky wrote:
> > Hello!
> >
> > I found a typo in the BUF_reverse manual
> > (https://www.openssl.org/docs/man1.1.0/crypto/BUF_MEM_new_ex.html)
> >
> > The manual says:
> >
> > BUF_reverse() reverses size bytes at in into out. If out is NULL, the
> > array is reversed in-place.
> >
> > But in fact in-place reverse is done when the in ptr is NULL.
> >
> > Thank you!
> >
> > --
> > SY, Dmitry Belyavsky
> >
> >
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>



-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Typo in BUF_reverse manual

[Dmitry Belyavsky]

Hello!

I found a typo in the BUF_reverse manual
(https://www.openssl.org/docs/man1.1.0/crypto/BUF_MEM_new_ex.html)

The manual says:

BUF_reverse() reverses size bytes at in into out. If out is NULL, the array
is reversed in-place.

But in fact in-place reverse is done when the in ptr is NULL.

Thank you!

-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] About Chinese crypto-algorithms

[Dmitry Belyavsky]

Hello Robin,

On Wed, Sep 28, 2016 at 3:44 PM, Salz, Rich <rs...@akamai.com> wrote:

> (I subscribed you to openssl-dev; I hope it works.)
>
> ISO standards are “pay to play.”  That is, any member organization can get
> something as an ISO standard with not much effort. :)
>
> >> "I strongly recommend that if anyone works on this, they do it as an
> externally-provided ENGINE, like GOST. "
> >Again, I'm sorry I have not a clear notion about the difference
> between build-in approach, and certainly we will take this if necessary.
>
> >> "We may also not have the resources to tackle something that would
> otherwise be of interest (we have a back catalog of nice-to-have
> cryptography waiting for a rainy day)"
> >We certainly respect policy within community and be willing to
> participate in this if possible in all aspects.
>
> You will have to learn how to write an ENGINE.  It is possible; Dmitry did
> it for GOST (look in the mailing list archives, https://mta.openssl.org,
> for some details; also maybe the Git log.  Also maybe he'll reply to this
> post :)  Richard Levitte has started a blog series on writing an ENGINE,
> see https://www.openssl.org/blog/blog/categories/engine-corner/


Sure. I'll be glad to assist.


>
> We want to make it easier to add new crypto via ENGINES.  Each time
> someone does it, we learn more about what's needed, the documentation gets
> (a little) better, and so on.
>
>
The best solution will be providing a skeleton engine (with a skeleton
Makefile example).


-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Linking with extra library

[Dmitry Belyavsky]

Dear Richard,



On Thu, Sep 1, 2016 at 5:39 PM, Richard Levitte <levi...@openssl.org> wrote:

> In message <CADqLbzJMH0U_851P+_oHbByyh-gBnNMmYvd7pqz45WHTz0njyw@mail.
> gmail.com> on Thu, 1 Sep 2016 16:06:54 +0300, Dmitry Belyavsky <
> beld...@gmail.com> said:
>
> beldmit> Hello Openssl Team,
> beldmit>
> beldmit> I'm currently working on a patch providing support of the
> beldmit> https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-00
> draft.
> beldmit>
> beldmit> I want to use functions from the libidn library to process the
> beldmit> specified conversion.
> beldmit> How do I add the linkage against libidn to the build system?
>
> ./config -lidn
>
> (you might want to toss in a -L argument there as well if your libidn
> isn't in a standard location)
>
> Thank you!


-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Linking with extra library

[Dmitry Belyavsky]

Hello Openssl Team,

I'm currently working on a patch providing support of the
https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-00 draft.

I want to use functions from the libidn library to process the specified
conversion.
How do I add the linkage against libidn to the build system?

Thank you!

-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] object.txt

[Dmitry Belyavsky]

Hello Richard,

Thank you for clarification!

On Tue, Aug 23, 2016 at 2:53 PM, Richard Levitte <levi...@openssl.org>
wrote:

> In message <CADqLbz+4v0zwnJTzenFtk8yYNqC4YuKinjfDY
> z2_faqhkbj...@mail.gmail.com> on Tue, 23 Aug 2016 14:00:23 +0300, Dmitry
> Belyavsky <beld...@gmail.com> said:
>
> beldmit> Hello,
> beldmit>
> beldmit> I try to add a new OID to the objects.h file in my fork of the
> OpenSSL
> beldmit> 1.1.0-pre7-dev.
> beldmit>
> beldmit> After adding the line to the objects.txt file and running
> ./config;
> beldmit> make the corresponding NIDs do not appear in the files
> beldmit> include/openssl/objects.h and include/openssl/obj_mac.h
> beldmit>
> beldmit> What's the right way to add new OIDs with new build system?
>
> There's a manual step to update the corresponding C files:  make update
>
> Cheers,
> Richard
>
> --
> Richard Levitte levi...@openssl.org
> OpenSSL Project http://www.openssl.org/~levitte/
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>



-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] object.txt

[Dmitry Belyavsky]

Hello,

I try to add a new OID to the objects.h file in my fork of the OpenSSL
1.1.0-pre7-dev.

After adding the line to the objects.txt file and running ./config; make
the corresponding NIDs do not appear in the files include/openssl/objects.h
and include/openssl/obj_mac.h

What's the right way to add new OIDs with new build system?

Thank you!

-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4655] Openssl req seems not to work with precreated key

[Dmitry Belyavsky via RT]

Dear Richard,

Thank you, it works.

On Mon, Aug 22, 2016 at 4:00 PM, Richard Levitte via RT <r...@openssl.org>
wrote:

> The issue isn't with the pre-created key, but because '-x509' doesn't fully
> flag that something new is to be created. The freeze is because 'openssl
> req'
> tries to read a csr... '-newkey', however, does flag the creation of a csr
> /
> x509, that's why the alternative command works.
>
> Fix in https://github.com/openssl/openssl/pull/1479
>
> Cheers,
> Richard
>
> On Mon Aug 22 12:33:47 2016, beld...@gmail.com wrote:
> > Hello openssl team,
> >
> > I experience problems with openssl version OpenSSL 1.1.0-pre7-dev
> >
> > I use Debian GNU Linux, the version is 8.5
> > The kernel version is
> > Linux vr-dev 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08)
> > x86_64 GNU/Linux
> >
> > I have created a private key with a command
> >
> > LD_LIBRARY_PATH=. apps/openssl genrsa -out rsa2048.pem 2048
> >
> > in the build directory.
> >
> > When I execute the command
> > OPENSSL_CONF=apps/openssl.cnf LD_LIBRARY_PATH=. apps/openssl req -x509
> -key
> > rsa2048.pem -keyform PEM -out cert.pem
> >
> > in the build directory, it seems to hang and does not print any prompt.
> >
> > The command line
> > OPENSSL_CONF=apps/openssl.cnf LD_LIBRARY_PATH=. apps/openssl req -x509
> > -newkey rsa:2048 -keyout key.pem -out req.pem -nodes
> >
> > works ok.
> >
> > What's done wrong by me?
> >
>
>
> --
> Richard Levitte
> levi...@openssl.org
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4655
> Please log in as guest with password guest if prompted
>
>


-- 
SY, Dmitry Belyavsky

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4655
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4655] Openssl req seems not to work with precreated key

[Dmitry Belyavsky]

Dear Richard,

Thank you, it works.

On Mon, Aug 22, 2016 at 4:00 PM, Richard Levitte via RT <r...@openssl.org>
wrote:

> The issue isn't with the pre-created key, but because '-x509' doesn't fully
> flag that something new is to be created. The freeze is because 'openssl
> req'
> tries to read a csr... '-newkey', however, does flag the creation of a csr
> /
> x509, that's why the alternative command works.
>
> Fix in https://github.com/openssl/openssl/pull/1479
>
> Cheers,
> Richard
>
> On Mon Aug 22 12:33:47 2016, beld...@gmail.com wrote:
> > Hello openssl team,
> >
> > I experience problems with openssl version OpenSSL 1.1.0-pre7-dev
> >
> > I use Debian GNU Linux, the version is 8.5
> > The kernel version is
> > Linux vr-dev 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08)
> > x86_64 GNU/Linux
> >
> > I have created a private key with a command
> >
> > LD_LIBRARY_PATH=. apps/openssl genrsa -out rsa2048.pem 2048
> >
> > in the build directory.
> >
> > When I execute the command
> > OPENSSL_CONF=apps/openssl.cnf LD_LIBRARY_PATH=. apps/openssl req -x509
> -key
> > rsa2048.pem -keyform PEM -out cert.pem
> >
> > in the build directory, it seems to hang and does not print any prompt.
> >
> > The command line
> > OPENSSL_CONF=apps/openssl.cnf LD_LIBRARY_PATH=. apps/openssl req -x509
> > -newkey rsa:2048 -keyout key.pem -out req.pem -nodes
> >
> > works ok.
> >
> > What's done wrong by me?
> >
>
>
> --
> Richard Levitte
> levi...@openssl.org
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4655
> Please log in as guest with password guest if prompted
>
>


-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4655] Openssl req seems not to work with precreated key

[Dmitry Belyavsky via RT]

Hello openssl team,

I experience problems with openssl version OpenSSL 1.1.0-pre7-dev

I use Debian GNU Linux, the version is 8.5
The kernel version is
Linux vr-dev 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08)
x86_64 GNU/Linux

I have created a private key with a command

LD_LIBRARY_PATH=. apps/openssl genrsa -out rsa2048.pem 2048

in the build directory.

When I execute the command
OPENSSL_CONF=apps/openssl.cnf LD_LIBRARY_PATH=. apps/openssl req -x509 -key
rsa2048.pem -keyform PEM -out cert.pem

in the build directory, it seems to hang and does not print any prompt.

The command line
OPENSSL_CONF=apps/openssl.cnf LD_LIBRARY_PATH=. apps/openssl  req -x509
-newkey rsa:2048 -keyout key.pem -out req.pem -nodes

works ok.

What's done wrong by me?

-- 
SY, Dmitry Belyavsky

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4655
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3940] Missing CRL checks in cms/smime cmdline utilities

[Dmitry Belyavsky via RT]

Thank you very much!

19 авг. 2016 г. 6:47 PM пользователь "Rich Salz via RT" 
написал:

> For now we just added a comment to master, 1.0.2, 1.0.1 in the cms.pod and
> smime.pod files:
>
> Note that no revocation check is done for the recipient cert, so if that
> key has been compromised, others may be able to decrypt the text.
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3940
> Please log in as guest with password guest if prompted
>
>

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3940
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3940] Missing CRL checks in cms/smime cmdline utilities

[Dmitry Belyavsky]

Thank you very much!

19 авг. 2016 г. 6:47 PM пользователь "Rich Salz via RT" 
написал:

> For now we just added a comment to master, 1.0.2, 1.0.1 in the cms.pod and
> smime.pod files:
>
> Note that no revocation check is done for the recipient cert, so if that
> key has been compromised, others may be able to decrypt the text.
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3940
> Please log in as guest with password guest if prompted
>
>
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c

[Dmitry Belyavsky]

Hello,

I can confirm that I have seen a similar behavior in multi-thread
environment. Unfortunately, I do not have a script to reproduce it either.

On Fri, May 20, 2016 at 6:49 PM, Mick Saxton via RT <r...@openssl.org> wrote:

> Hi
>
> Before going any further I would like to state that I have only seen this
> problem when we have 1 or more concurrent connections.
>
> Mostly we notice it on Windows but I have seen it on linux (Ubuntu).
>
> I first noticed it when using v1.0.2d but have seen it again since
> upgrading to v1.0.2h.
>
> It can happen in one of two places and results in a call to MD_Update with
> a negative value.
>
> I have come up with a temporary fix which avoids the possibility of
> crashing at the expense of some randomness.
> The system is very highly stressed at this point so debugging further is
> difficult.
>
> The fix I am using is probably not what you eventually will want to
> implement but it does improve stability.
>
> 273:MD_Update(, &(state[st_idx]), (j - k) );
> Change to
> 273:MD_Update(, &(state[st_idx]), (j - k) > 0 ? j - k : 1);
> // mi...@1e.com (j -k) must not be negative
>
> And
>
> 495:MD_Update(, &(state[st_idx]), MD_DIGEST_LENGTH / 2 - k )
> Change to
> 495:MD_Update(, &(state[st_idx]), MD_DIGEST_LENGTH / 2 - k >
> 0 ? MD_DIGEST_LENGTH / 2 - k : 1);  // mi...@1e.com (j -k) must not be
> negative
>
>
> I do have a test program which can reproduce this behaviour.
>
> If I can be of further help - please contact me by email.
>
> Regards
> Mick Saxton
>
> 
>
>
> Legal Notice: This email is intended only for the person(s) to whom it is
> addressed. If you are not an intended recipient and have received this
> message in error, please notify the sender immediately by replying to this
> email or calling +44(0) 2083269015 (UK) or +1 866 592 4214 (USA). This
> email and any attachments may be privileged and/or confidential. The
> unauthorized use, disclosure, copying or printing of any information it
> contains is strictly prohibited. The opinions expressed in this email are
> those of the author and do not necessarily represent the views of 1E Ltd.
> Nothing in this email will operate to bind 1E to any order or other
> contract.
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545
> Please log in as guest with password guest if prompted
>
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>


-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c

[Dmitry Belyavsky via RT]

Hello,

I can confirm that I have seen a similar behavior in multi-thread
environment. Unfortunately, I do not have a script to reproduce it either.

On Fri, May 20, 2016 at 6:49 PM, Mick Saxton via RT <r...@openssl.org> wrote:

> Hi
>
> Before going any further I would like to state that I have only seen this
> problem when we have 1 or more concurrent connections.
>
> Mostly we notice it on Windows but I have seen it on linux (Ubuntu).
>
> I first noticed it when using v1.0.2d but have seen it again since
> upgrading to v1.0.2h.
>
> It can happen in one of two places and results in a call to MD_Update with
> a negative value.
>
> I have come up with a temporary fix which avoids the possibility of
> crashing at the expense of some randomness.
> The system is very highly stressed at this point so debugging further is
> difficult.
>
> The fix I am using is probably not what you eventually will want to
> implement but it does improve stability.
>
> 273:MD_Update(, &(state[st_idx]), (j - k) );
> Change to
> 273:MD_Update(, &(state[st_idx]), (j - k) > 0 ? j - k : 1);
> // mi...@1e.com (j -k) must not be negative
>
> And
>
> 495:MD_Update(, &(state[st_idx]), MD_DIGEST_LENGTH / 2 - k )
> Change to
> 495:MD_Update(, &(state[st_idx]), MD_DIGEST_LENGTH / 2 - k >
> 0 ? MD_DIGEST_LENGTH / 2 - k : 1);  // mi...@1e.com (j -k) must not be
> negative
>
>
> I do have a test program which can reproduce this behaviour.
>
> If I can be of further help - please contact me by email.
>
> Regards
> Mick Saxton
>
> 
>
>
> Legal Notice: This email is intended only for the person(s) to whom it is
> addressed. If you are not an intended recipient and have received this
> message in error, please notify the sender immediately by replying to this
> email or calling +44(0) 2083269015 (UK) or +1 866 592 4214 (USA). This
> email and any attachments may be privileged and/or confidential. The
> unauthorized use, disclosure, copying or printing of any information it
> contains is strictly prohibited. The opinions expressed in this email are
> those of the author and do not necessarily represent the views of 1E Ltd.
> Nothing in this email will operate to bind 1E to any order or other
> contract.
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545
> Please log in as guest with password guest if prompted
>
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>


-- 
SY, Dmitry Belyavsky

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4215] Results of regression for some apps

[Dmitry Belyavsky via RT]

Dear Stephen,

On Tue, May 17, 2016 at 3:26 AM, Stephen Henson via RT <r...@openssl.org>
wrote:

> On Mon May 16 22:17:57 2016, beld...@gmail.com wrote:
> > Dear Stephen,
> >
> > There was one more bugreport merged to this ticket regarding the OCSP
> > (#4216).
> > Could you take a look at it?
> >
>
> That should be fixed by commit 6302bbd21a79bd2ed
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4215
> Please log in as guest with password guest if prompted
>
>
Thank you for clarification!



-- 
SY, Dmitry Belyavsky

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4215
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4215] Results of regression for some apps

[Dmitry Belyavsky]

Dear Stephen,

On Tue, May 17, 2016 at 3:26 AM, Stephen Henson via RT <r...@openssl.org>
wrote:

> On Mon May 16 22:17:57 2016, beld...@gmail.com wrote:
> > Dear Stephen,
> >
> > There was one more bugreport merged to this ticket regarding the OCSP
> > (#4216).
> > Could you take a look at it?
> >
>
> That should be fixed by commit 6302bbd21a79bd2ed
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4215
> Please log in as guest with password guest if prompted
>
>
Thank you for clarification!



-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4215] Resolved: Results of regression for some apps

[Dmitry Belyavsky via RT]

Dear Stephen,

There was one more bugreport merged to this ticket regarding the OCSP
(#4216).
Could you take a look at it?

Thank you!

On Mon, May 16, 2016 at 8:33 PM, Stephen Henson via RT <r...@openssl.org>
wrote:

> According to our records, your request has been resolved. If you have any
> further questions or concerns, please respond to this message.
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4215
> Please log in as guest with password guest if prompted
>
>


-- 
SY, Dmitry Belyavsky

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4215
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4215] Results of regression for some apps

[Dmitry Belyavsky via RT]

Dear Stephen,


On Fri, May 13, 2016 at 2:41 PM, Stephen Henson via RT <r...@openssl.org>
wrote:

> On Mon Jan 04 14:07:23 2016, beld...@gmail.com wrote:
> > Hello!
> >
> > I found the following problems running my cipher suite with openssl 1.1.0
> >
> > 1. Some apps try to load the default config file twice. In case when we
> > load an engine via the config file and the engine prevents itself from
> > loading more than once, it causes errors.
> >
> > The attached patch contains fixes for the 'req' and 'ts' utilities, but
> may
> > be there are some more utilities with specific config files.
> >
> > 2. The 'smime' utility erroneously regards the '-signer' option to be the
> > name of input file. It's wrong when the utility uses this option in
> -verify
> > mode. So the attached patch makes this option to be processed as string,
> > not as input.
> >
> > 3. The 'cms' and 'smime' utilities do not accept the '-inform smime'
> > options. It may be a bug or not a bug (files in SMIME format are
> accepted)
> > but it is definitely an incompatibility.
> >
>
> Can you indicate if #1 is still a problem and if so give some details on
> how to
> reproduce it?
>

Yes. The bug is still reproducable with the req command.

To reproduce it, you need to specify the OPENSSL_CONF variable.
(You have to load the engine via config to enable the algorithms on startup
of the openssl).
The engine you load through the config must return an error on loading 2nd
time (as ccgost engine does).

So using the req command like this:

OPENSSL_CONF=openssl.conf openssl req -new -key mykey.pem

Will cause an error like this:

140444282672896:error:26078067:engine routines:engine_list_add:conflicting
engine id:crypto/engine/eng_list.c:116:
140444282672896:error:2606906E:engine routines:ENGINE_add:internal list
error:crypto/engine/eng_list.c:268:
140444282672896:error:260B6067:engine routines:dynamic_load:conflicting
engine id:crypto/engine/eng_dyn.c:544:
140444282672896:error:260BC066:engine routines:int_engine_configure:engine
configuration error:crypto/engine/eng_cnf.c:190:section=cryptocom_section,
name=dynamic_path, value=/path/to/libengine.so
140444282672896:error:0E07606D:configuration file
routines:module_run:module initialization
error:crypto/conf/conf_mod.c:221:module=engines, value=engine_section,
retcode=-1

To prevent it, it seems to me that it's necessary to check
whether the value of the variable 'template' does not match the variable
'default_config_file'
as the config file specified in the default_config_file variable is already
loaded.



>
> #2 and #3 should be addressed now.
>
> Thank you!


-- 
SY, Dmitry Belyavsky

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4215
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4215] Results of regression for some apps

[Dmitry Belyavsky]

Dear Stephen,


On Fri, May 13, 2016 at 2:41 PM, Stephen Henson via RT <r...@openssl.org>
wrote:

> On Mon Jan 04 14:07:23 2016, beld...@gmail.com wrote:
> > Hello!
> >
> > I found the following problems running my cipher suite with openssl 1.1.0
> >
> > 1. Some apps try to load the default config file twice. In case when we
> > load an engine via the config file and the engine prevents itself from
> > loading more than once, it causes errors.
> >
> > The attached patch contains fixes for the 'req' and 'ts' utilities, but
> may
> > be there are some more utilities with specific config files.
> >
> > 2. The 'smime' utility erroneously regards the '-signer' option to be the
> > name of input file. It's wrong when the utility uses this option in
> -verify
> > mode. So the attached patch makes this option to be processed as string,
> > not as input.
> >
> > 3. The 'cms' and 'smime' utilities do not accept the '-inform smime'
> > options. It may be a bug or not a bug (files in SMIME format are
> accepted)
> > but it is definitely an incompatibility.
> >
>
> Can you indicate if #1 is still a problem and if so give some details on
> how to
> reproduce it?
>

Yes. The bug is still reproducable with the req command.

To reproduce it, you need to specify the OPENSSL_CONF variable.
(You have to load the engine via config to enable the algorithms on startup
of the openssl).
The engine you load through the config must return an error on loading 2nd
time (as ccgost engine does).

So using the req command like this:

OPENSSL_CONF=openssl.conf openssl req -new -key mykey.pem

Will cause an error like this:

140444282672896:error:26078067:engine routines:engine_list_add:conflicting
engine id:crypto/engine/eng_list.c:116:
140444282672896:error:2606906E:engine routines:ENGINE_add:internal list
error:crypto/engine/eng_list.c:268:
140444282672896:error:260B6067:engine routines:dynamic_load:conflicting
engine id:crypto/engine/eng_dyn.c:544:
140444282672896:error:260BC066:engine routines:int_engine_configure:engine
configuration error:crypto/engine/eng_cnf.c:190:section=cryptocom_section,
name=dynamic_path, value=/path/to/libengine.so
140444282672896:error:0E07606D:configuration file
routines:module_run:module initialization
error:crypto/conf/conf_mod.c:221:module=engines, value=engine_section,
retcode=-1

To prevent it, it seems to me that it's necessary to check
whether the value of the variable 'template' does not match the variable
'default_config_file'
as the config file specified in the default_config_file variable is already
loaded.



>
> #2 and #3 should be addressed now.
>
> Thank you!


-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4438] AutoReply: GOST ciphersuites and DTLS

[Dmitry Belyavsky]

Hello!

The patch marking the GOST ciphersuites DTLS-uncapable is attached.

Thank you!

On Thu, Mar 17, 2016 at 4:28 PM, The default queue via RT <r...@openssl.org>
wrote:

>
> Greetings,
>
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
> "GOST ciphersuites and DTLS",
> a summary of which appears below.
>
> There is no need to reply to this message right now.  Your ticket has been
> assigned an ID of [openssl.org #4438].
>
> Please include the string:
>
>  [openssl.org #4438]
>
> in the subject line of all future correspondence about this issue. To do
> so,
> you may reply to this message.
>
> Thank you,
> r...@openssl.org
>
> -
> Hello OpenSSL team,
>
> The GOST ciphersuites currently defined are not DTLS-capable.
>
> So it should be fixed in the ssl/s3_lib.c file.
>
> Thank you!
>
> --
> SY, Dmitry Belyavsky
>
>
> ---------
> http://rt.openssl.org/Ticket/Display.html?id=4438=guest=guest
>



-- 
SY, Dmitry Belyavsky
diff --git a/ssl/s3_lib.c b/ssl/s3_lib.c
index ef65050..46987a9 100644
--- a/ssl/s3_lib.c
+++ b/ssl/s3_lib.c
@@ -2506,7 +2506,7 @@ static SSL_CIPHER ssl3_ciphers[] =
  SSL_eGOST2814789CNT,
  SSL_GOST89MAC,
  TLS1_VERSION, TLS1_2_VERSION,
- DTLS1_VERSION, DTLS1_2_VERSION,
+ 0, 0,
  SSL_HIGH,
  SSL_HANDSHAKE_MAC_GOST94 | TLS1_PRF_GOST94 | TLS1_STREAM_MAC,
  256,
@@ -2521,7 +2521,7 @@ static SSL_CIPHER ssl3_ciphers[] =
  SSL_eNULL,
  SSL_GOST94,
  TLS1_VERSION, TLS1_2_VERSION,
- DTLS1_VERSION, DTLS1_2_VERSION,
+ 0, 0,
  SSL_STRONG_NONE,
  SSL_HANDSHAKE_MAC_GOST94 | TLS1_PRF_GOST94,
  0,
@@ -2536,7 +2536,7 @@ static SSL_CIPHER ssl3_ciphers[] =
  SSL_eGOST2814789CNT12,
  SSL_GOST89MAC12,
  TLS1_VERSION, TLS1_2_VERSION,
- DTLS1_VERSION, DTLS1_2_VERSION,
+ 0, 0,
  SSL_HIGH,
  SSL_HANDSHAKE_MAC_GOST12_256 | TLS1_PRF_GOST12_256 | TLS1_STREAM_MAC,
  256,
@@ -2551,7 +2551,7 @@ static SSL_CIPHER ssl3_ciphers[] =
  SSL_eNULL,
  SSL_GOST12_256,
  TLS1_VERSION, TLS1_2_VERSION,
- DTLS1_VERSION, DTLS1_2_VERSION,
+ 0, 0,
  SSL_STRONG_NONE,
  SSL_HANDSHAKE_MAC_GOST12_256 | TLS1_PRF_GOST12_256 | TLS1_STREAM_MAC,
  0,
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4438] AutoReply: GOST ciphersuites and DTLS

[Dmitry Belyavsky via RT]

Hello!

The patch marking the GOST ciphersuites DTLS-uncapable is attached.

Thank you!

On Thu, Mar 17, 2016 at 4:28 PM, The default queue via RT <r...@openssl.org>
wrote:

>
> Greetings,
>
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
> "GOST ciphersuites and DTLS",
> a summary of which appears below.
>
> There is no need to reply to this message right now.  Your ticket has been
> assigned an ID of [openssl.org #4438].
>
> Please include the string:
>
>  [openssl.org #4438]
>
> in the subject line of all future correspondence about this issue. To do
> so,
> you may reply to this message.
>
> Thank you,
> r...@openssl.org
>
> -
> Hello OpenSSL team,
>
> The GOST ciphersuites currently defined are not DTLS-capable.
>
> So it should be fixed in the ssl/s3_lib.c file.
>
> Thank you!
>
> --
> SY, Dmitry Belyavsky
>
>
> ---------
> http://rt.openssl.org/Ticket/Display.html?id=4438=guest=guest
>



-- 
SY, Dmitry Belyavsky

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4438
Please log in as guest with password guest if prompted

diff --git a/ssl/s3_lib.c b/ssl/s3_lib.c
index ef65050..46987a9 100644
--- a/ssl/s3_lib.c
+++ b/ssl/s3_lib.c
@@ -2506,7 +2506,7 @@ static SSL_CIPHER ssl3_ciphers[] =
  SSL_eGOST2814789CNT,
  SSL_GOST89MAC,
  TLS1_VERSION, TLS1_2_VERSION,
- DTLS1_VERSION, DTLS1_2_VERSION,
+ 0, 0,
  SSL_HIGH,
  SSL_HANDSHAKE_MAC_GOST94 | TLS1_PRF_GOST94 | TLS1_STREAM_MAC,
  256,
@@ -2521,7 +2521,7 @@ static SSL_CIPHER ssl3_ciphers[] =
  SSL_eNULL,
  SSL_GOST94,
  TLS1_VERSION, TLS1_2_VERSION,
- DTLS1_VERSION, DTLS1_2_VERSION,
+ 0, 0,
  SSL_STRONG_NONE,
  SSL_HANDSHAKE_MAC_GOST94 | TLS1_PRF_GOST94,
  0,
@@ -2536,7 +2536,7 @@ static SSL_CIPHER ssl3_ciphers[] =
  SSL_eGOST2814789CNT12,
  SSL_GOST89MAC12,
  TLS1_VERSION, TLS1_2_VERSION,
- DTLS1_VERSION, DTLS1_2_VERSION,
+ 0, 0,
  SSL_HIGH,
  SSL_HANDSHAKE_MAC_GOST12_256 | TLS1_PRF_GOST12_256 | TLS1_STREAM_MAC,
  256,
@@ -2551,7 +2551,7 @@ static SSL_CIPHER ssl3_ciphers[] =
  SSL_eNULL,
  SSL_GOST12_256,
  TLS1_VERSION, TLS1_2_VERSION,
- DTLS1_VERSION, DTLS1_2_VERSION,
+ 0, 0,
  SSL_STRONG_NONE,
  SSL_HANDSHAKE_MAC_GOST12_256 | TLS1_PRF_GOST12_256 | TLS1_STREAM_MAC,
  0,
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] cms -decrypt calls RAND_pseudo_bytes

[Dmitry Belyavsky]

Hello,

We currently use the openssl 1.0.2g.

We found out that the cms -decrypt command line utility calls the
RAND_pseudo_bytes function.

In the file crypto/cms/cms_enc.c the function EVP_CIPHER_CTX_rand_key is
called both for the encryption and for the decryption.

Could we avoid the call to the EVP_CIPHER_CTX_rand_key function in case of
decryption? It seems unnecessary for me here, but I am not sure I
understand the whole situation.

Thank you!

-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Question about adding a new cipher [I am not asking the old question]

[Dmitry Belyavsky]

Dear John,

On Mon, Mar 21, 2016 at 2:52 PM, John Hunter <zhjw...@gmail.com> wrote:

> Hi Dmitry,
> Thank you for you quick reply.
>
> On Mon, Mar 21, 2016 at 7:38 PM, Dmitry Belyavsky <beld...@gmail.com>
> wrote:
> > Hello John,
> >
> > On Mon, Mar 21, 2016 at 1:53 PM, John Hunter <zhjw...@gmail.com> wrote:
> >>
> >> I know that this question had been asked millions of times, I searched
> the
> >> maillist archives and I know it, and this is not a homework for an
> >> academic
> >> project, trust me :)
> >>
> >> In [1], Victor said that we don't need to rebuild OpenSSL just for
> adding
> >> a
> >> crypto algrorithm, and he recoment to see the ccgost engine, I did, but
> >> I think that if we add a symmetric cipher, we will declare a EVP_CIPHER
> >> struct, which contains a nid, let's say NID_id_Gost28147_89, this nid
> was
> >> defined in crypto/objects/obj_mac.h, but if I don't have a nid for my
> new
> >> added cipher, I think we should add one into openssl, in that occasion I
> >> think we should rebuild the OpenSSL.
> >>
> >> I am appreciated if somebody could help to explain.
> >>
> >> [1]
> >>
> http://openssl.6102.n7.nabble.com/add-a-new-cipher-to-OpenSSL-td22968.html
> >
> >
> > In theory, you are able to register OID/NID via engine.
> > In practice when we implemented the GOST algorithms we found that
> sometimes
> > it causes memory problems.
> > And anyway, if you provide cipher via an engine, it just allows to use
> it in
> > some commands but not for TLS.
>
> So if I want to use the engine cipher, I should add some ciphersuit in
> ssl and rebuild
> the openssl, but I am wondering how will the ssl use the engine? Maybe add
> the
> engine to openssl.cnf?
>

Yes. And the application should also use the OPENSSL_config() function to
ensure the loading of the engine.

 And sometimes the applications have their own config file with the
directives to load engines as accelerators.


> For now I just use the engine cipher(not a new added cipher, but replace
> the
> aes-128-ecb using the engine) in command with the -engine xxx parameter, I
> don't know how to use the engine cipher as default(I mean without the
> -engine).
>
> Thanks in advance !
>
> >
> > --
> > SY, Dmitry Belyavsky
> >
> > --
> > openssl-dev mailing list
> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> >
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>



-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Question about adding a new cipher [I am not asking the old question]

[Dmitry Belyavsky]

Hello John,

On Mon, Mar 21, 2016 at 1:53 PM, John Hunter <zhjw...@gmail.com> wrote:

> I know that this question had been asked millions of times, I searched the
> maillist archives and I know it, and this is not a homework for an academic
> project, trust me :)
>
> In [1], Victor said that we don't need to rebuild OpenSSL just for adding a
> crypto algrorithm, and he recoment to see the ccgost engine, I did, but
> I think that if we add a symmetric cipher, we will declare a EVP_CIPHER
> struct, which contains a nid, let's say NID_id_Gost28147_89, this nid was
> defined in crypto/objects/obj_mac.h, but if I don't have a nid for my new
> added cipher, I think we should add one into openssl, in that occasion I
> think we should rebuild the OpenSSL.
>
> I am appreciated if somebody could help to explain.
>
> [1]
> http://openssl.6102.n7.nabble.com/add-a-new-cipher-to-OpenSSL-td22968.html


In theory, you are able to register OID/NID via engine.
In practice when we implemented the GOST algorithms we found that sometimes
it causes memory problems.
And anyway, if you provide cipher via an engine, it just allows to use it
in some commands but not for TLS.

-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4438] GOST ciphersuites and DTLS

[Dmitry Belyavsky via RT]

Hello OpenSSL team,

The GOST ciphersuites currently defined are not DTLS-capable.

So it should be fixed in the ssl/s3_lib.c file.

Thank you!

-- 
SY, Dmitry Belyavsky

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4438
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] links to KDF functions from pkeyutl man are broken

[Dmitry Belyavsky]

Dear Stephen,

On Fri, Mar 4, 2016 at 4:00 PM, Dr. Stephen Henson <st...@openssl.org>
wrote:

> On Fri, Mar 04, 2016, Dmitry Belyavsky wrote:
>
> > Dear Rich,
> >
> > Is it possible to add a command line option to select hash algorithm used
> > in the PRF calculations?
> > GOST ciphersuites, for example, use TLS1 PRF based on the GOST digest
> > algorithms.
> >
>
> I think it's already there -pkeyopt md:
>

Thank you for the clarification.

-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] links to KDF functions from pkeyutl man are broken

[Dmitry Belyavsky]

Dear Rich,

Is it possible to add a command line option to select hash algorithm used
in the PRF calculations?
GOST ciphersuites, for example, use TLS1 PRF based on the GOST digest
algorithms.

Thank you!

On Fri, Mar 4, 2016 at 1:24 PM, Salz, Rich <rs...@akamai.com> wrote:

> Yes, links across sections (apps/crypto etc) don’t work well.
>
>
>
> --
>
> Senior Architect, Akamai Technologies
>
> IM: richs...@jabber.at Twitter: RichSalz
>
>
>
> *From:* Michel [mailto:michel.sa...@free.fr]
> *Sent:* Friday, March 04, 2016 2:06 AM
> *To:* openssl-dev@openssl.org
> *Subject:* [openssl-dev] links to KDF functions from pkeyutl man are
> broken
>
>
>
> Hi,
>
>
>
> Just to let you know that the links to EVP_PKEY_HKDF and EVP_PKEY_TLS1_PRF
> are not [yet ?] operational.
>
> https://www.openssl.org/docs/manmaster/apps/pkeyutl.html
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_docs_manmaster_apps_pkeyutl.html=CwMFAg=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=QL3zFYk6lRve3OX7FKfEG1Tot1OPKUv6EwmwXxWS7Gg=n0GKswyZbWcCI7gnf8gZAFOmesnMQiJLDl30aqAfEQc=>
>
>
>
> Regards,
>
>
>
> Michel.
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>


-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4267] Missing accessor to the EVP_CIPHER_CTX member oiv

[Dmitry Belyavsky via RT]

Well, I think the ticket may be closed.

Thank you!

On Wed, Feb 24, 2016 at 8:47 PM, Richard Levitte via RT <r...@openssl.org>
wrote:

> If you're happy, I'm happy; it's that easy. If you think it's good, then
> it's
> time to close this ticket. You decide.
>
> Cheers,
> Richard
>
> Vid Ons, 24 Feb 2016 kl. 17.33.29, skrev beld...@gmail.com:
> > Dear Richard,
> >
> > The patch you suggested seems not to break at least self-compatibility
> for
> > the smime -enc command.
> > Is this enough or should I do some more tests?
> >
> > Thank you!
> >
> > On Fri, Feb 19, 2016 at 12:40 AM, Dmitry Belyavsky <beld...@gmail.com>
> > wrote:
> >
> > > Dear Richard,
> > >
> > > Sorry for the delay. I am out of office now so I will check it some
> days
> > > later.
> > >
> > >
> > > On Thursday, February 18, 2016, Richard Levitte via RT <r...@openssl.org
> >
> > > wrote:
> > >
> > >> Did that help, can we close this ticket now?
> > >>
> > >> Vid Ons, 17 Feb 2016 kl. 11.25.26, skrev levitte:
> > >> > May I suggest that you use EVP_CIPHER_set_asn1_iv() and/or
> > >> > EVP_CIPHER_get_asn1_iv()? With a temporary ASN1_TYPE to which you
> > >> > assign
> > >> > gcp->iv, that should be perfectly possible, no?
> > >> >
> > >> > Cheers,
> > >> > Richard
> > >> >
> > >> > Vid Ons, 17 Feb 2016 kl. 09.53.04, skrev beld...@gmail.com:
> > >> > > Dear Richard,
> > >> > >
> > >> > > I am not sure it will not break the compatibility.
> > >> > > Both implementations of the GOST ciphers require access to this
> > >> > > field.
> > >> > >
> > >> > > On Wed, Feb 17, 2016 at 12:42 PM, Richard Levitte via RT
> > >> > > <r...@openssl.org>
> > >> > > wrote:
> > >> > >
> > >> > > > Hi,
> > >> > > >
> > >> > > > I'm sorry, the oiv field is EVP private. Sure, it's been
> accessible
> > >> > > > (and
> > >> > > > thoroughly misused in some cases) when EVP_CIPHER_CTX was open,
> but
> > >> > > > in
> > >> > > > essence,
> > >> > > > it's a EVP private store of the IV that was given at
> > >> > > > EVP_CipherInit().
> > >> > > >
> > >> > > > If you want to retain a copy of the original IV, I suggest you
> have
> > >> > > > one in
> > >> > > > GOSTs structure and take a copy of the IV given to the init()
> > >> > > > function.
> > >> > > >
> > >> > > > Thank you for the reminder, I meant to deal with this further.
> oiv
> > >> > > > should
> > >> > > > really not be publically accessible at all, not even as a
> constant.
> > >> > > >
> > >> > > > Cheers,
> > >> > > > Richard
> > >> > > >
> > >> > > > Vid Sat, 23 Jan 2016 kl. 09.40.19, skrev beld...@gmail.com:
> > >> > > > > Hello,
> > >> > > > >
> > >> > > > > After making the EVP_CIPHER_CTX struct opaque I found that
> there
> > >> > > > > is a
> > >> > > > > missing non-const accessor to the oiv member. It is used in
> GOST
> > >> > > > > engine
> > >> > > > > when we set the cipher parameters from the ASN1 parameters.
> > >> > > > >
> > >> > > > > Thank you!
> > >> > > > >
> > >> > > >
> > >> > > >
> > >> > > > --
> > >> > > > Richard Levitte
> > >> > > > levi...@openssl.org
> > >> > > >
> > >> > > > --
> > >> > > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267
> > >> > > > Please log in as guest with password guest if prompted
> > >> > > >
> > >> > > >
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >> > --
> > >> > Richard Levitte
> > >> > levi...@openssl.org
> > >>
> > >>
> > >> --
> > >> Richard Levitte
> > >> levi...@openssl.org
> > >>
> > >> --
> > >> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267
> > >> Please log in as guest with password guest if prompted
> > >>
> > >>
> > >
> > > --
> > > SY, Dmitry Belyavsky
> > >
> >
> >
> >
>
>
> --
> Richard Levitte
> levi...@openssl.org
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267
> Please log in as guest with password guest if prompted
>
>


-- 
SY, Dmitry Belyavsky

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4267] Missing accessor to the EVP_CIPHER_CTX member oiv

[Dmitry Belyavsky]

Well, I think the ticket may be closed.

Thank you!

On Wed, Feb 24, 2016 at 8:47 PM, Richard Levitte via RT <r...@openssl.org>
wrote:

> If you're happy, I'm happy; it's that easy. If you think it's good, then
> it's
> time to close this ticket. You decide.
>
> Cheers,
> Richard
>
> Vid Ons, 24 Feb 2016 kl. 17.33.29, skrev beld...@gmail.com:
> > Dear Richard,
> >
> > The patch you suggested seems not to break at least self-compatibility
> for
> > the smime -enc command.
> > Is this enough or should I do some more tests?
> >
> > Thank you!
> >
> > On Fri, Feb 19, 2016 at 12:40 AM, Dmitry Belyavsky <beld...@gmail.com>
> > wrote:
> >
> > > Dear Richard,
> > >
> > > Sorry for the delay. I am out of office now so I will check it some
> days
> > > later.
> > >
> > >
> > > On Thursday, February 18, 2016, Richard Levitte via RT <r...@openssl.org
> >
> > > wrote:
> > >
> > >> Did that help, can we close this ticket now?
> > >>
> > >> Vid Ons, 17 Feb 2016 kl. 11.25.26, skrev levitte:
> > >> > May I suggest that you use EVP_CIPHER_set_asn1_iv() and/or
> > >> > EVP_CIPHER_get_asn1_iv()? With a temporary ASN1_TYPE to which you
> > >> > assign
> > >> > gcp->iv, that should be perfectly possible, no?
> > >> >
> > >> > Cheers,
> > >> > Richard
> > >> >
> > >> > Vid Ons, 17 Feb 2016 kl. 09.53.04, skrev beld...@gmail.com:
> > >> > > Dear Richard,
> > >> > >
> > >> > > I am not sure it will not break the compatibility.
> > >> > > Both implementations of the GOST ciphers require access to this
> > >> > > field.
> > >> > >
> > >> > > On Wed, Feb 17, 2016 at 12:42 PM, Richard Levitte via RT
> > >> > > <r...@openssl.org>
> > >> > > wrote:
> > >> > >
> > >> > > > Hi,
> > >> > > >
> > >> > > > I'm sorry, the oiv field is EVP private. Sure, it's been
> accessible
> > >> > > > (and
> > >> > > > thoroughly misused in some cases) when EVP_CIPHER_CTX was open,
> but
> > >> > > > in
> > >> > > > essence,
> > >> > > > it's a EVP private store of the IV that was given at
> > >> > > > EVP_CipherInit().
> > >> > > >
> > >> > > > If you want to retain a copy of the original IV, I suggest you
> have
> > >> > > > one in
> > >> > > > GOSTs structure and take a copy of the IV given to the init()
> > >> > > > function.
> > >> > > >
> > >> > > > Thank you for the reminder, I meant to deal with this further.
> oiv
> > >> > > > should
> > >> > > > really not be publically accessible at all, not even as a
> constant.
> > >> > > >
> > >> > > > Cheers,
> > >> > > > Richard
> > >> > > >
> > >> > > > Vid Sat, 23 Jan 2016 kl. 09.40.19, skrev beld...@gmail.com:
> > >> > > > > Hello,
> > >> > > > >
> > >> > > > > After making the EVP_CIPHER_CTX struct opaque I found that
> there
> > >> > > > > is a
> > >> > > > > missing non-const accessor to the oiv member. It is used in
> GOST
> > >> > > > > engine
> > >> > > > > when we set the cipher parameters from the ASN1 parameters.
> > >> > > > >
> > >> > > > > Thank you!
> > >> > > > >
> > >> > > >
> > >> > > >
> > >> > > > --
> > >> > > > Richard Levitte
> > >> > > > levi...@openssl.org
> > >> > > >
> > >> > > > --
> > >> > > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267
> > >> > > > Please log in as guest with password guest if prompted
> > >> > > >
> > >> > > >
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >> > --
> > >> > Richard Levitte
> > >> > levi...@openssl.org
> > >>
> > >>
> > >> --
> > >> Richard Levitte
> > >> levi...@openssl.org
> > >>
> > >> --
> > >> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267
> > >> Please log in as guest with password guest if prompted
> > >>
> > >>
> > >
> > > --
> > > SY, Dmitry Belyavsky
> > >
> >
> >
> >
>
>
> --
> Richard Levitte
> levi...@openssl.org
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267
> Please log in as guest with password guest if prompted
>
>


-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4344] Re: Missing accessor to the EVP_CIPHER_CTX member oiv

[Dmitry Belyavsky via RT]

Dear Richard,

The patch you suggested seems not to break at least self-compatibility for
the smime -enc command.
Is this enough or should I do some more tests?

Thank you!

On Fri, Feb 19, 2016 at 12:40 AM, Dmitry Belyavsky <beld...@gmail.com>
wrote:

> Dear Richard,
>
> Sorry for the delay. I am out of office now so I will check it some days
> later.
>
>
> On Thursday, February 18, 2016, Richard Levitte via RT <r...@openssl.org>
> wrote:
>
>> Did that help, can we close this ticket now?
>>
>> Vid Ons, 17 Feb 2016 kl. 11.25.26, skrev levitte:
>> > May I suggest that you use EVP_CIPHER_set_asn1_iv() and/or
>> > EVP_CIPHER_get_asn1_iv()? With a temporary ASN1_TYPE to which you
>> > assign
>> > gcp->iv, that should be perfectly possible, no?
>> >
>> > Cheers,
>> > Richard
>> >
>> > Vid Ons, 17 Feb 2016 kl. 09.53.04, skrev beld...@gmail.com:
>> > > Dear Richard,
>> > >
>> > > I am not sure it will not break the compatibility.
>> > > Both implementations of the GOST ciphers require access to this
>> > > field.
>> > >
>> > > On Wed, Feb 17, 2016 at 12:42 PM, Richard Levitte via RT
>> > > <r...@openssl.org>
>> > > wrote:
>> > >
>> > > > Hi,
>> > > >
>> > > > I'm sorry, the oiv field is EVP private. Sure, it's been accessible
>> > > > (and
>> > > > thoroughly misused in some cases) when EVP_CIPHER_CTX was open, but
>> > > > in
>> > > > essence,
>> > > > it's a EVP private store of the IV that was given at
>> > > > EVP_CipherInit().
>> > > >
>> > > > If you want to retain a copy of the original IV, I suggest you have
>> > > > one in
>> > > > GOSTs structure and take a copy of the IV given to the init()
>> > > > function.
>> > > >
>> > > > Thank you for the reminder, I meant to deal with this further. oiv
>> > > > should
>> > > > really not be publically accessible at all, not even as a constant.
>> > > >
>> > > > Cheers,
>> > > > Richard
>> > > >
>> > > > Vid Sat, 23 Jan 2016 kl. 09.40.19, skrev beld...@gmail.com:
>> > > > > Hello,
>> > > > >
>> > > > > After making the EVP_CIPHER_CTX struct opaque I found that there
>> > > > > is a
>> > > > > missing non-const accessor to the oiv member. It is used in GOST
>> > > > > engine
>> > > > > when we set the cipher parameters from the ASN1 parameters.
>> > > > >
>> > > > > Thank you!
>> > > > >
>> > > >
>> > > >
>> > > > --
>> > > > Richard Levitte
>> > > > levi...@openssl.org
>> > > >
>> > > > --
>> > > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267
>> > > > Please log in as guest with password guest if prompted
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> > --
>> > Richard Levitte
>> > levi...@openssl.org
>>
>>
>> --
>> Richard Levitte
>> levi...@openssl.org
>>
>> --
>> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267
>> Please log in as guest with password guest if prompted
>>
>>
>
> --
> SY, Dmitry Belyavsky
>



-- 
SY, Dmitry Belyavsky

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4344
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4321] Re: Missing accessor to the EVP_CIPHER_CTX member oiv

[Dmitry Belyavsky via RT]

Dear Richard,

Sorry for the delay. I am out of office now so I will check it some days
later.

On Thursday, February 18, 2016, Richard Levitte via RT <r...@openssl.org>
wrote:

> Did that help, can we close this ticket now?
>
> Vid Ons, 17 Feb 2016 kl. 11.25.26, skrev levitte:
> > May I suggest that you use EVP_CIPHER_set_asn1_iv() and/or
> > EVP_CIPHER_get_asn1_iv()? With a temporary ASN1_TYPE to which you
> > assign
> > gcp->iv, that should be perfectly possible, no?
> >
> > Cheers,
> > Richard
> >
> > Vid Ons, 17 Feb 2016 kl. 09.53.04, skrev beld...@gmail.com
> <javascript:;>:
> > > Dear Richard,
> > >
> > > I am not sure it will not break the compatibility.
> > > Both implementations of the GOST ciphers require access to this
> > > field.
> > >
> > > On Wed, Feb 17, 2016 at 12:42 PM, Richard Levitte via RT
> > > <r...@openssl.org <javascript:;>>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > I'm sorry, the oiv field is EVP private. Sure, it's been accessible
> > > > (and
> > > > thoroughly misused in some cases) when EVP_CIPHER_CTX was open, but
> > > > in
> > > > essence,
> > > > it's a EVP private store of the IV that was given at
> > > > EVP_CipherInit().
> > > >
> > > > If you want to retain a copy of the original IV, I suggest you have
> > > > one in
> > > > GOSTs structure and take a copy of the IV given to the init()
> > > > function.
> > > >
> > > > Thank you for the reminder, I meant to deal with this further. oiv
> > > > should
> > > > really not be publically accessible at all, not even as a constant.
> > > >
> > > > Cheers,
> > > > Richard
> > > >
> > > > Vid Sat, 23 Jan 2016 kl. 09.40.19, skrev beld...@gmail.com
> <javascript:;>:
> > > > > Hello,
> > > > >
> > > > > After making the EVP_CIPHER_CTX struct opaque I found that there
> > > > > is a
> > > > > missing non-const accessor to the oiv member. It is used in GOST
> > > > > engine
> > > > > when we set the cipher parameters from the ASN1 parameters.
> > > > >
> > > > > Thank you!
> > > > >
> > > >
> > > >
> > > > --
> > > > Richard Levitte
> > > > levi...@openssl.org <javascript:;>
> > > >
> > > > --
> > > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267
> > > > Please log in as guest with password guest if prompted
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > Richard Levitte
> > levi...@openssl.org <javascript:;>
>
>
> --
> Richard Levitte
> levi...@openssl.org <javascript:;>
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267
> Please log in as guest with password guest if prompted
>
>

-- 
SY, Dmitry Belyavsky

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4321
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4267] Missing accessor to the EVP_CIPHER_CTX member oiv

[Dmitry Belyavsky via RT]

Dear Richard,

I am not sure it will not break the compatibility.
Both implementations of the GOST ciphers require access to this field.

On Wed, Feb 17, 2016 at 12:42 PM, Richard Levitte via RT <r...@openssl.org>
wrote:

> Hi,
>
> I'm sorry, the oiv field is EVP private. Sure, it's been accessible (and
> thoroughly misused in some cases) when EVP_CIPHER_CTX was open, but in
> essence,
> it's a EVP private store of the IV that was given at EVP_CipherInit().
>
> If you want to retain a copy of the original IV, I suggest you have one in
> GOSTs structure and take a copy of the IV given to the init() function.
>
> Thank you for the reminder, I meant to deal with this further. oiv should
> really not be publically accessible at all, not even as a constant.
>
> Cheers,
> Richard
>
> Vid Sat, 23 Jan 2016 kl. 09.40.19, skrev beld...@gmail.com:
> > Hello,
> >
> > After making the EVP_CIPHER_CTX struct opaque I found that there is a
> > missing non-const accessor to the oiv member. It is used in GOST engine
> > when we set the cipher parameters from the ASN1 parameters.
> >
> > Thank you!
> >
>
>
> --
> Richard Levitte
> levi...@openssl.org
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267
> Please log in as guest with password guest if prompted
>
>


-- 
SY, Dmitry Belyavsky

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4267] Missing accessor to the EVP_CIPHER_CTX member oiv

[Dmitry Belyavsky]

Dear Richard,

I am not sure it will not break the compatibility.
Both implementations of the GOST ciphers require access to this field.

On Wed, Feb 17, 2016 at 12:42 PM, Richard Levitte via RT <r...@openssl.org>
wrote:

> Hi,
>
> I'm sorry, the oiv field is EVP private. Sure, it's been accessible (and
> thoroughly misused in some cases) when EVP_CIPHER_CTX was open, but in
> essence,
> it's a EVP private store of the IV that was given at EVP_CipherInit().
>
> If you want to retain a copy of the original IV, I suggest you have one in
> GOSTs structure and take a copy of the IV given to the init() function.
>
> Thank you for the reminder, I meant to deal with this further. oiv should
> really not be publically accessible at all, not even as a constant.
>
> Cheers,
> Richard
>
> Vid Sat, 23 Jan 2016 kl. 09.40.19, skrev beld...@gmail.com:
> > Hello,
> >
> > After making the EVP_CIPHER_CTX struct opaque I found that there is a
> > missing non-const accessor to the oiv member. It is used in GOST engine
> > when we set the cipher parameters from the ASN1 parameters.
> >
> > Thank you!
> >
>
>
> --
> Richard Levitte
> levi...@openssl.org
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267
> Please log in as guest with password guest if prompted
>
>


-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl-users] OpenSSL version 1.1.0 pre release 3 published

[Dmitry Belyavsky]

Dear Rich,


> Just to emphasize one important point:  Our next release is planned to be
> Beta-1, in about a month.  After that, no new API's or features will be
> added to OpenSSL 1.1
>
>
If so, could you take a look at RT#4267?

Thank you!

-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Endianess info

[Dmitry Belyavsky]

Dear Andy,

On Sun, Feb 14, 2016 at 1:27 PM, Andy Polyakov <ap...@openssl.org> wrote:

> > Does this patch work for you?
>
> I'd vote against [catering this information in public header]. As it
> stands now -D[BL]_ENDIAN in OpenSSL config lines is actually just an
> optimization flag, and not as significant one. "Optimization flag" means
> that you can actually omit it, and it will still work, and "not as
> significant" means that not very much slower. Real endian dependencies
> are handled either by adhering to endian-neutral coding practices or so
> called constant conditions, such as if (endian.little). Advantage of
> constant condition is that both paths are parsed by compilers, so that
> at least code handling "less popular" endianness doesn't end up in
> majority's blind spot. There is no reason for why either of these
> techniques can't be exercised in off-tree code.
>

The endianess information could be used in case of cross-compilation.

-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Endianess info

[Dmitry Belyavsky]

Dear Rich,

Thank you, this patch works for me.

On Thu, Feb 11, 2016 at 9:35 PM, Salz, Rich <rs...@akamai.com> wrote:

> Does this patch work for you?
>
> ; git diff
>
> diff --git a/Configure b/Configure
>
> index 3dc6a42..b36bc32 100755
>
> --- a/Configure
>
> +++ b/Configure
>
> @@ -1553,6 +1553,8 @@ foreach (grep /_asm_src$/, keys %target) {
>
>  ($target{$obj} = $target{$src}) =~ s/\.[csS]\b/.o/g;
>
> }
>
>
>
> +$config{lendian} = $config{cflags} =~ /-DL_ENDIAN/ ? 'define' : 'undef';
>
> +
>
> # Write down our configuration where it fits #
>
>
>
> open(OUT,">configdata.pm") || die "unable to create configdata.pm: $!\n";
>
> diff --git a/include/openssl/opensslconf.h.in b/include/openssl/
> opensslconf.h.in
>
> index d9f6429..9dc547f 100644
>
> --- a/include/openssl/opensslconf.h.in
>
> +++ b/include/openssl/opensslconf.h.in
>
> @@ -122,6 +122,8 @@ EOF
>
>
>
> /* Generate 80386 code? */
>
> {- $config{processor} eq "386" ? "#define" : "#undef" -} I386_ONLY
>
> +/* Big or little endian? */
>
> +{- $config{lendian} eq "define" ? "#define" : "#undef" -}
> OPENSSL_LITTLE_ENDIAN
>
>
>
> #undef OPENSSL_UNISTD
>
> #define OPENSSL_UNISTD {- $target{unistd} -}
>
>
>
> --
>
> Senior Architect, Akamai Technologies
>
> IM: richs...@jabber.at Twitter: RichSalz
>
>
>
> *From:* Dmitry Belyavsky [mailto:beld...@gmail.com]
> *Sent:* Thursday, February 11, 2016 12:45 PM
> *To:* openssl-dev@openssl.org
> *Subject:* Re: [openssl-dev] Endianess info
>
>
>
> Hello Rich,
>
>
>
>
>
>
>
> On Thu, Feb 11, 2016 at 8:39 PM, Salz, Rich <rs...@akamai.com> wrote:
>
> > Is the endianess information available in any of installed by the 1.1.0
> version *.h files?
> > All the other necessary for building an algorithms-providing engine
> outside of the openssl source tree can be found in the opensslconf.h file.
>
> No, but that's an excellent idea.  Which #define do you need "moved" from
> an existing header file?
>
>
>
> I need the L_ENDIAN #define.
>
>
>
> Thank you!
>
>
>
> --
>
> SY, Dmitry Belyavsky
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>


-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Endianess info

[Dmitry Belyavsky]

Dear Rich,

Thank you!
I'll test it during the weekend.

On Thu, Feb 11, 2016 at 9:35 PM, Salz, Rich <rs...@akamai.com> wrote:

> Does this patch work for you?
>
> ; git diff
>
> diff --git a/Configure b/Configure
>
> index 3dc6a42..b36bc32 100755
>
> --- a/Configure
>
> +++ b/Configure
>
> @@ -1553,6 +1553,8 @@ foreach (grep /_asm_src$/, keys %target) {
>
>  ($target{$obj} = $target{$src}) =~ s/\.[csS]\b/.o/g;
>
> }
>
>
>
> +$config{lendian} = $config{cflags} =~ /-DL_ENDIAN/ ? 'define' : 'undef';
>
> +
>
> # Write down our configuration where it fits #
>
>
>
> open(OUT,">configdata.pm") || die "unable to create configdata.pm: $!\n";
>
> diff --git a/include/openssl/opensslconf.h.in b/include/openssl/
> opensslconf.h.in
>
> index d9f6429..9dc547f 100644
>
> --- a/include/openssl/opensslconf.h.in
>
> +++ b/include/openssl/opensslconf.h.in
>
> @@ -122,6 +122,8 @@ EOF
>
>
>
> /* Generate 80386 code? */
>
> {- $config{processor} eq "386" ? "#define" : "#undef" -} I386_ONLY
>
> +/* Big or little endian? */
>
> +{- $config{lendian} eq "define" ? "#define" : "#undef" -}
> OPENSSL_LITTLE_ENDIAN
>
>
>
> #undef OPENSSL_UNISTD
>
> #define OPENSSL_UNISTD {- $target{unistd} -}
>
>
>
> --
>
> Senior Architect, Akamai Technologies
>
> IM: richs...@jabber.at Twitter: RichSalz
>
>
>
> *From:* Dmitry Belyavsky [mailto:beld...@gmail.com]
> *Sent:* Thursday, February 11, 2016 12:45 PM
> *To:* openssl-dev@openssl.org
> *Subject:* Re: [openssl-dev] Endianess info
>
>
>
> Hello Rich,
>
>
>
>
>
>
>
> On Thu, Feb 11, 2016 at 8:39 PM, Salz, Rich <rs...@akamai.com> wrote:
>
> > Is the endianess information available in any of installed by the 1.1.0
> version *.h files?
> > All the other necessary for building an algorithms-providing engine
> outside of the openssl source tree can be found in the opensslconf.h file.
>
> No, but that's an excellent idea.  Which #define do you need "moved" from
> an existing header file?
>
>
>
> I need the L_ENDIAN #define.
>
>
>
> Thank you!
>
>
>
> --
>
> SY, Dmitry Belyavsky
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>


-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Commit 17a723885e8a875fc19d5140f580f80a113ba78f

[Dmitry Belyavsky]

Hello all,

Does the code added by the commit 17a723885e8a875fc19d5140f580f80a113ba78f

+switch (EVP_PKEY_id(pk)) {
+default:
+return -1;
+case EVP_PKEY_RSA:
+return SSL_PKEY_RSA_ENC;
+case EVP_PKEY_DSA:
+return SSL_PKEY_DSA_SIGN;

with leading 'default' label work correctly?

Thank you!

-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Commit 17a723885e8a875fc19d5140f580f80a113ba78f

[Dmitry Belyavsky]

Dear Rich,

On Thu, Feb 11, 2016 at 8:30 PM, Salz, Rich <rs...@akamai.com> wrote:

> > with leading 'default' label work correctly?
>
> Yes, the order of case labels doesn't matter.  (In fact, it used to be the
> case that compilers -- back in the stone age, when they generated code on
> stone tablets -- used to be a little more efficient when you did that.)
>

Thank you! I was sure from the ancient times that the 'default' label
should be the last one...

-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Endianess info

[Dmitry Belyavsky]

Hello Rich,



On Thu, Feb 11, 2016 at 8:39 PM, Salz, Rich <rs...@akamai.com> wrote:

> > Is the endianess information available in any of installed by the 1.1.0
> version *.h files?
> > All the other necessary for building an algorithms-providing engine
> outside of the openssl source tree can be found in the opensslconf.h file.
>
> No, but that's an excellent idea.  Which #define do you need "moved" from
> an existing header file?
>

I need the L_ENDIAN #define.

Thank you!

-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Endianess info

[Dmitry Belyavsky]

Hello OpenSSL Team,

Is the endianess information available in any of installed by the 1.1.0
version *.h files?
All the other necessary for building an algorithms-providing engine outside
of the openssl source tree can be found in the opensslconf.h file.

Thank you!

-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4226] FIX: ADD IPv6 support for OCSP Responder

[Dmitry Belyavsky via RT]

Dear Rich,

On Mon, Jan 25, 2016 at 5:06 PM, Rich Salz via RT <r...@openssl.org> wrote:

> We are working on full IPv6 support and it will appear in the next release.
>

Do you mean 1.1.0?

Thank you!

-- 
SY, Dmitry Belyavsky

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

Re: [openssl-dev] [openssl.org #4226] FIX: ADD IPv6 support for OCSP Responder

[Dmitry Belyavsky]

Dear Rich,

On Mon, Jan 25, 2016 at 5:06 PM, Rich Salz via RT <r...@openssl.org> wrote:

> We are working on full IPv6 support and it will appear in the next release.
>

Do you mean 1.1.0?

Thank you!

-- 
SY, Dmitry Belyavsky
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4267] Missing accessor to the EVP_CIPHER_CTX member oiv

[Dmitry Belyavsky via RT]

Hello,

After making the EVP_CIPHER_CTX struct opaque I found that there is a
missing non-const accessor to the oiv member. It is used in GOST engine
when we set the cipher parameters from the ASN1 parameters.

Thank you!

-- 
SY, Dmitry Belyavsky

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

[openssl-dev] [openssl.org #4215] Results of regression for some apps

[Dmitry Belyavsky via RT]

Hello!

I found the following problems running my cipher suite with openssl 1.1.0

1. Some apps try to load the default config file twice. In case when we
load an engine via the config file and the engine prevents itself from
loading more than once, it causes errors.

The attached patch contains fixes for the 'req' and 'ts' utilities, but may
be there are some more utilities with specific config files.

2. The 'smime' utility erroneously regards the '-signer' option to be the
name of input file. It's wrong when the utility uses this option in -verify
mode. So the attached patch makes this option to be processed as string,
not as input.

3. The 'cms' and 'smime' utilities do not accept the '-inform smime'
options. It may be a bug or not a bug (files in SMIME format are accepted)
but it is definitely an incompatibility.

Thank you!

-- 
SY, Dmitry Belyavsky

diff --git a/apps/req.c b/apps/req.c
index a0da788..9235b2b 100644
--- a/apps/req.c
+++ b/apps/req.c
@@ -377,13 +377,14 @@ int req_main(int argc, char **argv)
 BIO_printf(bio_err, "Error getting passwords\n");
 goto end;
 }
-
+if (template != default_config_file)
+{
 if (verbose)
 BIO_printf(bio_err, "Using configuration from %s\n", template);
 req_conf = app_load_config(template);
 if (!app_load_modules(req_conf))
 goto end;
-
+}
 if (req_conf != NULL) {
 p = NCONF_get_string(req_conf, NULL, "oid_file");
 if (p == NULL)
diff --git a/apps/smime.c b/apps/smime.c
index 551a8fd..a1dde89 100644
--- a/apps/smime.c
+++ b/apps/smime.c
@@ -115,7 +115,7 @@ OPTIONS smime_options[] = {
 {"noattr", OPT_NOATTR, '-', "Don't include any signed attributes"},
 {"binary", OPT_BINARY, '-', "Don't translate message to text"},
 {"certfile", OPT_CERTFILE, '<', "Other certificates file"},
-{"signer", OPT_SIGNER, '<', "Signer certificate file"},
+{"signer", OPT_SIGNER, 's', "Signer certificate file"},
 {"recip", OPT_RECIP, '<', "Recipient certificate file for decryption"},
 {"in", OPT_IN, '<', "Input file"},
 {"inform", OPT_INFORM, 'F', "Input format SMIME (default), PEM or DER"},
diff --git a/apps/ts.c b/apps/ts.c
index 00b5e53..c1a3b05 100644
--- a/apps/ts.c
+++ b/apps/ts.c
@@ -319,10 +319,11 @@ int ts_main(int argc, char **argv)
 goto end;
 }
 
+if (configfile != default_config_file) {
 conf = load_config_file(configfile);
 if (!app_load_modules(conf))
 goto end;
-
+}
 /* Check parameter consistency and execute the appropriate function. */
 switch (mode) {
 default:
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4216] ocsp 1.1.0/1.0.2 incompatibility

[Dmitry Belyavsky via RT]

Hello,

I found an incompatibility in behavior of the 'ocsp' utility in the 1.0.2
and 1.1.0 versions.

The command line

openssl ocsp -issuer cacert.pem -CAfile cacert.pem -md_gost94 -cert
cert1.pem -sha1 -cert cert2.pem -reqout request.der

returns an error in 1.1.0:

ocsp: Digest must be before -cert or -serial
ocsp: Use -help for summary.

This command line worked well in 1.0.2.
Thank you!

-- 
SY, Dmitry Belyavsky

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Regression: dgst command

[Dmitry Belyavsky]

Hello,

I run my test suite for the openssl 1.1.0 version.

Executing the command

openssl dgst -md_gost94 -sign rsaseckey.pem -out sig.bin dgst.dat

I get an error:

Error setting context
47545377098440:error:0408C09D:rsa routines:check_padding_md:invalid
digest:rsa_pmeth.c:413:

The behavior have changed in 1.1.0. Is it a design decision (and I should
fix tests) or misbehavior?

Thank you!

-- 
SY, Dmitry Belyavsky
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4213] Error defining ciphersuite 0x0300ff87

[Dmitry Belyavsky via RT]

Hello,

I've found I made a typo introducing the GOST ciphersuite 0x0300ff87.
It's a ciphersuite with NULL encryption and so it is rarely used, that's
why I did not catch this mistake during the testing.

This specification requires using the "stream MAC" mode for this
ciphersuite. The patch is attached.

Thank you!

-- 
SY, Dmitry Belyavsky

diff --git a/ssl/s3_lib.c b/ssl/s3_lib.c
index e3e4fd3..50dbbc5 100644
--- a/ssl/s3_lib.c
+++ b/ssl/s3_lib.c
@@ -3284,7 +3284,7 @@ OPENSSL_GLOBAL const SSL_CIPHER ssl3_ciphers[] = {
  SSL_GOST12_256,
  SSL_TLSV1,
  SSL_STRONG_NONE,
- SSL_HANDSHAKE_MAC_GOST12_256 | TLS1_PRF_GOST12_256,
+ SSL_HANDSHAKE_MAC_GOST12_256 | TLS1_PRF_GOST12_256 | TLS1_STREAM_MAC,
  0,
  0},
 #endif
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Variable length of digest

[Dmitry Belyavsky]

Dear Victor,

On Thu, Dec 24, 2015 at 11:02 AM, Victor Wagner <vi...@wagner.pp.ru> wrote:

> On Thu, 24 Dec 2015 10:45:37 +0300
> Dmitry Belyavsky <beld...@gmail.com> wrote:
>
>
> > >
> > > If there's a new construct whose output size depends on the input
> > > data, that probably requires a new family of functions.
> > >
> >
> > Well, the gost-mac is treated specially itself and may be it can be
> > simplified introducing the new construction.
>
> Really it is MAC. I.e. it is combination of digest and pkey algorithms,
> and digest itself is never seen by any application. Applications only
> access MAC value via EVP_DigestSignFinal  interface. And it already
> allows variable size of signature.
>

If you try to change the output length via the -macopt option of the dgst
command, you'll see that the text output will be 4 bytes.
It seems to happen because of the internal call to the EVP_MD_size()
function.

If we change the EVP_MD_CTX_size() definition from a macro to a function
trying to call the ctrl function and then to fallback to the result of the
EVP_MD_size() function, it should improve the situation.

-- 
SY, Dmitry Belyavsky
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Variable length of digest

[Dmitry Belyavsky]

Hello OpenSSL Team,

I have a question.

I need to implement a digest with variable length of output. The length of
output can be easily specified by the control function, but EVP functions
expect the constant length of the digest result.

Is there a good solution how to fix it and will the patch providing such a
solution be acceptable?

Thank you!

-- 
SY, Dmitry Belyavsky
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Variable length of digest

[Dmitry Belyavsky]

Dear Stephen and Victor,

On Thu, Dec 24, 2015 at 1:37 AM, Viktor Dukhovni <openssl-us...@dukhovni.org
> wrote:

> On Wed, Dec 23, 2015 at 10:18:55PM +, Dr. Stephen Henson wrote:
>
> > That's an interesting question. What digest requires this? Is the output
> > length arbitrary or do the standards specify a maximum size?
>

I mean the gost-mac digest (implemented in the ccgost engine,
engines/ccgost/gost_crypt.c).
It allows the output to vary from 1 to 8 bytes, though 4 bytes is the most
common value.

We've added the control values implementing the variable length in our
repository (https://github.com/gost-engine/engine)


>
> With SHA3, NIST differentiates between fixed-length hash functions
> and variable-length XOFs.
>
> Introduction of variable length digests into OpenSSL would break
> applications that expect the EVP_MD family of functions to produce
> fixed length (input data indepdendent) results.
>
> If there's a new construct whose output size depends on the input
> data, that probably requires a new family of functions.
>

Well, the gost-mac is treated specially itself and may be it can be
simplified introducing the new construction.

Thank you!

-- 
SY, Dmitry Belyavsky
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4181] Error building openssl with REF_PRINT

[Dmitry Belyavsky via RT]

Hello OpenSSL team,
I get errors when I build openssl 1.0.2e with -DREF_PRINT -DREF_CHECK

./config -ggdb -DREF_PRINT -DREF_CHECK
make

ec_key.c: In function 'EC_KEY_free':
ec_key.c:115:14: error: called object is not a function or function pointer
 REF_PRINT("EC_KEY", r);
  ^
ec_key.c: In function 'EC_KEY_up_ref':
ec_key.c:219:14: error: called object is not a function or function pointer
 REF_PRINT("EC_KEY", r);
  ^
make[2]: *** [ec_key.o] Error 1
make[2]: Leaving directory `/home/beldmit/openssl-1.0.2e/crypto/ec'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/home/beldmit/openssl-1.0.2e/crypto'
make: *** [build_crypto] Error 1


-- 
SY, Dmitry Belyavsky

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4158] GOST 2012 compatibility is broken by commit 28f4580c1e510ccf4278a20975c9bc3306f758d6

[Dmitry Belyavsky via RT]

Hello OpenSSL Team,

I found out that the commit 28f4580c1e510ccf4278a20975c9bc3306f758d6 breaks
GOST 2012 client auth processing.

If the call to the EVP_PKEY_get_default_digest_nid() function is
unacceptable here, it can be replaced with the chain of if expressions (the
patch is attached).

BTW, what is a design policy in places when we have an enumeration of
algorithms?
I supposed that calling the implementation-provided callbacks is a right
way (or at least better then case expressions or chain of ifs)...

Thank you!

-- 
SY, Dmitry Belyavsky

index dcfb44f..0619507 100644
--- a/ssl/statem/statem_srvr.c
+++ b/ssl/statem/statem_srvr.c
@@ -3017,6 +3017,14 @@ MSG_PROCESS_RETURN tls_process_cert_verify(SSL *s, 
PACKET *pkt)
 #endif
 } else if (pkey->type == EVP_PKEY_RSA) {
 md = EVP_md5_sha1();
+#ifndef OPENSSL_NO_GOST
+} else if (pkey->type == NID_id_GostR3410_2001) {
+md = EVP_get_digestbynid(NID_id_GostR3411_94);
+} else if (pkey->type == NID_id_GostR3410_2012_256) {
+md = EVP_get_digestbynid(NID_id_GostR3411_2012_256);
+} else if (pkey->type == NID_id_GostR3410_2012_512) {
+md = EVP_get_digestbynid(NID_id_GostR3411_2012_512);
+#endif
 } else {
 md = EVP_sha1();
 }
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4158] GOST 2012 compatibility is broken by commit 28f4580c1e510ccf4278a20975c9bc3306f758d6

[Dmitry Belyavsky]

Dear Stephen,

On Mon, Nov 30, 2015 at 4:17 AM, Stephen Henson via RT <r...@openssl.org>
wrote:

> On Sun Nov 29 09:04:03 2015, beld...@gmail.com wrote:
> > Hello OpenSSL Team,
> >
> > I found out that the commit 28f4580c1e510ccf4278a20975c9bc3306f758d6
> breaks
> > GOST 2012 client auth processing.
> >
>
> This should be fixed by commit aa430c7467bcb7aa0a88
>

It works.
Thank you very much!


-- 
SY, Dmitry Belyavsky
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4158] GOST 2012 compatibility is broken by commit 28f4580c1e510ccf4278a20975c9bc3306f758d6

[Dmitry Belyavsky via RT]

Dear Stephen,

On Mon, Nov 30, 2015 at 4:17 AM, Stephen Henson via RT <r...@openssl.org>
wrote:

> On Sun Nov 29 09:04:03 2015, beld...@gmail.com wrote:
> > Hello OpenSSL Team,
> >
> > I found out that the commit 28f4580c1e510ccf4278a20975c9bc3306f758d6
> breaks
> > GOST 2012 client auth processing.
> >
>
> This should be fixed by commit aa430c7467bcb7aa0a88
>

It works.
Thank you very much!


-- 
SY, Dmitry Belyavsky

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

Re: [openssl-dev] PBE_UNICODE

[Dmitry Belyavsky]

Dear Andy,

On Fri, Nov 20, 2015 at 10:45 PM, Andy Polyakov <ap...@openssl.org> wrote:

>
> > The test example was provide by the authors of specification. There are
> > also examples in the document. May be it will be useful.
>
> We are apparently talking about slightly different things. Well, they
> are somewhat related, but not quite the same. It's just additional angle
> to cover.
>

Ok. Let's try to collect all the things.

1. We have a lack of Internet-wide specification regarding processing the
multibyte characters in PKCS#12.
2. We have the openssl code with 2 variants of such processing that can be
switched by the PBE_UNICODE define.
3. We have a "Russian" variant of specification.

I am interested mostly in compatibility between the openssl implementation
and "Russian" one when the password contains ASCII or Cyrillic characters.

How can I help?

-- 
SY, Dmitry Belyavsky
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] PBE_UNICODE

[Dmitry Belyavsky]

Dear Andy,

On Fri, Nov 20, 2015 at 1:48 PM, Andy Polyakov <ap...@openssl.org> wrote:
>
> > I understand that there should be problems with Windows.
>
> To eliminate possibility of misunderstanding. Claim is not limited to
> problems with Windows, but that OpenSSL handles non-ASCII characters in
> apparently non-interoperable way. On all systems. I referred to Windows
> as complicating factor in the problem, not whole/separate problem.


Yes, I understand it.

>
>
> > So the test PKCS12 object was created using Windows using a
> > GOST-providing CSP.
> >
> > I do not know whether the authors of the CSP have implemented their own
> > mechanism of transforming the password or used any provided by the
> > Windows system default.
>
> What are chances that they too used same formally incorrect approach?


I think that they use the system method, if any, because it means they do
not increase their work :-)

>
> > But in fact the openssl being built without defining the PBE_UNICODE
> > macros was able to parse the test PKCS12.
>
> Right. Doing otherwise will put burden of big-endian UTF-16 conversion
> on caller and chances that caller gets it right are low.


Ok.

>
>
> > Thank you!
>
> ??? So suggestion is leave it as it is? Well, given the presented
> evidence doing the right thing should break things for you. But does it
> mean that one can/should be excused from getting things right?

https://tools.ietf.org/html/rfc7292#appendix-B.1 says:

The underlying password-based encryption methods in PKCS #5 v2.1 view
   passwords (and salt) as being simple byte strings.
...
What's left unspecified in the above paragraph is precisely where the
   byte string representing a password comes from.  (This is not an
   issue with salt strings, since they are supplied as a password-based
   encryption (or authentication) parameter.)  PKCS #5 v2.1 says: "[...]
   a password is considered to be an octet string of arbitrary length
   whose interpretation as a text string is unspecified.  In the
   interest of interoperability, however, it is recommended that
   applications follow some common text encoding rules.  ASCII and UTF-8
   are two possibilities."

   In this specification, however, all passwords are created from
   BMPStrings with a NULL terminator.  This means that each character in
   the original BMPString is encoded in 2 bytes in big-endian format
   (most-significant byte first).  There are no Unicode byte order
   marks.  The 2 bytes produced from the last character in the BMPString
   are followed by 2 additional bytes with the value 0x00.

As I understand the text herein before, there is no ultimate specification.

So I would prefer a set of options be specified by the caller with a
reasonable default value.
But as I do not have enough PKCS#12 from real-life sources, I can't predict
this default value.

Currently the openssl is in "works for me" state. To propose changes, I
need to have a set of mismatching PKCS#12 files.

--
SY, Dmitry Belyavsky
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] PBE_UNICODE

[Dmitry Belyavsky]

Dear Andy,

On Fri, Nov 20, 2015 at 4:51 PM, Andy Polyakov <ap...@openssl.org> wrote:



>
> >> ??? So suggestion is leave it as it is? Well, given the presented
> >> evidence doing the right thing should break things for you. But does it
> >> mean that one can/should be excused from getting things right?
> >
> > https://tools.ietf.org/html/rfc7292#appendix-B.1 says:
> >
> >In this specification, however, all passwords are created from
> >BMPStrings with a NULL terminator.  This means that each character in
> >the original BMPString is encoded in 2 bytes in big-endian format
> >(most-significant byte first).  There are no Unicode byte order
> >marks.  The 2 bytes produced from the last character in the BMPString
> >are followed by 2 additional bytes with the value 0x00.
> >
> > As I understand the text herein before, there is no ultimate
> specification.
>
> Correct. At the same time it should be noted that there is explicit
> reference to 2-byte encoding and Unicode. Well, one can argue that when
> they mention Unicode they refer to [lack of] byte order mark, and byte
> order mark only, and it has nothing to do with what that 2nd byte is
> used for. [Or shall we say "1st" as we are looking at big-endian?] But
> at the same time they don't say that the additional byte has to be zero.
> The only sensible and natural thing to do is to use these 2 bytes for
> storing UTF-16 character, not to mechanically inject zeros into UTF-8
> encoded string as now... Of course one can say that latter, essentially
> unnatural way, is de-facto standard and we are stuck with it. But that
> would have to mean that it has to be harmonized on Windows. I refer to
> how OpenSSL pkcs12 works on Windows, not what somebody else does. In
> other words there is a dilemma. A. Choose what is right thing to do and
> act accordingly. B. Accept status quo with Unix as reference and
> harmonize Windows. Alternative to dilemma is to explicitly disclaim
> support for non-ASCII characters in pkcs12 utility.
>

There is a specification in Russian,
http://tk26.ru/methods/containers_v1/Addition_to_PKCS8_v1_0.pdf

It says:
"The password Psw should be represented in UTF-8 format without trailing
zero byte and passed as the P element of the PBKDF2 algorithm"

The test example was provide by the authors of specification. There are
also examples in the document. May be it will be useful.


-- 
SY, Dmitry Belyavsky
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] PBE_UNICODE

[Dmitry Belyavsky]

Dear Andy,

On Fri, Nov 20, 2015 at 12:08 PM, Andy Polyakov <ap...@openssl.org> wrote:

> > ... And on Windows it's even worse. As it stands now
> > even passing non-ASCII strings as command-line argument [and presumably
> > at prompt] is not an option.
>
> This is not entirely true. Whether or not one can pass non-ASCII strings
> as command-line argument is language-specific. Or rather code
> page-specific in Windowish. With Asian languages you're really out of
> luck, while smaller alphabets can work out (but not mixed) if system
> locale matches expectations.
>

I understand that there should be problems with Windows.
So the test PKCS12 object was created using Windows using a GOST-providing
CSP.

I do not know whether the authors of the CSP have implemented their own
mechanism of transforming the password or used any provided by the Windows
system default.

But in fact the openssl being built without defining the PBE_UNICODE macros
was able to parse the test PKCS12.

Thank you!

-- 
SY, Dmitry Belyavsky
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] PBE_UNICODE

[Dmitry Belyavsky]

Hello OpenSSL Team,

I use the openssl 1.0.2d.

There is a commented out definition of the PBE_UNICODE define in the file
pkcs12.h
I expected it to be necessary for correct processing of the Cyrillic
symbols in PKCS12 passwords, but my test shows that the password is
correctly processed when the PBE_UNICODE is undefined and locale is set to
ru_RU.utf8.

Do I miss something or this variable and corresponding #ifdef may be
eliminated?

Thank you!

-- 
SY, Dmitry Belyavsky
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4141] GOST ciphersuites

[Dmitry Belyavsky via RT]

Dear Stephen,

On Mon, Nov 16, 2015 at 5:22 PM, Stephen Henson via RT <r...@openssl.org>
wrote:

> On Sun Nov 15 10:04:28 2015, beld...@gmail.com wrote:
> > Hello!
> >
> > In the commit 5e3d21fef150f020e2d33439401da8f7e311aa24 you set
> > the SSL_SSLV3 for the GOST ciphersuites. But the GOST ciphersuites are
> not
> > usable with SSLv3, they require TLSv1.
> >
> > Could you turn the flag back for the GOST ciphersuites?
> >
>
> Does that commit break anything? It should not change the previous
> functionality in any way because we also had this in ssl_locl.h:
>

No, it does not break our tests.


>
> # define SSL_TLSV1 SSL_SSLV3/* for now */
>
> The subsequent commits change SSL_TLSV1 so it really disables ciphersuites
> in
> SSL v3 (before it didn't) and adds the flag to PSK+SHA2 ciphersuites, We
> can
> add SSL_TLSV1 to the GOST ciphersuites but that will change the behaviour
> from
> what it was before.
>

Usage of the GOST ciphersuites with the SSLv3 protocol is not specified, so
the change should not affect the GOST-related behaviour.
So I think it will be better for clarity.

Thank you!

-- 
SY, Dmitry Belyavsky

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

Re: [openssl-dev] [openssl.org #4141] GOST ciphersuites

[Dmitry Belyavsky]

Dear Stephen,

On Mon, Nov 16, 2015 at 5:22 PM, Stephen Henson via RT <r...@openssl.org>
wrote:

> On Sun Nov 15 10:04:28 2015, beld...@gmail.com wrote:
> > Hello!
> >
> > In the commit 5e3d21fef150f020e2d33439401da8f7e311aa24 you set
> > the SSL_SSLV3 for the GOST ciphersuites. But the GOST ciphersuites are
> not
> > usable with SSLv3, they require TLSv1.
> >
> > Could you turn the flag back for the GOST ciphersuites?
> >
>
> Does that commit break anything? It should not change the previous
> functionality in any way because we also had this in ssl_locl.h:
>

No, it does not break our tests.


>
> # define SSL_TLSV1 SSL_SSLV3/* for now */
>
> The subsequent commits change SSL_TLSV1 so it really disables ciphersuites
> in
> SSL v3 (before it didn't) and adds the flag to PSK+SHA2 ciphersuites, We
> can
> add SSL_TLSV1 to the GOST ciphersuites but that will change the behaviour
> from
> what it was before.
>

Usage of the GOST ciphersuites with the SSLv3 protocol is not specified, so
the change should not affect the GOST-related behaviour.
So I think it will be better for clarity.

Thank you!

-- 
SY, Dmitry Belyavsky
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4141] GOST ciphersuites

[Dmitry Belyavsky via RT]

Hello!

In the commit 5e3d21fef150f020e2d33439401da8f7e311aa24 you set
the SSL_SSLV3 for the GOST ciphersuites. But the GOST ciphersuites are not
usable with SSLv3, they require TLSv1.

Could you turn the flag back for the GOST ciphersuites?

Thank you!

-- 
SY, Dmitry Belyavsky

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Improving OpenSSL default RNG

[Dmitry Belyavsky]

Hello Alexander,

On Fri, Oct 23, 2015 at 4:22 PM, Alessandro Ghedini <alessan...@ghedini.me>
wrote:


> So, any thought? If there's interest in this, I can look into investigating
> these things more in detail and propose possible patches.
>
>
In Russia we have to certify the RNG hardware and software for using in
organizations where the certified products are required.
Currently we are able to implement custom RAND_METHODs and provide it via
engines. So if the hardware is unavailable, the RAND_bytes() call fails.

In the 1.0.* versions of the OpenSSL library not all calls to RAND*
functions were checked for success, and it caused some problems.
LibreSSL treats their RNG functions as never-failed, and I do not know
about BoringSSL.

So we need non-void RAND API and possibility to provide our own
RAND_METHODs. If the current code is to be refactored, I ask to leave these
options possible.

-- 
SY, Dmitry Belyavsky
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4106] Bug in smime command in master

[Dmitry Belyavsky via RT]

Hello!

When I try to verify the signed message using the master branch, I get an
error.

The command line is:

openssl smime -verify -inform der -in signed2_2_256.asn -noverify -signer
signer.certs -out was_signed.dat

STDERR CONTENTS:
smime: Cannot open input file signer.certs, No such file or directory

The message does not match the documentation and the behavior of the
command does not match the 1.0.2 version.

-- 
SY, Dmitry Belyavsky

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4104] A bug in the crl2pkc7 command in master

[Dmitry Belyavsky via RT]

Hello,

I've found a bug in the crl2pkc7 command in the master branch.

openssl crl2pkcs7 -in test.crl -certfile cert.pem -out p7.pem

Output:

error opening the file, -in
error loading certificates
140737354073768:error:02001002:system library:fopen:No such file or
directory:bss_file.c:175:fopen('-in','r')
140737354073768:error:2006D080:BIO routines:BIO_new_file:no such
file:bss_file.c:178:

The patch I attach fixes it.

-- 
SY, Dmitry Belyavsky

--- a/apps/crl2p7.c
+++ b/apps/crl2p7.c
@@ -138,7 +138,7 @@ int crl2pkcs7_main(int argc, char **argv)
 if ((certflst == NULL)
 && (certflst = sk_OPENSSL_STRING_new_null()) == NULL)
 goto end;
-if (!sk_OPENSSL_STRING_push(certflst, *(++argv))) {
+if (!sk_OPENSSL_STRING_push(certflst, opt_arg())) {
 sk_OPENSSL_STRING_free(certflst);
 goto end;
 }
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4099] Config is loaded twice in the openssl ts command line application

[Dmitry Belyavsky via RT]

Hello,

I found that the openssl ts command in master tries to load config file
twice.
To prevent it, the lines 323-324 should be removed.

The patch is attached.

Thank you!

-- 
SY, Dmitry Belyavsky

index 237dd01..222ca45 100644
--- a/apps/ts.c
+++ b/apps/ts.c
@@ -320,8 +320,6 @@ int ts_main(int argc, char **argv)
 }
 
 conf = load_config_file(configfile);
-if (!app_load_modules(conf))
-goto end;
 
 /* Check parameter consistency and execute the appropriate function. */
 switch (mode) {
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4093] AutoReply: Problem loading engine from config

[Dmitry Belyavsky via RT]

Hello!

The attached patch fixes it.

On Wed, Oct 14, 2015 at 10:10 PM, The default queue via RT <r...@openssl.org>
wrote:

>
> Greetings,
>
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
> "Problem loading engine from config",
> a summary of which appears below.
>
> There is no need to reply to this message right now.  Your ticket has been
> assigned an ID of [openssl.org #4093].
>
> Please include the string:
>
>  [openssl.org #4093]
>
> in the subject line of all future correspondence about this issue. To do
> so,
> you may reply to this message.
>
> Thank you,
> r...@openssl.org
>
> -
> Hello,
>
> I have a problem when I load an engine from config file in master.
>
> OpenSSL cmdline: /home/build/openssl-shell/openssl/apps/openssl dgst
> -md_gost94 dgst.dat
>
> Error configuring OpenSSL modules
> 47445915269832:error:25066067:DSO support routines:DLFCN_LOAD:could not
> load the shared library:dso_dlfcn.c:172:filename(libengines.so):
> libengines.so: cannot open shared object file: No such file or directory
> 47445915269832:error:25070067:DSO support routines:DSO_load:could not load
> the shared library:dso_lib.c:227:
> 47445915269832:error:0E07506E:configuration file
> routines:MODULE_LOAD_DSO:error loading dso:conf_mod.c:270:module=engines,
> path=engines
> 47445915269832:error:0E076071:configuration file
> routines:MODULE_RUN:unknown module name:conf_mod.c:212:module=engines
>
> The openssl.cnf file I use is:
>
> 
> openssl_conf = openssl_def
> [openssl_def]
> engines = engine_section
> [engine_section]
> gost=gost_section
> [gost_section]
> dynamic_path=/home/build/openssl-shell/openssl/engines/ccgost/libgost.so
> engine_id=gost
> default_algorithms = ALL
> 
>
> The gost engine I build is from the master.
>
> If I delete the lines
> 
> engines = engine_section
> [engine_section]
> 
> I get another error:
>
> dgst: Unknown digest md_gost94
> dgst: Use -help for summary.
>
> The behavior seems to be changed after the commit
>
> https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=a0a82324f965bbcc4faed4e1ee3fcaf81ea52166
>
> Thank you!
>
> --
> SY, Dmitry Belyavsky
>
>


-- 
SY, Dmitry Belyavsky

--- a/apps/openssl.c
+++ b/apps/openssl.c
@@ -175,6 +175,10 @@ static int apps_startup()
 ERR_load_crypto_strings();
 ERR_load_SSL_strings();
 
+OPENSSL_load_builtin_modules();
+#ifndef OPENSSL_NO_ENGINE
+ENGINE_load_builtin_engines();
+#endif
 if (!app_load_modules(NULL)) {
 ERR_print_errors(bio_err);
 BIO_printf(bio_err, "Error loading default configuration\n");
@@ -183,12 +187,8 @@ static int apps_startup()
 
 OpenSSL_add_all_algorithms();
 OpenSSL_add_ssl_algorithms();
-OPENSSL_load_builtin_modules();
 setup_ui_method();
 /*SSL_library_init();*/
-#ifndef OPENSSL_NO_ENGINE
-ENGINE_load_builtin_engines();
-#endif
 return 1;
 }
 

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

[openssl-dev] [openssl.org #4093] Problem loading engine from config

[Dmitry Belyavsky via RT]

Hello,

I have a problem when I load an engine from config file in master.

OpenSSL cmdline: /home/build/openssl-shell/openssl/apps/openssl dgst
-md_gost94 dgst.dat

Error configuring OpenSSL modules
47445915269832:error:25066067:DSO support routines:DLFCN_LOAD:could not
load the shared library:dso_dlfcn.c:172:filename(libengines.so):
libengines.so: cannot open shared object file: No such file or directory
47445915269832:error:25070067:DSO support routines:DSO_load:could not load
the shared library:dso_lib.c:227:
47445915269832:error:0E07506E:configuration file
routines:MODULE_LOAD_DSO:error loading dso:conf_mod.c:270:module=engines,
path=engines
47445915269832:error:0E076071:configuration file
routines:MODULE_RUN:unknown module name:conf_mod.c:212:module=engines

The openssl.cnf file I use is:


openssl_conf = openssl_def
[openssl_def]
engines = engine_section
[engine_section]
gost=gost_section
[gost_section]
dynamic_path=/home/build/openssl-shell/openssl/engines/ccgost/libgost.so
engine_id=gost
default_algorithms = ALL


The gost engine I build is from the master.

If I delete the lines

engines = engine_section
[engine_section]

I get another error:

dgst: Unknown digest md_gost94
dgst: Use -help for summary.

The behavior seems to be changed after the commit
https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=a0a82324f965bbcc4faed4e1ee3fcaf81ea52166

Thank you!

-- 
SY, Dmitry Belyavsky

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4073] Segfault in engine processing

[Dmitry Belyavsky via RT]

Hello Matt,

On Mon, Oct 12, 2015 at 12:08 PM, Matt Caswell via RT <r...@openssl.org>
wrote:

> On Tue Oct 06 20:08:12 2015, beld...@gmail.com wrote:
> > Hello!
> >
> > I get a segfault when executing the command
> >
> > openssl dgst -engine gost -md_gost94 -mac hmac -macop
> > key:123456901234567890123456789012
> >
>
> I assume this is on master? I can't reproduce this. Are you using your new
> GOST
> engine or the one currently in master?
>

Yes, it's on master. I think that I use the engine currently in master.
I'll try to reproduce it again.


-- 
SY, Dmitry Belyavsky

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

Re: [openssl-dev] [openssl.org #4073] Segfault in engine processing

[Dmitry Belyavsky]

Hello Matt,

On Mon, Oct 12, 2015 at 12:08 PM, Matt Caswell via RT <r...@openssl.org>
wrote:

> On Tue Oct 06 20:08:12 2015, beld...@gmail.com wrote:
> > Hello!
> >
> > I get a segfault when executing the command
> >
> > openssl dgst -engine gost -md_gost94 -mac hmac -macop
> > key:123456901234567890123456789012
> >
>
> I assume this is on master? I can't reproduce this. Are you using your new
> GOST
> engine or the one currently in master?
>

Yes, it's on master. I think that I use the engine currently in master.
I'll try to reproduce it again.


-- 
SY, Dmitry Belyavsky
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4073] Segfault in engine processing

[Dmitry Belyavsky]

Hello!

Thank you, I can't reproduce it either. Please close the ticket.
Sorry for disturbing.

On Mon, Oct 12, 2015 at 12:39 PM, Dmitry Belyavsky via RT <r...@openssl.org>
wrote:

> Hello Matt,
>
> On Mon, Oct 12, 2015 at 12:08 PM, Matt Caswell via RT <r...@openssl.org>
> wrote:
>
> > On Tue Oct 06 20:08:12 2015, beld...@gmail.com wrote:
> > > Hello!
> > >
> > > I get a segfault when executing the command
> > >
> > > openssl dgst -engine gost -md_gost94 -mac hmac -macop
> > > key:123456901234567890123456789012
> > >
> >
> > I assume this is on master? I can't reproduce this. Are you using your
> new
> > GOST
> > engine or the one currently in master?
> >
>
> Yes, it's on master. I think that I use the engine currently in master.
> I'll try to reproduce it again.
>
>
> --
> SY, Dmitry Belyavsky
>
> _______
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>



-- 
SY, Dmitry Belyavsky
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4073] Segfault in engine processing

[Dmitry Belyavsky via RT]

Hello!

Thank you, I can't reproduce it either. Please close the ticket.
Sorry for disturbing.

On Mon, Oct 12, 2015 at 12:39 PM, Dmitry Belyavsky via RT <r...@openssl.org>
wrote:

> Hello Matt,
>
> On Mon, Oct 12, 2015 at 12:08 PM, Matt Caswell via RT <r...@openssl.org>
> wrote:
>
> > On Tue Oct 06 20:08:12 2015, beld...@gmail.com wrote:
> > > Hello!
> > >
> > > I get a segfault when executing the command
> > >
> > > openssl dgst -engine gost -md_gost94 -mac hmac -macop
> > > key:123456901234567890123456789012
> > >
> >
> > I assume this is on master? I can't reproduce this. Are you using your
> new
> > GOST
> > engine or the one currently in master?
> >
>
> Yes, it's on master. I think that I use the engine currently in master.
> I'll try to reproduce it again.
>
>
> --
> SY, Dmitry Belyavsky
>
> _______
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>



-- 
SY, Dmitry Belyavsky

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

Re: [openssl-dev] [openssl.org #4089] NULL ciphersuites do not work in master

[Dmitry Belyavsky via RT]

Dear Kurt,

On Sun, Oct 11, 2015 at 9:13 PM, Kurt Roeckx via RT <r...@openssl.org> wrote:

> On Sun, Oct 11, 2015 at 05:54:16PM +0000, Dmitry Belyavsky via RT wrote:
> > Hello!
> >
> > When I debug, I see that the cipher is forbidden by
> > the ssl_security_default_callback function because of not enough security
> > bits.
>
> You can change the security level by using:
> -cipher NULL-SHA256@SECLEVEL=0
>

Thank you! It works. Please close the ticket.

-- 
SY, Dmitry Belyavsky

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

[openssl-dev] [openssl.org #4089] NULL ciphersuites do not work in master

[Dmitry Belyavsky via RT]

Hello!

I use the command lines for s_client ans s_server (built from master):

openssl s_server -www -cert cert.pem -key seckey.pem -cipher NULL-SHA256
-tls1

openssl s_client -connect localhost:4433 -CAfile sslCA/cacert.pem
-verify_return_error -verify 1 -state -cipher NULL-SHA256 -ign_eof

Client STDERR is

verify depth is 1
SSL_connect:before/connect initialization
SSL_connect:error in error
47960945916616:error:140830B5:SSL routines:ssl3_client_hello:no ciphers
available:s3_clnt.c:865:
SSL3 alert write:warning:close notify

When I debug, I see that the cipher is forbidden by
the ssl_security_default_callback function because of not enough security
bits.

Is it a bug or feature?

-- 
SY, Dmitry Belyavsky

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4089] NULL ciphersuites do not work in master

[Dmitry Belyavsky]

Dear Kurt,

On Sun, Oct 11, 2015 at 9:13 PM, Kurt Roeckx via RT <r...@openssl.org> wrote:

> On Sun, Oct 11, 2015 at 05:54:16PM +0000, Dmitry Belyavsky via RT wrote:
> > Hello!
> >
> > When I debug, I see that the cipher is forbidden by
> > the ssl_security_default_callback function because of not enough security
> > bits.
>
> You can change the security level by using:
> -cipher NULL-SHA256@SECLEVEL=0
>

Thank you! It works. Please close the ticket.

-- 
SY, Dmitry Belyavsky
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4085] Bug in genpkey in master

[Dmitry Belyavsky via RT]

Hello,

I've found a bug in the genpkey command in the master branch.

If we use an algorithm provided by an engine and the engine is loaded via
config, the algorithm can't be found during the command line options
processing.

The solution I suggest is moving the app_load_modules() call before the
options loop.
I think this can be used in all cmdline utilities accepting algorithm name
from options.

Thank you!

-- 
SY, Dmitry Belyavsky

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4086] s_server bug in master

[Dmitry Belyavsky via RT]

Hello,

I've found a bug in s_server command line application in master branch.

During apps_startup() the OpenSSL_add_ssl_algorithms() function is called
 before loading any engines.

The OpenSSL_add_ssl_algorithms() is defined as SSL_library_init().

The SSL_library_init() builds a list of available ciphersuites. In case of
engine-provided algorithms some ciphersuites will be disabled because the
engine providing algorithms is not loaded yet.

The list of ciphersuites is not rebuilded after loading engines. So the
engine-dependent ciphersuites are not available.


-- 
SY, Dmitry Belyavsky

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Adding async support

[Dmitry Belyavsky]

Dear Matt,

I have some questions.

On Thu, Oct 8, 2015 at 12:32 AM, Matt Caswell <m...@openssl.org> wrote:

>
>
> On 07/10/15 21:44, Dmitry Belyavsky wrote:
> > Dear Matt,
> >
> > On Wed, Oct 7, 2015 at 4:43 PM, Matt Caswell <m...@openssl.org
> > <mailto:m...@openssl.org>> wrote:
> >
> >
> >
> > On 07/10/15 14:29, Viktor Dukhovni wrote:
> > >
> > > Should applications generally enable async mode because that might
> > > be beneficial down the road?  Or is this just for exotic hardware
> > > not likely to be seen in most environments?
> >
> > It will only be helpful if you have an engine capable of supporting
> > async. I can't really answer the question because I don't know how
> > common this will be. My hope is that this will become relatively
> common.
> > I have been toying with the idea of creating a multi-threaded async
> > engine where the engine manages a pool of threads to offload async
> work
> > to which would then offer true async support even if you don't have
> > specialist hardware.
> >
> >
> > If we have an engine executing long crypto operations, how can we adopt
> > the engine and software using this engine to process them asynchronously?
>
> The engine needs to have a way of offloading the work to "something
> else" so that it can come back and pick up the results later. Typically
> for an engine this would mean some external hardware, but as I suggested
> above it could be done using threads.
>
> From an engine perspective the work would be:
> - Receive a request to do some crypto work in the normal way via the
> engine API.
> - Offload the work to "something else"
>

So what is a mechanism of such an offload? Can I, for example, get the
(global) ASYNC_pool and add a job (function/pointer to context) to it?


> - Call the new API function ASYNC_pause_job(). This will return control
> back to the calling application.
>


> - At sometime later, preferably when the application knows the work has
> completed (* see below), the application will resume the async job. From
> an engine perspective this just appears as the ASYNC_pause_job()
> function call returning - so it just continues where it left off
> - The engine should verify that the work offloaded to "something else"
> has completed.
> - If not it just calls ASYNC_pause_job() again as before.
> - If it has completed then it collects the results and returns them back
> in the normal way for an engine
>
> From an application perspective it depends whether it is using libcrypto
> directly, or whether it is using libssl.
>
> If libssl then:
> - the application essentially operates as normal
> - additionally it must call either SSL_CTX_set_mode() or SSL_set_mode to
> set the SSL_ASYNC_MODE
> - In any call to SSL_read/SSL_write/SSL_accept/SSL_connect etc, it must
> be prepared to handle an SSL_ERROR_WANT_ASYNC response. This works in
> essentially the same way as SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE,
> i.e sometime later (* see below) it recalls
> SSL_read/SSL_write/SSL_accept/SSL_connect and the async job is resumed.
>

How will the SSL struct obtain a job id from the engine implementing, for
example, "long" RSA_METHOD?


>
> If using libcrypto then:
> - the application must determine which crypto operations it wants to
> perform asynchronously. Those operations should be wrapped in an
> application defined function.
> - the application initiates the async job by calling ASYNC_start_job and
> passing in a pointer to the function to be started as a job.
> - from an engine perspective it will work in exactly the same way as for
> libssl initiated crypto work.
> - ASYNC_start_job may return with an ASYNC_PAUSE response. The
> application can go off and do other work, and then resume the job at a
> later time by recalling ASYNC_start_job.
>

So do I understand correctly that if I want to perform SSL operations
asynchronously,
I'm able to wrap the SSL functions into the application defined functions
and then behave as described
herein before?


>
>
> So the next question is how does the application know when it is ok to
> resume a job? There are two basic models:
>
> - Event based...essentially the engine signals to the application that
> the results are ready for collection
> - Polling...in this model the application will have to periodically
> restart the job to see if it is ready to be continued or not
>
> There are API calls available for the event based model. See
> ASYNC_wake(), ASYNC_clear_wake(), ASYNC_get_wait_fd(), and
> SSL_get_async_wait_fd() in the documentation links I sent out previously.
>
> There is some example code in the ASYNC_start_job() documentation. You
> can also look at the source code for the dummy async engine.
>

Thank you. I've looked through them but still did not understand completely.


-- 
SY, Dmitry Belyavsky
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Adding async support

[Dmitry Belyavsky]

Dear Matt,

On Thu, Oct 8, 2015 at 1:56 PM, Matt Caswell <m...@openssl.org> wrote:

>
> > The engine needs to have a way of offloading the work to "something
> > else" so that it can come back and pick up the results later.
> Typically
> > for an engine this would mean some external hardware, but as I
> suggested
> > above it could be done using threads.
> >
> > From an engine perspective the work would be:
> > - Receive a request to do some crypto work in the normal way via the
> > engine API.
> > - Offload the work to "something else"
> >
> >
> > So what is a mechanism of such an offload? Can I, for example, get the
> > (global) ASYNC_pool and add a job (function/pointer to context) to it?
>
> The offload mechanism is entirely engine specific. We do not know how
> any specific engine works or how to interface to the hardware. An engine
> will be called in exactly the same way as now. The job of the engine
> will be to take the parameters passed to it and initiate the work in the
> engine hardware.
>
> So in pseudo code it might look something like this:
>
> static int myengine_aes128_cbc_cipher(EVP_CIPHER_CTX *ctx,
> unsigned char *out, const unsigned char *in, size_t inl)
> {
> int jobid;
>
> jobid = offload_cipher_to_hardware(ctx, out, in , inl);
>
> /*
>  * jobid holds a reference in the engine back to the work we just
>  * started
>  */
>
> while(work_not_finished_yet(jobid)) {
> /* Return control back to the calling application */
> ASYNC_pause_job();
> }
>
> return get_results_from_hardware(jobid);
> }
>
> You will note that ASYNC_pause_job() does *not* do a "return" to return
> control back to the user application...but calling ASYNC_pause_job()
> will cause SSL_read (or whatever) to return with SSL_ERROR_WANT_ASYNC
> nonetheless. The async job has its own private stack to enable this.
> Recalling SSL_read from the user application will appear to the engine
> like the function call ASYNC_pause_job() has returned.
>
>
> > How will the SSL struct obtain a job id from the engine implementing,
> > for example, "long" RSA_METHOD?
>
> It does not need to. The SSL object has a reference to the ASYNC_JOB.
> The engine can manage its own job ids - see the pseudo code above.
>

I see. So am I correct supposing that pseudo code for
offload_cipher_to_hardware looks like this:

static int async_wrapper(void * args)
{
...
}

static ASYNC_JOB *offload (void *args)
{
  ASYNC_JOB *pjob = NULL;
  int funcret;
  size_t size = 0;

  int ret = ASYNC_start_job(, , async_wrapper, args,
  *args, size);
  if (ret != ASYNC_PAUSE) return NULL;
  return pjob;
}

?

Thank you!

-- 
SY, Dmitry Belyavsky
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Adding async support

[Dmitry Belyavsky]

Dear Matt,

On Thu, Oct 8, 2015 at 3:17 PM, Matt Caswell <m...@openssl.org> wrote:

>
>
> No. I think you are confusing two different things.
>
> 1) How does an *application* perform asynchronous work (via libssl or
> libcrypto) using an asynchronous capable engine?
>

Ok. There is an example an explanation you have provided.


>
> 2) How does an asynchronous capable engine offload async work to its
> hardware?
>
> These patches solve the first problem only. It provides an API and
> mechanism for control to pass between the application and engine and
> back again (perhaps multiple times) during the invocation of a long
> running crypto operation. It also provides some mechanisms to enable an
> engine to signal the completion of work to the application.
>


> The second problem is entirely engine dependant. It will be a different
> solution for different hardware. These patches do not provide a solution
> to that problem.
>

So I do not understand what you mean by "offload" :-(

I understand that it's an engine-dependent, but I can't imagine a
corresponding pseudo code.


-- 
SY, Dmitry Belyavsky
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Adding async support

[Dmitry Belyavsky]

Dear  Matt,

On Thu, Oct 8, 2015 at 10:06 PM, Matt Caswell <m...@openssl.org> wrote:

>
>
> On 08/10/15 18:56, Dmitry Belyavsky wrote:
>
> > The second problem is entirely engine dependant. It will be a
> different
> > solution for different hardware. These patches do not provide a
> solution
> > to that problem.
> >
> >
> > So I do not understand what you mean by "offload" :-(
> >
> > I understand that it's an engine-dependent, but I can't imagine a
> > corresponding pseudo code.
>
> Ok. So this is the pseudo code I posted before for how an engine might
> be implemented:
>
> static int myengine_aes128_cbc_cipher(EVP_CIPHER_CTX *ctx,
> unsigned char *out, const unsigned char *in, size_t inl)
> {
> int jobid;
>
> jobid = offload_cipher_to_hardware(ctx, out, in , inl);
>
> /*
>  * jobid holds a reference in the engine back to the work we just
>  * started
>  */
>
> while(work_not_finished_yet(jobid)) {
> /* Return control back to the calling application */
> ASYNC_pause_job();
> }
>
> return get_results_from_hardware(jobid);
> }
>
>
> So lets imagine an engine that works via threads and how those pseudo
> code function call might be implemented. It could be something like this:
>
> void initialise_engine(void)
> {
> start_thread(worker_main);
> }
>
> static int nextjobid = 0;
>
> struct work_st {
> int jobid;
> EVP_CIPHER_CTX *ctx;
> unsigned char *out;
> unsigned char *in;
> size_t inl;
> int ret;
> }
>
> int worker_main(void)
> {
> struct work_st *work;
>
> while(true) {
> work = get_work_off_in_queue();
> /* This is a long running operation */
> work->ret = do_aes128_cbc_cipher(work->ctx, work->out, work->in,
> work->inl);
> put_work_in_finished_set(work);
> }
> }
>
> int offload_cipher_to_hardware(EVP_CIPHER_CTX *ctx, unsigned char *out,
> unsigned char *in, size_t inl) {
> struct work_st *work;
>
> work = malloc(sizeof *work);
> work->ctx = ctx;
> work->out = out;
> work->in = in;
> work->inl = inl;
> work->jobid = nextjobid++;
>
> add_work_to_in_queue(work);
>
> return work->jobid;
> }
>
> int work_not_finished_yet(int jobid)
> {
> return !is_work_in_finished_set(jobid);
> }
>
> int get_results_from_hardware(int jobid)
> {
> struct work_st *work;
>
> work = get_work_out_of_finished_set(jobid);
>
> return work->ret;
> }
>
> In a hardware based engine everything in "worker_main" would be
> implemented in the hardware. So the hardware gets on with the long
> running crypto operation, whilst in the software control has returned
> back to the application.
>
> Does that make more sense?
>

Thank you! I finally got it.


-- 
SY, Dmitry Belyavsky
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev