Yes, that Wireshark decode of (encrypted) renegotiation is clearly wrong.
Sending two ClientKX would be wrong, sending (Client)Cert and ClientKX
is right, and the first size would match Cert and not ClientKX.
You might try is s_client -connect 23.66.176.239 -msg -debug
with redirect from a
From: owner-openssl-users On Behalf Of Porter, Andrew
Sent: Tuesday, December 17, 2013 17:53
Already tried -no_tls1_2 with no effect, but -cipher 'DEFAULT:!ECDH' is a
success,
and also just -cipher 'DHE-RSA-AES256-SHA' to make it as small as
possible.
So looks like a bug with nss 3.15 or
Hi,
From my understanding ECDSA has a modulus N and a field size of q.
When generating the co-ordinates (x,y) using the generator and random value
k - g * k = (x,y) - the x and y values should be restricted to the range x =
[1, ... , q-1] and y = [1, ... , q -1].
Then of course to get r we
On 12/17/2013 07:11 PM, Porter, Andrew wrote:
and the Java app throws the exception:
PKCS11Exception: CKR_DOMAIN_PARAMS_INVALID
Can you provide a backtrace?
What's the JVM configuration? Does it use the SunPKCS11 provider, or if
not, how does it end up in NSS code? (Some RHEL OpenJDK
http://en.wikipedia.org/wiki/Elliptic_Curve_DSA
order in the code you pasted = n in the wiki = N in your mail.
The code you pasted refers to GFp so the points (x,y) satisfy 0 = x
p and 0 = y p. That's probably what you mean by q. Anyway, it's
used in the underlying elliptic curve operations
Florian:
By backtrace I'm guessing you mean Java debug output, below is what I get in
the Tomcat catalina.out with
JAVA_TOOL_OPTIONS=-Djavax.net.debug=ssl,handshake set in the script that
starts Tomcat.
Problem happens with the stock OpenJDK 1.7.0-45 java.security file enabling the
pkcs11
Thank you Billy for the clarification - is there a way to retrieve the value
for p that is used under the hood? I assume the p value does not change
(unless the curve is changed).
Sent from my iPhone
On 19 Dec 2013, at 17:35, Billy Brumley bbrum...@gmail.com wrote:
I have previously pointed this out as a bug in the FIPS spec. The need to
prevent matching pairs in random numbers by 4.8.2 in FIPS 140-2 reduces
the entropy.
The requirement in 4.8.2 applies to all SP800-90 DRBGs, not just the Dual
EC DRBG.
I submitted this as part of my comments to the
It's in the EC_GROUP structure: group-field. Check crypto/ec/ec_lcl.h. BBB
On Thu, Dec 19, 2013 at 9:54 AM, Patrick McCorry stonecold...@gmail.com wrote:
Thank you Billy for the clarification - is there a way to retrieve the value
for p that is used under the hood? I assume the p value does
Dave (and Florian):
I doubt this one is an instance of the Hello-too-big problem; I've
never seen that in Suncle JSSE and I doubt it would be
introduced in OpenJDK.
You are correct that it is not the hello size: as you suggested I tried the
ECDHE-RSA-x ciphers from the openssl ciphers
On Thu, Dec 19, 2013, Porter, Andrew wrote:
The next puzzler: the -cipher ''ECDHE-RSA-AES256-SHA' which fails with
stock OpenSSL 1.0.1e (Cygwin, OpenSUSE v13.1, built myself) works using
RHEL-modified 1.0.1e openssl. There are significant ClientHello differences
in compression method and
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
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
Steve:
If you try OpenSSL 1.0.2 you can customise the signature algorithms and
supported curves using a command line option.
Erm, how? The ssltest.c and ssl_conf.c source files suggest -named_curve or
-curves as a possibilities, but trying to use them with openssl s_client just
gets me
On Thu, Dec 19, 2013, Porter, Andrew wrote:
Steve:
If you try OpenSSL 1.0.2 you can customise the signature algorithms and
supported curves using a command line option.
Erm, how? The ssltest.c and ssl_conf.c source files suggest -named_curve or
-curves as a possibilities, but trying
The s_client and s_server utilities can use the new SSL_CONF API in 1.0.2,
see:
http://www.openssl.org/docs/ssl/SSL_CONF_cmd.html#SUPPORTED_COMMAND_LINE_COMMANDS
The -sigalgs and -curves options should do the trick.
I did try -curves before and failed, but I must have been tripped up by
On 19 December 2013 23:47, Porter, Andrew andrew_por...@bmc.com wrote:
So, additional data now. This works:
./openssl s_client -debug -cipher 'ECDHE-RSA-AES256-SHA' -curves
'secp521r1:secp384r1:prime256v1:sect571r1' -connect tomcat-host:443
But use the same curves in a different order, with
On 20 December 2013 00:24, Matt Caswell fr...@baggins.org wrote:
On 19 December 2013 23:47, Porter, Andrew andrew_por...@bmc.com wrote:
So, additional data now. This works:
./openssl s_client -debug -cipher 'ECDHE-RSA-AES256-SHA' -curves
'secp521r1:secp384r1:prime256v1:sect571r1' -connect
Maybe just a co-incidence, but the sect571r1 curve is the only binary curve
in your list- the others are all prime curves. Maybe it doesn't like binary
curves?
Yes, if any binary curve (sect571r1, sect571k1, sect409k1, sect409r1,
sect283k1, sect283r1, sect239k1, sect233k1, sect233r1,
... 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
20 matches
Mail list logo
