... 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 F
> 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, sect1
On 20 December 2013 00:24, Matt Caswell wrote:
> On 19 December 2013 23:47, Porter, Andrew 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 th
On 19 December 2013 23:47, Porter, Andrew 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 sect571r1 first
> 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 t
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,
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 19 December 2013 18:52, Billy Brumley 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_
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
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 meth
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" ou
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 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 not change
> (unles
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 re-opene
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 wrote:
>
> http://en.wikipedia.org/wiki/Elliptic
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 p
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 op
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 pack
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 do
> 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.
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 f
20 matches
Mail list logo
