On 25/10/2018 10:12, ramakrushna mishra wrote:
> Hi Matt,
>
> Thank you for the response.
> But I wanted to know the handshake behavior when client has support for
> "TLSv1.3,TLSv1.2" and server has support for ("TLSv1.2,TLSv1") or
> ("TLSv1.2,SSLv3).
>
> Both client and server is built with openssl 1.1.1 and the above
> connection fails with handshake failure. The same connection works if
> server has continious range of protocol version such as
> ("TLSv1.2,TLSv1.1,TLSv1,SSLv3).
>
> So, is the handshake behavior change if the supported protocol versions
> are not in continuous range ?
On the server side I would expect this to successfully connect with
TLSv1.2. I just tested this using s_server/s_client and it worked as
expected:
$ openssl s_server -no_tls1_3 -no_tls1_1
$ openssl s_client -min_protocol "TLSv1.2"
A non continuous range on the client side works slightly differently. So
this fails:
$ openssl s_server -min_protocol "TLSv1.2"
$ openssl s_client -no_tls1_3 -no_tls1_1
This is because of the way the supported versions are advertised by the
client in the ClientHello. In the above scenario the client will
advertise TLSv1.0 as its highest supported version.
Matt
>
> Thanks and regards,
> Ram Krushna
>
> On Wed, Oct 24, 2018 at 10:14 PM <openssl-users-request@xxxxxxxxxxx
> <mailto:openssl-users-request@xxxxxxxxxxx>> wrote:
>
> Send openssl-users mailing list submissions to
> openssl-users@xxxxxxxxxxx <mailto:openssl-users@xxxxxxxxxxx>
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mta.openssl.org/mailman/listinfo/openssl-users
> or, via email, send a message with subject or body 'help' to
> openssl-users-request@xxxxxxxxxxx
> <mailto:openssl-users-request@xxxxxxxxxxx>
>
> You can reach the person managing the list at
> openssl-users-owner@xxxxxxxxxxx
> <mailto:openssl-users-owner@xxxxxxxxxxx>
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openssl-users digest..."
>
>
> Today's Topics:
>
> 1. Re: Reg issue in alert message (Matt Caswell)
> 2. Using SM2 ECIES in 1.1.1 (Akira Takahashi)
> 3. Re: Using SM2 ECIES in 1.1.1 (Matt Caswell)
> 4. openssl cms encrypt recipientInfo [questions for openssl
> developers]. (???? ?????????)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 24 Oct 2018 13:57:04 +0100
> From: Matt Caswell <matt@xxxxxxxxxxx <mailto:matt@xxxxxxxxxxx>>
> To: openssl-users@xxxxxxxxxxx <mailto:openssl-users@xxxxxxxxxxx>
> Subject: Re: Reg issue in alert message
> Message-ID: <eb5d58cb-e8b8-fc6b-5992-a25e83e8d2e6@xxxxxxxxxxx
> <mailto:eb5d58cb-e8b8-fc6b-5992-a25e83e8d2e6@xxxxxxxxxxx>>
> Content-Type: text/plain; charset=utf-8
>
>
>
> On 24/10/2018 13:25, ramakrushna mishra wrote:
> > Hi All,
> >
> > Thank you for all for providing the information.
> > I suspect we are using " SSL_MODE_SEND_FALLBACK_SCSV??" and that might
> > be causing the issue.? The team is looking into this issue now
> with the
> > provided information.?
> >
> > ?One doubt that came during? our investigation is :
> > " If client has highest version of TLS1.3 and server has support for
> > TLS1.2 and SLV3 only.? ?How the handshake will? proceed ? "
>
> The protocol will negotiate the highest commonly supported protocol
> version. So if the server supports TLS1.3 and the client only supports
> TLS1.2 then TLS1.2 will be used. Don't use SSLv3. That is disabled by
> default in current OpenSSL versions.
>
> Matt
>
> > I am not sure if this question should go to a new thread ?
> >
> > Thanks and Regards,
> > Ram Krushna
> >
> > On Wed, Oct 24, 2018 at 11:47 AM
> <openssl-users-request@xxxxxxxxxxx
> <mailto:openssl-users-request@xxxxxxxxxxx>
> > <mailto:openssl-users-request@xxxxxxxxxxx
> <mailto:openssl-users-request@xxxxxxxxxxx>>> wrote:
> >
> > Send openssl-users mailing list submissions to
> > ? ? ? ? openssl-users@xxxxxxxxxxx
> <mailto:openssl-users@xxxxxxxxxxx> <mailto:openssl-users@xxxxxxxxxxx
> <mailto:openssl-users@xxxxxxxxxxx>>
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > ? ? ? ? https://mta.openssl.org/mailman/listinfo/openssl-users
> > or, via email, send a message with subject or body 'help' to
> > ? ? ? ? openssl-users-request@xxxxxxxxxxx
> <mailto:openssl-users-request@xxxxxxxxxxx>
> > <mailto:openssl-users-request@xxxxxxxxxxx
> <mailto:openssl-users-request@xxxxxxxxxxx>>
> >
> > You can reach the person managing the list at
> > ? ? ? ? openssl-users-owner@xxxxxxxxxxx
> <mailto:openssl-users-owner@xxxxxxxxxxx>
> > <mailto:openssl-users-owner@xxxxxxxxxxx
> <mailto:openssl-users-owner@xxxxxxxxxxx>>
> >
> > When replying, please edit your Subject line so it is more
> specific
> > than "Re: Contents of openssl-users digest..."
> >
> >
> > Today's Topics:
> >
> > ? ?1. Re: CAPI-Engine doc (Selva Nair)
> > ? ?2. Re: CAPI-Engine doc (Michael Wojcik)
> > ? ?3. Re: Reg issue in alert message (Michael Wojcik)
> > ? ?4. Re: CAPI-Engine doc (Jakob Bohm)
> > ? ?5. Re: Openssl Build Error- module unsafe for SAFESEH
> > ? ? ? image/Unable to generate SAFESEH image (sakdev)
> >
> >
> >
> ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Tue, 23 Oct 2018 11:22:04 -0400
> > From: Selva Nair <selva.nair@xxxxxxxxx
> <mailto:selva.nair@xxxxxxxxx> <mailto:selva.nair@xxxxxxxxx
> <mailto:selva.nair@xxxxxxxxx>>>
> > To: richard.oehlinger@xxxxxxxxxxxxxxx
> <mailto:richard.oehlinger@xxxxxxxxxxxxxxx>
> > <mailto:richard.oehlinger@xxxxxxxxxxxxxxx
> <mailto:richard.oehlinger@xxxxxxxxxxxxxxx>>,
> > openssl-users@xxxxxxxxxxx <mailto:openssl-users@xxxxxxxxxxx>
> <mailto:openssl-users@xxxxxxxxxxx <mailto:openssl-users@xxxxxxxxxxx>>
> > Subject: Re: CAPI-Engine doc
> > Message-ID:
> > ? ? ? ?
> >
> <CAKuzo_iqEBP-QG19Hsg5dFVoUG+2q-5O=vfg_NTzAJsQj+D3Jw@xxxxxxxxxxxxxx
> <mailto:vfg_NTzAJsQj%2BD3Jw@xxxxxxxxxxxxxx>
> > <mailto:vfg_NTzAJsQj%2BD3Jw@xxxxxxxxxxxxxx
> <mailto:vfg_NTzAJsQj%252BD3Jw@xxxxxxxxxxxxxx>>>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > On Tue, Oct 23, 2018 at 10:38 AM Richard Oehlinger via
> openssl-users
> > <openssl-users@xxxxxxxxxxx <mailto:openssl-users@xxxxxxxxxxx>
> <mailto:openssl-users@xxxxxxxxxxx
> <mailto:openssl-users@xxxxxxxxxxx>>> wrote:
> > >
> > > Hi!
> > >
> > > I'm trying to get a handle on the CAPI engine, because I need to
> > have a
> > > secure Keystore on Windows. Furthermore I need it to work
> with Qt's
> > > QSslKey, which fortunately can be constructed by EVP_PKEY *.
> > >
> > > So far so good. The key is found, but when I try to use it
> in a SSL
> > > connection i get following error:
> > >
> > > error:80070063:lib(128):CAPI_RSA_SIGN:cant create hash object,
> > > error:1409B006:SSL
> routines:ssl3_send_server_key_exchange:EVP lib
> >
> > Which version of OpenSSL?
> >
> > > Trace Output is:
> > >
> > > Setting debug file to
> C:\Users\user\AppData\Local\Temp\engine.txt
> > > Opening certificate store MY
> > > capi_get_key, contname={4EBA52A8-AB4B-47DB-B777-2B26351F324C},
> > > provname=Microsoft Enhanced Cryptographic Provider v1.0, type=1
> > > Called CAPI_rsa_sign()
> >
> > This CSP cannot do SHA2 hashes so won't work unless you restrict
> > signature algorithms or set TLS version to 1.1. I believe OpenSSL
> > 1.1.0 will try to load The ".. Enhanced RSA AES .. Provider" which
> > can handle SHA2 and may work. I say "may" because, if the key
> store is
> > a legacy hardware token, it also depends on signature algorithms
> > supported
> > by the token and may be necessary to downgrade to TLS 1.1.
> >
> > Selva
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Tue, 23 Oct 2018 15:37:24 +0000
> > From: Michael Wojcik <Michael.Wojcik@xxxxxxxxxxxxxx
> <mailto:Michael.Wojcik@xxxxxxxxxxxxxx>
> > <mailto:Michael.Wojcik@xxxxxxxxxxxxxx
> <mailto:Michael.Wojcik@xxxxxxxxxxxxxx>>>
> > To: "openssl-users@xxxxxxxxxxx
> <mailto:openssl-users@xxxxxxxxxxx> <mailto:openssl-users@xxxxxxxxxxx
> <mailto:openssl-users@xxxxxxxxxxx>>"
> > <openssl-users@xxxxxxxxxxx <mailto:openssl-users@xxxxxxxxxxx>
> <mailto:openssl-users@xxxxxxxxxxx <mailto:openssl-users@xxxxxxxxxxx>>>
> > Subject: Re: CAPI-Engine doc
> > Message-ID:
> > ? ? ? ?
> >
> <DM5PR18MB1324455050CC00BD3A2DD70FF9F50@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> <mailto:DM5PR18MB1324455050CC00BD3A2DD70FF9F50@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
> >
> <mailto:DM5PR18MB1324455050CC00BD3A2DD70FF9F50@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> <mailto:DM5PR18MB1324455050CC00BD3A2DD70FF9F50@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>>>
> >
> > Content-Type: text/plain; charset="Windows-1252"
> >
> > > From: openssl-users
> [mailto:openssl-users-bounces@xxxxxxxxxxx
> <mailto:openssl-users-bounces@xxxxxxxxxxx>
> > <mailto:openssl-users-bounces@xxxxxxxxxxx
> <mailto:openssl-users-bounces@xxxxxxxxxxx>>] On Behalf
> > > Of Richard Oehlinger via openssl-users
> > > Sent: Tuesday, October 23, 2018 10:38
> > >
> > > I'm trying to get a handle on the CAPI engine, because I need to
> > have a
> > > secure Keystore on Windows. Furthermore I need it to work
> with Qt's
> > > QSslKey, which fortunately can be constructed by EVP_PKEY *.
> >
> > What OpenSSL version are you using? Please remember to include
> this
> > informtion in every question. (And, normally, we'd ask for the
> > platform as well, but since CAPI is Windows-specific, we know that
> > in this case.)
> >
> > > So far so good. The key is found, but when I try to use it
> in a SSL
> > > connection i get following error:
> > >
> > > error:80070063:lib(128):CAPI_RSA_SIGN:cant create hash object,
> > > error:1409B006:SSL
> routines:ssl3_send_server_key_exchange:EVP lib
> > >
> > > I use a current Windows 10. Do I need to use a different
> Algorithm in
> > > order to work? Some googeling is indicating the provider
> might be
> > wrong.
> >
> > I haven't looked at the CAPI engine code since 1.0.1j. At that
> time,
> > I needed CAPI support and discovered there were various issues
> with
> > the extant CAPI code, so I forked and rewrote it. That was
> some time
> > back, obviously, and I'm afraid I never got around to pushing the
> > changes back to openssl.org <http://openssl.org>
> <http://openssl.org>. (In fact, it was
> > sufficiently long ago that I believe the organization was still
> > reluctant to take contributions from people in the US at the
> time.)
> >
> > The biggest issue was with provider handling. CAPI is
> something of a
> > braindead API in many ways - Microsoft's replacement, CNG, is
> > somewhat better - and the provider stuff is one of them. When
> a key
> > (including a "key" which is actually just a reference to a key
> > contained in an HSM) is imported into one of the Windows key
> stores,
> > it has to be associated with a provider, and that provider has to
> > accommodate that type and size of key; otherwise the key is
> > unusable. Then, when you try to use the key in CAPI, you have to
> > specify the same provider - CAPI isn't smart enough to figure
> it out
> > on its own.
> >
> > So my version of the CAPI engine has code to look up the key's
> > provider and silently correct the provider type information in the
> > engine's context structure if it's a mismatch.
> >
> > Beyond that, it appears that my changes included:
> >
> > - Support for building all the necessary functionality when using
> > Microsoft Windows SDK 6.0A, which was one of my requirements
> at the
> > time.
> >
> > - Supporting hashes other than SHA-1 for DSA. We have US Federal
> > customers who needed fairly comprehensive DSA support. For most
> > people this is likely a non-issue.
> >
> > - Forcing stack probes on for the callback functions, because my
> > engine was being built outside the OpenSSL build process, but
> needed
> > to match the calling convention of OpenSSL, which (at least in
> > 1.0.1j) included stack-probe support.
> >
> > - A fix suggested by Steven Henson years ago on the mailing
> list to
> > capi_get_key, but never (at least by 1.0.1j) picked up in the
> source
> > code: If CryptGetUserKey returns NTE_NO_KEY, xor keyspec with 3 to
> > flip the key type and try CryptGetUesrKey again.
> >
> > I think that's it, though it's possible I tweaked some other
> things
> > and didn't call them out in the comments.
> >
> > I suppose I should check what the CAPI engine source looks like in
> > 1.1.1, merge my changes in if feasible, and submit a PR. One of
> > these days...
> >
> > Really, though, what we need is a new engine written to use CNG
> > rather than CAPI. Though that would have the disadvantage of not
> > supporting ancient Windows OS and SDK versions which, while
> > unsupported by Microsoft, are still used in far too many places.
> >
> > --
> > Michael Wojcik
> > Distinguished Engineer, Micro Focus
> >
> >
> >
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Tue, 23 Oct 2018 15:37:25 +0000
> > From: Michael Wojcik <Michael.Wojcik@xxxxxxxxxxxxxx
> <mailto:Michael.Wojcik@xxxxxxxxxxxxxx>
> > <mailto:Michael.Wojcik@xxxxxxxxxxxxxx
> <mailto:Michael.Wojcik@xxxxxxxxxxxxxx>>>
> > To: "openssl-users@xxxxxxxxxxx
> <mailto:openssl-users@xxxxxxxxxxx> <mailto:openssl-users@xxxxxxxxxxx
> <mailto:openssl-users@xxxxxxxxxxx>>"
> > <openssl-users@xxxxxxxxxxx <mailto:openssl-users@xxxxxxxxxxx>
> <mailto:openssl-users@xxxxxxxxxxx <mailto:openssl-users@xxxxxxxxxxx>>>
> > Subject: Re: Reg issue in alert message
> > Message-ID:
> > ? ? ? ?
> >
> <DM5PR18MB13246F528FB866508D8E9267F9F50@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> <mailto:DM5PR18MB13246F528FB866508D8E9267F9F50@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
> >
> <mailto:DM5PR18MB13246F528FB866508D8E9267F9F50@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> <mailto:DM5PR18MB13246F528FB866508D8E9267F9F50@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>>>
> >
> > Content-Type: text/plain; charset="Windows-1252"
> >
> > > From: openssl-users
> [mailto:openssl-users-bounces@xxxxxxxxxxx
> <mailto:openssl-users-bounces@xxxxxxxxxxx>
> > <mailto:openssl-users-bounces@xxxxxxxxxxx
> <mailto:openssl-users-bounces@xxxxxxxxxxx>>] On Behalf
> > > Of Viktor Dukhovni
> > > Sent: Tuesday, October 23, 2018 10:02
> > >
> > > On Tue, Oct 23, 2018 at 01:29:27PM +0100, Matt Caswell wrote:
> > >
> > > > > So, I think client have set TLS_FALLBACK_SCSV in cipher
> suite
> > list in
> > > > > client hello.
> > > >
> > > > This suggests there is a bug in the client application.
> This can
> > only
> > > > happen if the client application calls SSL_CTX_set_mode() or
> > > > SSL_set_mode() to set the SSL_MODE_SEND_FALLBACK_SCSV mode.
> > >
> > > I have a somewhat plausible, if dicey hunch:
> > >
> > >? ? ?Perhaps some application developers got confused between
> > >? ? ?the similar functions SSL_CTX_set_session_cache_mode(3)
> > >? ? ?and SSL_CTX_set_mode(3) and called the wrong one?
> >
> > Certainly possible, but I wouldn't discount the possibility that
> > someone simply thought setting SSL_MODE_SEND_FALLBACK_SCSV was the
> > Right Thing. There was a fair bit of confusion around the Fallback
> > SCSV when it first appeared (we had questions from customers that
> > indicated they didn't understand it, and I had to read the ID to
> > make sure I did). And, of course, TLS is mightly confusing in
> general.
> >
> > It is interesting to note that those two options happen to
> have the
> > same value, though, particularly given the similarity of the two
> > function names.
> >
> > This is one of those cases where C's weak type system is a
> problem.
> > Though it would be nice if OpenSSL used enums rather than
> macros for
> > these things.
> >
> > --
> > Michael Wojcik
> > Distinguished Engineer, Micro Focus
> >
> >
> >
> >
> >
> > ------------------------------
> >
> > Message: 4
> > Date: Tue, 23 Oct 2018 17:42:56 +0200
> > From: Jakob Bohm <jb-openssl@xxxxxxxxxx
> <mailto:jb-openssl@xxxxxxxxxx> <mailto:jb-openssl@xxxxxxxxxx
> <mailto:jb-openssl@xxxxxxxxxx>>>
> > To: openssl-users@xxxxxxxxxxx
> <mailto:openssl-users@xxxxxxxxxxx> <mailto:openssl-users@xxxxxxxxxxx
> <mailto:openssl-users@xxxxxxxxxxx>>
> > Subject: Re: CAPI-Engine doc
> > Message-ID: <fc161e84-bf5f-f61b-0f1d-3bfa5641edd8@xxxxxxxxxx
> <mailto:fc161e84-bf5f-f61b-0f1d-3bfa5641edd8@xxxxxxxxxx>
> > <mailto:fc161e84-bf5f-f61b-0f1d-3bfa5641edd8@xxxxxxxxxx
> <mailto:fc161e84-bf5f-f61b-0f1d-3bfa5641edd8@xxxxxxxxxx>>>
> > Content-Type: text/plain; charset=utf-8; format=flowed
> >
> > On 23/10/2018 17:22, Selva Nair wrote:
> > > On Tue, Oct 23, 2018 at 10:38 AM Richard Oehlinger via
> openssl-users
> > > <openssl-users@xxxxxxxxxxx
> <mailto:openssl-users@xxxxxxxxxxx> <mailto:openssl-users@xxxxxxxxxxx
> <mailto:openssl-users@xxxxxxxxxxx>>> wrote:
> > >> Hi!
> > >>
> > >> I'm trying to get a handle on the CAPI engine, because I
> need to
> > have a
> > >> secure Keystore on Windows. Furthermore I need it to work
> with Qt's
> > >> QSslKey, which fortunately can be constructed by EVP_PKEY *.
> > >>
> > >> So far so good. The key is found, but when I try to use it
> in a SSL
> > >> connection i get following error:
> > >>
> > >> error:80070063:lib(128):CAPI_RSA_SIGN:cant create hash object,
> > >> error:1409B006:SSL
> routines:ssl3_send_server_key_exchange:EVP lib
> > > Which version of OpenSSL?
> > >
> > >> Trace Output is:
> > >>
> > >> Setting debug file to
> C:\Users\user\AppData\Local\Temp\engine.txt
> > >> Opening certificate store MY
> > >> capi_get_key, contname={4EBA52A8-AB4B-47DB-B777-2B26351F324C},
> > >> provname=Microsoft Enhanced Cryptographic Provider v1.0, type=1
> > >> Called CAPI_rsa_sign()
> > > This CSP cannot do SHA2 hashes so won't work unless you restrict
> > > signature algorithms or set TLS version to 1.1. I believe
> OpenSSL
> > > 1.1.0 will try to load The ".. Enhanced RSA AES .. Provider"
> which
> > > can handle SHA2 and may work. I say "may" because, if the
> key store is
> > > a legacy hardware token, it also depends on signature algorithms
> > supported
> > > by the token and may be necessary to downgrade to TLS 1.1.
> > >
> > The above limitations are less severe in CNG ("CryptoAPI Next
> > Generation")
> > on Windows 6.00 and later, where the old API and CSP names are
> actually
> > emulations on top of a new structure with much smaller "KSP"
> providers.
> > At the same time, the CNG emulation of the classic CryptoAPI
> functions
> > are limited to what was available in Windows 5.01 SP2 and 5.02
> SP2, thus
> > much of the SHA-2 functionality is available only by calling
> the CNG
> > APIs directly on Windows >= 6.00, but the older APIs with a
> reference
> > to newer enum values introduced in Windows 5.01 SP3 or 5.02
> SP2+Hotfix.
> >
> > Put another way, Microsoft forked their crypto source tree
> sometime in
> > 2004 or 2005, and anything added later was implemented
> differently in
> > the 5.0x and 6.0x code bases.
> >
> > Enjoy
> >
> > Jakob
> > --
> > Jakob Bohm, CIO, Partner, WiseMo A/S.? https://www.wisemo.com
> > Transformervej 29, 2860 S?borg, Denmark.? Direct +45 31 13 16 10
> > This public discussion message is non-binding and may contain
> errors.
> > WiseMo - Remote Service Management for PCs, Phones and Embedded
> >
> >
> >
> > ------------------------------
> >
> > Message: 5
> > Date: Tue, 23 Oct 2018 23:16:13 -0700 (MST)
> > From: sakdev <best.sakthi3@xxxxxxxxx
> <mailto:best.sakthi3@xxxxxxxxx> <mailto:best.sakthi3@xxxxxxxxx
> <mailto:best.sakthi3@xxxxxxxxx>>>
> > To: openssl-users@xxxxxxxxxxx
> <mailto:openssl-users@xxxxxxxxxxx> <mailto:openssl-users@xxxxxxxxxxx
> <mailto:openssl-users@xxxxxxxxxxx>>
> > Subject: Re: Openssl Build Error- module
> unsafe for
> > ? ? ? ? SAFESEH image/Unable to generate SAFESEH image
> > Message-ID: <1540361773425-0.post@xxxxxxxxxxxxx
> <mailto:1540361773425-0.post@xxxxxxxxxxxxx>
> > <mailto:1540361773425-0.post@xxxxxxxxxxxxx
> <mailto:1540361773425-0.post@xxxxxxxxxxxxx>>>
> > Content-Type: text/plain; charset=us-ascii
> >
> > Added "/safeseh" in assembler flags and problem got solved. Thank
> > you very
> > much.
> >
> >
> >
> > --
> > Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
> >
> >
> > ------------------------------
> >
> > Subject: Digest Footer
> >
> > _______________________________________________
> > openssl-users mailing list
> > openssl-users@xxxxxxxxxxx <mailto:openssl-users@xxxxxxxxxxx>
> <mailto:openssl-users@xxxxxxxxxxx <mailto:openssl-users@xxxxxxxxxxx>>
> > https://mta.openssl.org/mailman/listinfo/openssl-users
> >
> >
> > ------------------------------
> >
> > End of openssl-users Digest, Vol 47, Issue 45
> > *********************************************
> >
> >
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 24 Oct 2018 23:55:23 +0900
> From: Akira Takahashi <takahashi.akira.58s@xxxxxxxxxx
> <mailto:takahashi.akira.58s@xxxxxxxxxx>>
> To: openssl-users@xxxxxxxxxxx <mailto:openssl-users@xxxxxxxxxxx>
> Subject: Using SM2 ECIES in 1.1.1
> Message-ID: <f4163a25-e9b6-f60b-b3ea-8aadf2c190fe@xxxxxxxxxx
> <mailto:f4163a25-e9b6-f60b-b3ea-8aadf2c190fe@xxxxxxxxxx>>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi all,
>
>
> Since the version 1.1.1 supports the SM2 public key cryptography
> suite I am
> trying to test its ECIES (found in crypto/sm2/sm2_crypto.c) over
> different
> standardized prime curves i.e. not just sm2p256v1.
>
> Is there CLI or minimal code snippet to achieve it via the EVP
> interface?
>
> The current man page of SM2 seems to only describe SM2 as a
> signature algorithm,
> but not as a public key encryption.
>
>
> Thank you in advance for your help!
>
> Akira
>
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 24 Oct 2018 16:14:47 +0100
> From: Matt Caswell <matt@xxxxxxxxxxx <mailto:matt@xxxxxxxxxxx>>
> To: openssl-users@xxxxxxxxxxx <mailto:openssl-users@xxxxxxxxxxx>
> Subject: Re: Using SM2 ECIES in 1.1.1
> Message-ID: <92097423-88c0-5a7d-9395-a84195b257d6@xxxxxxxxxxx
> <mailto:92097423-88c0-5a7d-9395-a84195b257d6@xxxxxxxxxxx>>
> Content-Type: text/plain; charset=utf-8
>
>
>
> On 24/10/2018 15:55, Akira Takahashi wrote:
> > Hi all,
> >
> >
> > Since the version 1.1.1 supports the SM2 public key cryptography
> suite I
> > am trying to test its ECIES (found in crypto/sm2/sm2_crypto.c) over
> > different standardized prime curves i.e. not just sm2p256v1.
> >
> > Is there CLI or minimal code snippet to achieve it via the EVP
> interface?
> >
> > The current man page of SM2 seems to only describe SM2 as a signature
> > algorithm, but not as a public key encryption.
>
> You can use the EVP_PKEY_encrypt() function for this purpose.
>
> A generic example (not SM2 specific) is on the EVP_PKEY_encrypt()
> man page:
>
> https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_encrypt.html
>
> Doing this for SM2 is essentially the same as shown in that example
> except of course don't call the RSA specific
> EVP_PKEY_CTX_set_rsa_padding() function.
>
> Setting up of the EVP_PKEY itself to contain an SM2 key is the same as
> for sign/verify, i.e. you need to call EVP_PKEY_set_alias_type(). There
> is no need to set an id though. See:
>
> https://www.openssl.org/docs/man1.1.1/man7/SM2.html
>
> Hope that helps,
>
> Matt
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 24 Oct 2018 21:42:49 +0500
> From: ???? ????????? <socketpair@xxxxxxxxx
> <mailto:socketpair@xxxxxxxxx>>
> To: openssl-users@xxxxxxxxxxx <mailto:openssl-users@xxxxxxxxxxx>
> Subject: openssl cms encrypt recipientInfo [questions
> for openssl developers].
> Message-ID:
>
> <CAEmTpZF9hUxy6fQyX+ZNgs-HBJiw6nxGVanXXix-vA8D8HgLXg@xxxxxxxxxxxxxx
> <mailto:CAEmTpZF9hUxy6fQyX%2BZNgs-HBJiw6nxGVanXXix-vA8D8HgLXg@xxxxxxxxxxxxxx>>
> Content-Type: text/plain; charset="UTF-8"
>
> Here is a dump of my CMS encrypted message.
>
> ===================
> CMS_ContentInfo:.
> contentType: pkcs7-envelopedData (1.2.840.113549.1.7.3)
> d.envelopedData:.
> version: 2
> originatorInfo: <ABSENT>
> recipientInfos:
> d.kari:.
> version: 3
> d.originatorKey:.
> algorithm:.
> algorithm: id-ecPublicKey (1.2.840.10045.2.1)
> parameter: <ABSENT>
> publicKey: (0 unused bits)
> 0000 - 04 89 ee 81 d8 05 30 2d-4e 3a a3 33 dd 8b
> ......0-N:.3..
> 000e - c5 7d 56 79 02 2b 16 7a-f5 4c 20 3f 18 ed
> .}Vy.+.z.L ?..
> 001c - 92 ba 81 98 88 f8 7a 6c-41 ba 8e bb c0 a5
> ......zlA.....
> 002a - 41 c4 2a fe 36 31 5c f3-92 9c b5 ad 79 a9
> A.*.61\.....y.
> 0038 - 9c 4c 75 69 23 9d a1 5b-ef .Lui#..[.
> ukm: <ABSENT>
> keyEncryptionAlgorithm:.
> algorithm: dhSinglePass-stdDH-sha256kdf-scheme
> (1.3.132.1.11.1)
> parameter: SEQUENCE:
> recipientEncryptedKeys:
> d.rKeyId:.
> subjectKeyIdentifier:.
> 0000 - 82 46 4f ae b4 cb 84 7b-f4 70 68 6f d0
> .FO....{.pho.
> 000d - 24 e7 15 8c 34 f3 c4 $...4..
> date: <ABSENT>
> other: <ABSENT>
> encryptedKey:.
> 0000 - f9 b1 b1 28 2a 0c ea e5-eb 3b 0f 22 a5 f4
> ...(*....;."..
> 000e - 51 8e 22 a3 76 4f fe 01-6f 26 37 b5 24 1c
> Q.".vO..o&7.$.
> 001c - 20 ba 9f 1a 11 92 25 a5-e4 4e 79 6f
> .....%..Nyo
> encryptedContentInfo:.
> contentType: pkcs7-data (1.2.840.113549.1.7.1)
> contentEncryptionAlgorithm:.
> algorithm: aes-256-cbc (2.16.840.1.101.3.4.1.42)
> parameter: OCTET STRING:
> 0000 - c4 12 53 6c 1f 04 ee 3a-2f 19 43 6f 87 0c af
> ..Sl...:/.Co...
> 000f - 9b .
> encryptedContent:.
> 0000 - 9f 18 ea 29 08 26 f5 8c-7c 69 ae 23 f2 ca 95
> ...).&..|i.#...
> 000f - 76 v
> unprotectedAttrs:
> <EMPTY>
> ========
>
> As you can see it has reference to one recipient, identified by his
> subjectKeyIdentifier. By some reason
> RecipientInfos/d.kari/d.originatorKey also includes full public key
> from recipient's certificate. Questions:
>
> 1. Why is it required?
> 2. Is it possible to omit it since it is superfluous (IMHO) ?
> 3.
> https://github.com/openssl/openssl/blob/master/crypto/cms/cms_kari.c#L386
> (and RFC) say that there could be either key, subjectandserial or
> subjectkeyidentifier. So, how to set it using command line openssl
> application ?
>
> --
> Segmentation fault
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> openssl-users mailing list
> openssl-users@xxxxxxxxxxx <mailto:openssl-users@xxxxxxxxxxx>
> https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
> ------------------------------
>
> End of openssl-users Digest, Vol 47, Issue 47
> *********************************************
>
>
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
