Building with darwin-x86_64-cc.
Error is:
paes-x86_64.s:203:32-bit absolute addressing is not supported for x86-64
I have attached my diff which fixes it.
Please let me know if you need further information.
Regards,
Jeremiah Rothschild
Systems Administrator
Franz Inc.
diff -r -u
Hi,
modexp512-x86_64.s ends here:
| #
| # X2 = Xh * M2 + Xl
| # do first part (X2 = Xh * M2)
| addq$80,%rdi# rdi - pXh ; 128 bits, 2 qwords
| #Xh is actually { [rdi+8*1], rbp }
| addq$64,%rsi# rsi - M2
| leaq296(%rsp),%rcx# rcx - pX2 ; 641 bits, 11
Hello,
My reading of RFC4492 is that the ECC ciphersuites apply only to TLS
1.0 or later. According to it: This document describes additions to TLS
to support ECC, applicable both to TLS Version 1.0 [2] and to TLS
Version 1.1 [3]. In particular, it defines
So it seems that SSL 3.0 shouldn't
[n...@gnutls.org - Sat Mar 17 14:57:31 2012]:
Hello,
My reading of RFC4492 is that the ECC ciphersuites apply only to TLS
1.0 or later. According to it: This document describes additions to TLS
to support ECC, applicable both to TLS Version 1.0 [2] and to TLS
Version 1.1 [3]. In
[fol...@cisco.com - Sat Mar 17 14:55:45 2012]:
Using openssl s_server as the application with libcrypto 1.0.1, it
appears the TLS 1.2 behavior may not be compliant with RFC 5246. Page
49 of RFC 5246 states:
If the client provided a signature_algorithms extension, then all
The documentation doesn't reflect current behaviour. The type
parameter to DSA_sign and DSA_verify is currently ignored, it should
arguably check the length is consistent with the passed digest type.
The actual algorithm implementation is OK though. The supplied digest
will be truncated if it
On 03/17/2012 03:53 PM, Stephen Henson via RT wrote:
The EC codes does need a bit of revising, that is one of its many quirks.
I'm trying to work out though how that client ends up producing that
condition. The only way I can think s_server with those command line
options could end up using
Building with darwin-x86_64-cc.
Error is:
paes-x86_64.s:203:32-bit absolute addressing is not supported for x86-64
Sounds like bug in assembler, as it's not absolute address there. What
does 'as -v' print on your system? I can't reproduce the problem with
Apple Inc version cctools-822, GNU
modexp512-x86_64.s ends here:
| #
| # X2 = Xh * M2 + Xl
| # do first part (X2 = Xh * M2)
| addq$80,%rdi# rdi - pXh ; 128 bits, 2 qwords
| #Xh is actually { [rdi+8*1], rbp }
| addq$64,%rsi# rsi - M2
| leaq296(%rsp),%rcx# rcx - pX2 ; 641 bits, 11
Is incore part of the validation, or is it like fipsld - allowed to be
modified as needed without invalidating FIPS certification?
It shouldn't void certification, no. But why is it concern for you? You
have to aim for change letter and therefore there is window for
including even this
On Sat, Mar 17, 2012 at 3:53 PM, Stephen Henson via RT r...@openssl.orgwrote:
My reading of RFC4492 is that the ECC ciphersuites apply only to TLS
1.0 or later. According to it: This document describes additions to TLS
to support ECC, applicable both to TLS Version 1.0 [2] and to TLS
On Sat, Mar 17, 2012 at 05:21:47PM +0100, Andy Polyakov via RT wrote:
modexp512-x86_64.s ends here:
| #
| # X2 = Xh * M2 + Xl
| # do first part (X2 = Xh * M2)
| addq$80,%rdi# rdi - pXh ; 128 bits, 2 qwords
| #Xh is actually { [rdi+8*1], rbp }
| addq
On Sat, Mar 17, 2012 at 05:21:47PM +0100, Andy Polyakov via RT wrote:
modexp512-x86_64.s ends here:
| #
| # X2 = Xh * M2 + Xl
| # do first part (X2 = Xh * M2)
| addq$80,%rdi# rdi - pXh ; 128 bits, 2 qwords
| #Xh is actually { [rdi+8*1], rbp }
| addq
On 03/17/2012 03:53 PM, Stephen Henson via RT wrote:
The EC codes does need a bit of revising, that is one of its many quirks.
I'm trying to work out though how that client ends up producing that
condition. The only way I can think s_server with those command line
options could end up using
[n...@gnutls.org - Sat Mar 17 16:08:24 2012]:
I captured the handshake (attached), and it seems the client advertises
TLS 1.2. Could it be that the fallback is on the lowest supported
version rather than the next available?
That's strange. I tried OpenSSL 1.0.0h server (which supports
On 03/17/2012 09:03 PM, Stephen Henson via RT wrote:
[n...@gnutls.org - Sat Mar 17 16:08:24 2012]:
I captured the handshake (attached), and it seems the client
advertises TLS 1.2. Could it be that the fallback is on the lowest
supported version rather than the next available?
That's
Understood. I asked in part because I want to minimize the
number/scope of modifications so that the change letter validation is
viable and straightforward; and, I asked out of curiosity.
Kevin
On Sat, Mar 17, 2012 at 12:26 PM, Andy Polyakov ap...@openssl.org wrote:
Is incore part of the
On Sat, Mar 17, 2012 at 09:13:51PM +0100, Nikos Mavrogiannopoulos via RT wrote:
On 03/17/2012 09:03 PM, Stephen Henson via RT wrote:
[n...@gnutls.org - Sat Mar 17 16:08:24 2012]:
I captured the handshake (attached), and it seems the client
advertises TLS 1.2. Could it be that the
ping?
this should be trivial.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
On Sun, Mar 18, 2012 at 12:20:48AM +0100, Kurt Roeckx via RT wrote:
On Sat, Mar 17, 2012 at 09:13:51PM +0100, Nikos Mavrogiannopoulos via RT
wrote:
On 03/17/2012 09:03 PM, Stephen Henson via RT wrote:
[n...@gnutls.org - Sat Mar 17 16:08:24 2012]:
I captured the handshake
On Sun, Mar 18, 2012 at 12:49:35AM +0100, Kurt Roeckx via RT wrote:
I can confirm that removing the no-ssl2 part gets me a TLS
instead of SSLv3 connection.
The problem seems to be this code in s_client.c:
#if !defined(OPENSSL_NO_SSL2) !defined(OPENSSL_NO_SSL3)
21 matches
Mail list logo
