Re: ECDSA - OpenSSL Implementation using the modulus (N) instead of field size (q)?
Thanks Guys, At the moment I'm trying to distinguish if n p, as the x co-ordinate does not wrap around n (so x = r in all cases) - to verify if this is always the case Sent from my iPad On 20 Dec 2013, at 04:16, Billy Brumley bbrum...@gmail.com wrote: ... yet it seems you are free to use it as you please (like the rest of the library does) internally, so it depends on what you are doing. (Modifying the library or creating an application -- since you posted code snippets I assumed the former, Matt points out the proper way externally.) BBB On Fri, Dec 20, 2013 at 12:44 AM, Matt Caswell fr...@baggins.org wrote: On 19 December 2013 18:52, Billy Brumley bbrum...@gmail.com wrote: It's in the EC_GROUP structure: group-field. Check crypto/ec/ec_lcl.h. BBB Anything in the *lcl.h header files does not form part of the public API and you shouldn't really rely on it as it may change. Better is to use: int EC_GROUP_get_curve_GFp(const EC_GROUP *group, BIGNUM *p, BIGNUM *a, BIGNUM *b, BN_CTX *ctx); or int EC_GROUP_get_curve_GF2m(const EC_GROUP *group, BIGNUM *p, BIGNUM *a, BIGNUM *b, BN_CTX *ctx); as appropriate dependent on the type of curve that you have. On Thu, Dec 19, 2013 at 9:54 AM, Patrick McCorry stonecold...@gmail.com wrote: From what I can see in the implementation (ecs_ossl.c) when using ecdsa_sign_setup - the 'q' field size is never used! /* * Does the multiplciation of G (generator) * k to produce curve point (x,y) */ EC_POINT_mul(group, temp_point, k, NULL, NULL, ctx) What you call 'q' (called 'p' within openssl) is used in this operation. It is a parameter of the group and is required to do the point multiplication. Matt __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: ECDSA - OpenSSL Implementation using the modulus (N) instead of field size (q)?
On 20 December 2013 09:09, Patrick McCorry stonecold...@gmail.com wrote: Thanks Guys, At the moment I'm trying to distinguish if n p, as the x co-ordinate does not wrap around n (so x = r in all cases) - to verify if this is always the case n can be greater than p, e.g. see the definition of secp112r1 in http://www.secg.org/collateral/sec2_final.pdf: p = DB7C 2ABF62E3 5E668076 BEAD208B n = DB7C 2ABF62E3 5E7628DF AC6561C5 Or n can be less than p, e.g. see the definition of secp112r2 p = DB7C 2ABF62E3 5E668076 BEAD208B n = 36DF 0AAFD8B8 D7597CA1 0520D04B Matt __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
compile errors
First time trying to retro-fit an app with SSL so could use some help... Compiling on Scientific Linux 6.4 openssl-devel 1.0.1e-15.el6_5.x86-64 #include openssl/ssl.h gcc -lssl -lcrypto-pipe -Wall -Wno-unused-parameter -ggdb3 -fPIC -fno-strict-aliasing -rdynamic -I/opt/apps/include -D__USE_FILE_OFFSET64 -c net.c -o net.o In file included from /usr/include/openssl/x509_vfy.h:70, from /usr/include/openssl/x509.h:600, from /usr/include/openssl/ssl.h:156, from net.c:11: /usr/include/openssl/lhash.h:143: error: expected ')' before '-' token /usr/include/openssl/lhash.h:144: error: expected ';' before 'unsigned' In file included from /usr/include/openssl/dtls1.h:64, from /usr/include/openssl/ssl.h:1320, from net.c:11: /usr/include/openssl/pqueue.h:82: error: conflicting types for 'pqueue_free' /apps/IPsoft/IPmon/include/lib/pqueue.h:97: note: previous declaration of 'pqueue_free' was here /usr/include/openssl/pqueue.h:84: error: conflicting types for 'pqueue_insert' /apps/IPsoft/IPmon/include/lib/pqueue.h:113: note: previous declaration of 'pqueue_insert' was here /usr/include/openssl/pqueue.h:85: error: conflicting types for 'pqueue_peek' /apps/IPsoft/IPmon/include/lib/pqueue.h:150: note: previous declaration of 'pqueue_peek' was here /usr/include/openssl/pqueue.h:86: error: conflicting types for 'pqueue_pop' /apps/IPsoft/IPmon/include/lib/pqueue.h:133: note: previous declaration of 'pqueue_pop' was here /usr/include/openssl/pqueue.h:91: error: conflicting types for 'pqueue_print' /apps/IPsoft/IPmon/include/lib/pqueue.h:162: note: previous declaration of 'pqueue_print' was here /usr/include/openssl/pqueue.h:92: error: conflicting types for 'pqueue_size' /apps/IPsoft/IPmon/include/lib/pqueue.h:104: note: previous declaration of 'pqueue_size' was here make: *** [net.o] Error 1 Other ssl apps seem to compile ok, so guessing I’ve missed something….any ideas why this blows up? Thanks! Dan
RE: OpenSSL 1.0.1e - OpenJDK/NSS interoperability issue?
Florian: It would be great to have a self-contained reproducer, so that we can test this before we enable the NSS-backed crypto provider in OpenJDK again. Can you use official channels for this? I can provide you with the x86_64 openssl 1.0.2 utility I built yesterday as the client plus an RPM that is our customized Tomcat as the server, this is sufficient to reproduce the issue. Together they're about 8 Mb, I think that's small enough to get through our email system as attachments in separate emails if necessary. Let me know off-list if you want me to send these to you. -Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
FIPS Capable Library, 2D09F086 error, 1409B004 error, and SSL3_SEND_SERVER_KEY_EXCHANGE failure?
I'm testing the FIPS Capable OpenSSL library with nginx. nginx start a master process which calls: SSL_library_init(); SSL_load_error_strings(); OpenSSL_add_all_algorithms(); The master then starts a number of child processes. It does so by forking without an exec (if I am reading the source code properly). The master process does *not* install OpenSSL static locks, but nginx not multi-threaded. When operating in non-FIPS mode, SSL/TLS connections proceed as expected when connecting to https://localhost during testing (but testing is very limited, and I have not load tested with a tool like Apache's 'ab' ). When operating in FIPS mode, the following occurs during a connection to https://localhost: nginx log 2013/12/20 13:57:13 [crit] 8123#0: *1 SSL_do_handshake() failed (SSL: error:2D09F086:FIPS routines:FIPS_digestupdate:selftest failed error:2D09F086:FIPS routines:FIPS_digestupdate:selftest failed error:2D09F086:FIPS routines:FIPS_digestupdate:selftest failed error:2D09F086:FIPS routines:FIPS_digestupdate:selftest failed error:2D09F086:FIPS routines:FIPS_digestupdate:selftest failed error:2D09E086:FIPS routines:FIPS_digestfinal:selftest failed error:2D09F086:FIPS routines:FIPS_digestupdate:selftest failed error:2D09F086:FIPS routines:FIPS_digestupdate:selftest failed error:2D09F086:FIPS routines:FIPS_digestupdate:selftest failed error:2D09E086:FIPS routines:FIPS_digestfinal:selftest failed error:04075083:rsa routines:RSA_sign:invalid message length error:1409B004:SSL routines:SSL3_SEND_SERVER_KEY_EXCHANGE:RSA lib) while SSL handshaking, client: 127.0.0.1, server: 0.0.0.0:443 /nginx log SSL3_SEND_SERVER_KEY_EXCHANGE is a puzzling failure since it appears to be DTLS related. I'm begin to wonder if the forks are causing trouble for OpenSSL when operating in FIPS mode. Does anyone have any ideas for troubleshooting the issue? Thanks in advance. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Upgrade Breakage of Perl Script: RH recent
I don’t use Fedora and track its versions, but assuming those are recent
RedHat including Fedora recently enabled ECC in its openssl packages
after years of excluding it over concerns about Certicom’s patent.
That increases the number of cipher suites in the Client Hello message
and also adds two extensions (although fairly small for RH) which makes
the Hello message bigger, and some servers are known to hang or otherwise
fail when the Hello message is bigger than used to be “normal” a decade ago.
Apparently api.tab.com.au:443 is such; tested with s_client 255 hangs.
(In a 404 it claims to be “WebLogic Server”, which I don’t know about.)
I also observe this server does not implement 5746 (secure renegotiation)
and will negotiate only TLSv1(.0) and 4 akRSA suites (RC4, 3DES, both AES)
suggesting it is rather old. If you can’t get the server operator(s) to fix
their
server, you need to get openssl as used by perl to send a shorter ClientHello.
The most straightforward way is to reduce the set of suites offered,
especially since the server implements only 4.
According to perldoc for the best perl I have (5.6.1 ActivePerl for Windows)
but not tested, LWP::UserAgent can take a hash ssl_opts which apparently are
passed (eventually) to openssl. Just making SSL_cipher_list DEFAULT:!ECDH
should reduce the cipher list enough, although you might want even more
restrictive settings for other reasons, like in general you should always
prohibit “export” and “LOW” ciphers which have been broken for years.
Alternatively it looks like you can set SSL_version to exclude TLSv12 or just
force TLSv1; that excludes a bunch of ciphers and also the sigalgs extension,
which should make Hello short enough.
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Peter Abbott
Sent: Thursday, December 19, 2013 17:29
To: openssl-users@openssl.org
Subject: *** Spam *** Upgrade Breakage of Perl Script
Hi,
I have a simple perl script which supplies a username and account password to a
server. The server in turn returns a password token for further operations. The
script does not specifically use openssl but the perl modules LWP::UserAgent
and or HTTP::Request must do. The script worked perfectly up to openssl version
1.0.1e-4.fc19.x86_64. Further upgrades to 1.0.1e-28.fc19 and 1.0.1e30.fc19 just
hang somewhere at the handshake stage.
I am only a novice and have a limited understanding of what is going on. Part
of the script is as follows:
#!/usr/bin/perl -w
use strict;
use LWP::UserAgent;
use HTTP::Request;
my $message = '?xml version=1.0 encoding=utf-8?
soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:ser=http://service.thirdparty.api.neo.tabcorp.com.au/;
soapenv:Header/
soapenv:Body
ser:authenticateAccount
apiMeta
deviceId111/deviceId
jurisdictionId2/jurisdictionId
requestChannel1/requestChannel
usernamePasswordToken/usernamePasswordToken
/apiMeta
authRequest
accountIdxx/accountId
accountPassword/accountPassword
/authRequest
/ser:authenticateAccount
/soapenv:Body
/soapenv:Envelope';
my $keyn;
my $userAgent = LWP::UserAgent-new();
my $request = HTTP::Request-new(POST =
'https://api.tab.com.au/tabapi/services/thirdPartyAuthenticate');
$request-header(SOAPAction =
'http://service.thirdparty.api.neo.tabcorp.com.au/;');
$request-content($message);
$request-content_type(text/xml; charset=utf-8);
my $response = $userAgent-request($request);
if($response-code == 200) {
print $response-as_string;
}
else {
print zs
}
Can anyone shed some light on what is happening here or what I can do to remedy
the problem?
Thanks,
Peter.
Re: Upgrade Breakage of Perl Script: RH recent
Thanks Dave,
I have approached the server operator about the security shortcomings that
you pointed out. In the interim I used your suggestion and altered the
cipher list to SSL_cipher_list DEFAULT:!ECDH.
This has sorted the problem. I am very grateful for your assistance.
Peter.
On 21 December 2013 08:08, Dave Thompson dthomp...@prinpay.com wrote:
I don’t use Fedora and track its versions, but assuming those are recent
RedHat including Fedora recently enabled ECC in its openssl packages
after years of excluding it over concerns about Certicom’s patent.
That increases the number of cipher suites in the Client Hello message
and also adds two extensions (although fairly small for RH) which makes
the Hello message bigger, and some servers are known to hang or otherwise
fail when the Hello message is bigger than used to be “normal” a decade
ago.
Apparently api.tab.com.au:443 is such; tested with s_client 255 hangs.
(In a 404 it claims to be “WebLogic Server”, which I don’t know about.)
I also observe this server does not implement 5746 (secure renegotiation)
and will negotiate only TLSv1(.0) and 4 akRSA suites (RC4, 3DES, both AES)
suggesting it is rather old. If you can’t get the server operator(s) to
fix their
server, you need to get openssl as used by perl to send a shorter
ClientHello.
The most straightforward way is to reduce the set of suites offered,
especially since the server implements only 4.
According to perldoc for the best perl I have (5.6.1 ActivePerl for
Windows)
but not tested, LWP::UserAgent can take a hash ssl_opts which apparently
are
passed (eventually) to openssl. Just making SSL_cipher_list DEFAULT:!ECDH
should reduce the cipher list enough, although you might want even more
restrictive settings for other reasons, like in general you should always
prohibit “export” and “LOW” ciphers which have been broken for years.
Alternatively it looks like you can set SSL_version to exclude TLSv12 or
just
force TLSv1; that excludes a bunch of ciphers and also the sigalgs
extension,
which should make Hello short enough.
*From:* owner-openssl-us...@openssl.org [mailto:
owner-openssl-us...@openssl.org] *On Behalf Of *Peter Abbott
*Sent:* Thursday, December 19, 2013 17:29
*To:* openssl-users@openssl.org
*Subject:* *** Spam *** Upgrade Breakage of Perl Script
Hi,
I have a simple perl script which supplies a username and account password
to a server. The server in turn returns a password token for further
operations. The script does not specifically use openssl but the perl
modules LWP::UserAgent and or HTTP::Request must do. The script worked
perfectly up to openssl version 1.0.1e-4.fc19.x86_64. Further upgrades to
1.0.1e-28.fc19 and 1.0.1e30.fc19 just hang somewhere at the handshake stage.
I am only a novice and have a limited understanding of what is going on.
Part of the script is as follows:
#!/usr/bin/perl -w
use strict;
use LWP::UserAgent;
use HTTP::Request;
my $message = '?xml version=1.0 encoding=utf-8?
soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:ser=http://service.thirdparty.api.neo.tabcorp.com.au/;
soapenv:Header/
soapenv:Body
ser:authenticateAccount
apiMeta
deviceId111/deviceId
jurisdictionId2/jurisdictionId
requestChannel1/requestChannel
usernamePasswordToken/usernamePasswordToken
/apiMeta
authRequest
accountIdxx/accountId
accountPassword/accountPassword
/authRequest
/ser:authenticateAccount
/soapenv:Body
/soapenv:Envelope';
my $keyn;
my $userAgent = LWP::UserAgent-new();
my $request = HTTP::Request-new(POST = '
https://api.tab.com.au/tabapi/services/thirdPartyAuthenticate');
$request-header(SOAPAction = '
http://service.thirdparty.api.neo.tabcorp.com.au/;');
$request-content($message);
$request-content_type(text/xml; charset=utf-8);
my $response = $userAgent-request($request);
if($response-code == 200) {
print $response-as_string;
}
else {
print zs
}
Can anyone shed some light on what is happening here or what I can do to
remedy the problem?
Thanks,
Peter.
