Re: [openssl-users] Unable to decrypt CMS object encrypted with EC prime256v1 certificate
On Wed, Jul 06, 2016, Stephan M?hlstrasser wrote:
> Am 06.07.16 um 05:15 schrieb Dr. Stephen Henson:
> >...
> >>Is the CMS object broken, or is this a problem in OpenSSL?
> >>
> >
> >Well the OpenSSL version does interop OK with the Bouncy Castle version of
> >ECDH and CMS. I've checked through your test message and the problem is that
> >the AES unwrapping algorithm checks fail meaning it can't proceed any
> >further.
> >That could be down to a CMS problem, an ECDH issue or a problem with the wrap
> >algorithm either in the version you are testing or OpenSSL.
> >
> >Is it possible to get any debugging information from the other version you
> >are
> >using: for example the content encryption key it is expecting or the ECDH
> >shared secret?
>
> I don't know whether that is possible, I will check.
>
> >Have you tried generating an message with OpenSSL and decrypting it with the
> >other version?
>
> Yes, the other version cannot decrypt the CMS object generated by
> OpenSSL. I did some tests with Bouncy Castle, and it also cannot
> decrypt the CMS object.
>
> What might be interesting is that on the other hand Windows
> CryptoAPI is able to decrypt the CMS object (tested on Windows 10).
>
Just to clarify: you're saying that neither this third party version nor
BouncyCastler can decrypt the OpenSSL generated CMS objects?
> While doing research on this, we found one thing that looks
> suspicious in the CMS objects generated by OpenSSL 1.0.2. When
> dumping the CMS object with dumpasn1, the key wrap algorithm is
> encoded as follows:
>
> SEQUENCE {
> OBJECT IDENTIFIER '1 3 132 1 11 3'
> SEQUENCE {
>OBJECT IDENTIFIER aes256-wrap (2 16 840 1 101 3 4 1 45)
>NULL
>}
> }
>
> Note the NULL parameter in the aes256-wrap algorithm identifier.
> Compare that to RFC 3565, "2.3.2. AES CEK Wrap Process":
>
> https://tools.ietf.org/html/rfc3565#section-2.3.2
>
> "In all cases the parameters field MUST be absent."
>
> Does this refer to the parameters field of the AlgorithmIdentifier
> of the AES key wrap algorithm? Then it would be incorrect to include
> the NULL here.
>
I'll check. That looks like a bug as the code should be excluding the NULL.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How to turn on certain elements in CMS objects
On Wed, Jul 06, 2016, Stephan M?hlstrasser wrote: > So do I understand it correctly that OpenSSL currentls only supports > RFC3278? Does that mean that it can't process CMS enveloped data > objects that are created according to RFC5753? > OpenSSL should be able to decrypt either RFC3278 or RFC5753 forms. > In my other thread titled "Unable to decrypt CMS object encrypted > with EC prime256v1 certificate" the CMS object that cannot be > decrypted with OpenSSL does contain the EC parameters. Can that be > related to the problem? > It shouldn't affect OpenSSL's ability to decrypt the object as that information is not used anywhere in the key derivation. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Error building 1.0.1t with no-srp
I'm building 1.0.1t with the no-srp option.When I do, I get thefollowing error making all in ssl... make[1]: Entering directory `/users/scottn/openssl-1.0.1t/ssl' make[1]: *** No rule to make target `../include/openssl/srp.h', needed by `tls_srp.o'. Stop. Anyone else build without SRP? Anyone have suggestions? --- Scott Neugroschl | XYPRO Technology Corporation 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 | -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Unable to decrypt CMS object encrypted with EC prime256v1 certificate
Am 06.07.16 um 05:15 schrieb Dr. Stephen Henson:
...
Is the CMS object broken, or is this a problem in OpenSSL?
Well the OpenSSL version does interop OK with the Bouncy Castle version of
ECDH and CMS. I've checked through your test message and the problem is that
the AES unwrapping algorithm checks fail meaning it can't proceed any further.
That could be down to a CMS problem, an ECDH issue or a problem with the wrap
algorithm either in the version you are testing or OpenSSL.
Is it possible to get any debugging information from the other version you are
using: for example the content encryption key it is expecting or the ECDH
shared secret?
I don't know whether that is possible, I will check.
Have you tried generating an message with OpenSSL and decrypting it with the
other version?
Yes, the other version cannot decrypt the CMS object generated by
OpenSSL. I did some tests with Bouncy Castle, and it also cannot decrypt
the CMS object.
What might be interesting is that on the other hand Windows CryptoAPI is
able to decrypt the CMS object (tested on Windows 10).
While doing research on this, we found one thing that looks suspicious
in the CMS objects generated by OpenSSL 1.0.2. When dumping the CMS
object with dumpasn1, the key wrap algorithm is encoded as follows:
SEQUENCE {
OBJECT IDENTIFIER '1 3 132 1 11 3'
SEQUENCE {
OBJECT IDENTIFIER aes256-wrap (2 16 840 1 101 3 4 1 45)
NULL
}
}
Note the NULL parameter in the aes256-wrap algorithm identifier. Compare
that to RFC 3565, "2.3.2. AES CEK Wrap Process":
https://tools.ietf.org/html/rfc3565#section-2.3.2
"In all cases the parameters field MUST be absent."
Does this refer to the parameters field of the AlgorithmIdentifier of
the AES key wrap algorithm? Then it would be incorrect to include the
NULL here.
--
Stephan
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Call rsa_mod_exp for more than one exponentiation
Hi. Is it possible to call the rsa_mod_exp method in RSA_METHOD structure for more than one exponentiation? E.g.: openssl `speed rsa -engine my_engine` will call rsa_mod_exp for every single rsa sign/verify operation, but I want to queue, let's say 10 of these operations and process them in a single rsa_mod_exp call. I want to do this because the RSA ENGINE is using GPU based implementations which are faster the CPU (default) based implementations when executes multiple operations in parallel. Best regards, Dani Grosu -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How to turn on certain elements in CMS objects
Am 06.07.16 um 15:46 schrieb Dr. Stephen Henson:
...
Second the following:
129 10: [1] {
1318: OCTET STRING B1 04 4A FD FC 8B 70 6D
: }
If I match this correctly to RFC 5652, this is
ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL
inside the KeyAgreeRecipientInfo SEQUENCE (see
https://tools.ietf.org/html/rfc5652#section-6.2.2).
Can OpenSSL emit this optional element?
Yes but not using the command line utility. It would require a custom program
to set the parameter using the CMS API.
Could you pleaee briefly explain how set the parameter? I could not find
anything in the documentation of the CMS API about this.
What is the purpose of the "ukm" field?
It provides some additional optional random data used in the key encryption
key derivation algorithm.
Note that you can get a diagnistic dump using:
openssl cms -cmsout -inform DER -print -in cmd.der
I wasn't aware of this feature, that looks very useful, thanks!
--
Stephan
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How to turn on certain elements in CMS objects
Am 06.07.16 um 16:02 schrieb Dr. Stephen Henson:
On Wed, Jul 06, 2016, Dr. Stephen Henson wrote:
On Fri, Jul 01, 2016, Stephan M?hlstrasser wrote:
First the AlgorithmIdentifier includes the EC curve name:
40 19: SEQUENCE {
427: OBJECT IDENTIFIER ecPublicKey (1 2 840
10045 2 1)
518: OBJECT IDENTIFIER ansiX9p256r1 (1 2 840
10045 3 1 7)
: }
In CMS objects created with OpenSSL with the same recipient
certificate, the curve name is always omitted. Is it possible to
make OpenSSL emit the curve name as well?
No as this is a violation of the standards. From RFC3278:
originator MUST be the alternative originatorKey. The
originatorKey algorithm field MUST contain the id-ecPublicKey
object identifier (see Section 8.1) with NULL parameters. The
originatorKey publicKey field MUST contain the DER-encoding of a
value of the ASN.1 type ECPoint (see Section 8.2), which
represents the sending agent's ephemeral EC public key.
Correction... that is not allowed by RFC3278 but is allowed in RFC5753 but
OpenSSL doesn't currently generate that format. It's not clear what purpose it
serves as the EC parameters are specified in the recipient's key and
certificate anyway.
So do I understand it correctly that OpenSSL currentls only supports
RFC3278? Does that mean that it can't process CMS enveloped data objects
that are created according to RFC5753?
In my other thread titled "Unable to decrypt CMS object encrypted with
EC prime256v1 certificate" the CMS object that cannot be decrypted with
OpenSSL does contain the EC parameters. Can that be related to the problem?
--
Stephan
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How to turn on certain elements in CMS objects
On Wed, Jul 06, 2016, Dr. Stephen Henson wrote:
> On Fri, Jul 01, 2016, Stephan M?hlstrasser wrote:
>
> >
> > First the AlgorithmIdentifier includes the EC curve name:
> >
> > 40 19: SEQUENCE {
> > 427: OBJECT IDENTIFIER ecPublicKey (1 2 840
> > 10045 2 1)
> > 518: OBJECT IDENTIFIER ansiX9p256r1 (1 2 840
> > 10045 3 1 7)
> > : }
> >
> > In CMS objects created with OpenSSL with the same recipient
> > certificate, the curve name is always omitted. Is it possible to
> > make OpenSSL emit the curve name as well?
> >
>
> No as this is a violation of the standards. From RFC3278:
>
> originator MUST be the alternative originatorKey. The
> originatorKey algorithm field MUST contain the id-ecPublicKey
> object identifier (see Section 8.1) with NULL parameters. The
> originatorKey publicKey field MUST contain the DER-encoding of a
> value of the ASN.1 type ECPoint (see Section 8.2), which
> represents the sending agent's ephemeral EC public key.
>
Correction... that is not allowed by RFC3278 but is allowed in RFC5753 but
OpenSSL doesn't currently generate that format. It's not clear what purpose it
serves as the EC parameters are specified in the recipient's key and
certificate anyway.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How to turn on certain elements in CMS objects
On Fri, Jul 01, 2016, Stephan M?hlstrasser wrote:
> Hi,
>
> this message is related to another question that I sent with subject
> "Unable to decrypt CMS object encrypted with EC prime256v1
> certificate".
>
> Below I have included the full ASN.1 dump of the CMS object
> generated by a third-party application.
>
> The CMS object has two properties that I so far was not able to
> reproduce when creating CMS objects with OpenSSL:
>
> First the AlgorithmIdentifier includes the EC curve name:
>
> 40 19: SEQUENCE {
> 427: OBJECT IDENTIFIER ecPublicKey (1 2 840
> 10045 2 1)
> 518: OBJECT IDENTIFIER ansiX9p256r1 (1 2 840
> 10045 3 1 7)
> : }
>
> In CMS objects created with OpenSSL with the same recipient
> certificate, the curve name is always omitted. Is it possible to
> make OpenSSL emit the curve name as well?
>
No as this is a violation of the standards. From RFC3278:
originator MUST be the alternative originatorKey. The
originatorKey algorithm field MUST contain the id-ecPublicKey
object identifier (see Section 8.1) with NULL parameters. The
originatorKey publicKey field MUST contain the DER-encoding of a
value of the ASN.1 type ECPoint (see Section 8.2), which
represents the sending agent's ephemeral EC public key.
> Second the following:
>
> 129 10: [1] {
> 1318: OCTET STRING B1 04 4A FD FC 8B 70 6D
> : }
>
> If I match this correctly to RFC 5652, this is
>
> ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL
>
> inside the KeyAgreeRecipientInfo SEQUENCE (see
> https://tools.ietf.org/html/rfc5652#section-6.2.2).
>
> Can OpenSSL emit this optional element?
Yes but not using the command line utility. It would require a custom program
to set the parameter using the CMS API.
> What is the purpose of the "ukm" field?
>
It provides some additional optional random data used in the key encryption
key derivation algorithm.
Note that you can get a diagnistic dump using:
openssl cms -cmsout -inform DER -print -in cmd.der
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Dynamically loading OpenSSL on Windows
On 06.07.2016 09:37, Stuart Douglas wrote: > Hi everyone, > > I am trying to implement a generic Java SSLContext that is backed by > OpenSSL that uses dynamic loading to link to OpenSSL. > > This works well on Linux, however I am running into "no > OPENSSL_Applink" issues on Windows. According to the FAQ all that > should be required is including openssl\applink.c, however this will > not work in my case as the main process is the java executable, and > not my glue library, so the uplink function is not finding it. > > Is there any way I can get this working? I have had a quick look at > the uplink code and as far as I can tell I am out of luck, but I am > hoping I have missed something. > > Stuart > If you take a look at the OPENSSL_Uplink() function (ms/uplink.c), you will see that the code gets the applink function pointer via apphandle = GetModuleHandle(NULL); applink = GetProcAddress(apphandle, "OPENSSL_Applink") i.e., OpenSSL expects the OPENSSL_Applink() function to be "DLL-exported" from the executable itself, see [1]. (If this sounds weird to you, don't worry, you're not alone ;-) In my opinion this is a design flaw which makes it almost impossible to have a wrapper dll around the OpenSSL library, since you always have to modify the excutable to be able to link. The back links are necessary, but the way they are obtained is bad design. The best solution for this would be to have an OpenSSL API call such as OPENSSL_register_applink(), which could be used by an executable or a shared library likewise. The only problem I see is to add the new api and stay compatible to the old hacky way. Maybe you should open a ticket on the rt for this. Regards, Matthias [1] MSDN - GetModuleHandle https://msdn.microsoft.com/en-us/library/windows/desktop/ms683199(v=vs.85).aspx -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Dynamically loading OpenSSL on Windows
Hi everyone, I am trying to implement a generic Java SSLContext that is backed by OpenSSL that uses dynamic loading to link to OpenSSL. This works well on Linux, however I am running into "no OPENSSL_Applink" issues on Windows. According to the FAQ all that should be required is including openssl\applink.c, however this will not work in my case as the main process is the java executable, and not my glue library, so the uplink function is not finding it. Is there any way I can get this working? I have had a quick look at the uplink code and as far as I can tell I am out of luck, but I am hoping I have missed something. Stuart -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
