Re: [openssl.org #3383] ASM support questions for openssl 1.0.1g. in MIPS64 CPU.
I am porting Openssl 1.0.1g in Embedded which is developed with OpenWRT - MIPS64 CPU. I found SHA is not working and it will always dead when calling sha1_block_data_order defined in sha1-mips.pl. If I ./configure with no-asm then everything is fine. My questions is does sha1-mips.pl is support only for MIPS32? does it support on MIPS64? Formally speaking RT is for bug reports, not for queries like above. While sha1-mips.pl is not MIPS32-only and MIPS64 is expected to work, it wasn't actually tested for a good while. So make it look like bug report. When you say I am porting what does it mean exactly? There is a number of linux*-mips* config lines, so port shouldn't be needed. When you say MIPS64, what does it mean? 64-bit kernel? Or MIPS64 processor running 32-bit kernel? If latter, does kernel support n32 ABI? When it dies, where exactly? This information is obtained with debugger. Collect even register contents and disassemble output up to crash point. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3437] Bug in TLS Client Hello CipherSuite List
Hi,
I've found a bug in the Client Hello cipher suites list corresponding to RFC
2246. Always the last cipher suite in the list contains an additional byte
0xFF, so the rest of the record cannot be read correctly and connections, which
use the following Client Hello Extensions, fail.
I'm note sure, in which version(s) and since this bug is in. I only see, that
connections will not work, as soon as the request goes through an web proxy
with https inspection which use openssl. I tested with different comercial
products, request which goes through a web proxy which do not use openssl (e.g
Microsoft TMG) works fine. So I guess, this additional byte is the reason for
broken connections.
All of the tested web proxy products are patched because of the heart bleeding
bug.
Example: This is a TLS Rec Layer-1 which contains the additional byte 0xFF on
position 007D:
16 03 01 00 E4 01 00 00 E0 03 01 83 1E 08 12 F6
0010 02 39 AC 34 43 6F 43 E3 FC 67 6F F8 38 6D E3 19
0020 FC 80 E1 8D 5C CF EE FE 61 3F AF 00 00 50 C0 14
0030 C0 0A C0 22 C0 21 00 39 00 38 00 88 00 87 C0 0F
0040 C0 05 00 35 00 84 C0 12 C0 08 C0 1C C0 1B 00 16
0050 00 13 C0 0D C0 03 00 0A C0 13 C0 09 C0 1F C0 1E
0060 00 33 00 32 00 45 00 44 C0 0E C0 04 00 2F 00 41
0070 C0 11 C0 07 C0 0C C0 02 00 05 00 04 00 FF 02 01
0080 00 00 66 00 00 00 19 00 17 00 00 14 77 65 62 63
0090 6F 6E 66 2E 63 6F 6E 6E 65 63 74 69 73 2E 63 68
00A0 00 0B 00 04 03 00 01 02 00 0A 00 34 00 32 00 0E
00B0 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 0A 00 16
00C0 00 17 00 08 00 06 00 07 00 14 00 15 00 04 00 05
00D0 00 12 00 13 00 01 00 02 00 03 00 0F 00 10 00 11
00C0 00 23 00 00 00 0F 00 01 01
The 0xFF on position 007D should not be there, only then, the rest of the
record can interpreted correctly.
Here you find the whole tree of the wrong ClientHello (with 0xFF): Have a look
at the last TLSCipherSuites and the following bytes:
Frame: Number = 5, Captured Frame Length = 299, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP
(IPv4),DestinationAddress:[00-0C-29-AA-3E-0C],SourceAddress:[00-22-55-7E-D2-E7]
+ Ipv4: Src = 193.134.161.73, Dest = 91.209.53.40, Next Protocol = TCP, Packet
ID = 49379, Total IP Length = 285
+ Tcp: Flags=...AP..., SrcPort=37948, DstPort=HTTPS(443), PayloadLen=233,
Seq=1755423924 - 1755424157, Ack=4227022623, Win=29 (scale factor 0x9) = 14848
TLSSSLData: Transport Layer Security (TLS) Payload Data
- TLS: TLS Rec Layer-1 HandShake: Client Hello. Encrypted Handshake Message.
- TlsRecordLayer: TLS Rec Layer-1 HandShake:
ContentType: HandShake:
- Version: TLS 1.0
Major: 3 (0x3)
Minor: 1 (0x1)
Length: 228 (0xE4)
- SSLHandshake: SSL HandShake Encrypted Handshake Message
HandShakeType: ClientHello(0x01)
Length: 224 (0xE0)
- ClientHello: TLS 1.0
+ Version: TLS 1.0
+ RandomBytes:
SessionIDLength: 0 (0x0)
CipherSuitesLength: 80
+ TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA { 0xC0,0x14 }
+ TLSCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA{ 0xC0,0x0A }
+ TLSCipherSuites: TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA{ 0xC0,0x22 }
+ TLSCipherSuites: TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA { 0xC0,0x21 }
+ TLSCipherSuites: TLS_DHE_RSA_WITH_AES_256_CBC_SHA{ 0x00, 0x39 }
+ TLSCipherSuites: TLS_DHE_DSS_WITH_AES_256_CBC_SHA{ 0x00, 0x38 }
+ TLSCipherSuites: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA { 0x00, 0x88 }
+ TLSCipherSuites: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA { 0x00, 0x87 }
+ TLSCipherSuites: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA { 0xC0,0x0F }
+ TLSCipherSuites: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA { 0xC0,0x05 }
+ TLSCipherSuites: TLS_RSA_WITH_AES_256_CBC_SHA{ 0x00, 0x35 }
+ TLSCipherSuites: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA { 0x00, 0x84 }
+ TLSCipherSuites: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA { 0xC0,0x12 }
+ TLSCipherSuites: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA { 0xC0,0x08 }
+ TLSCipherSuites: TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA { 0xC0,0x1C }
+ TLSCipherSuites: TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA { 0xC0,0x1B }
+ TLSCipherSuites: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA{ 0x00,0x16}
+ TLSCipherSuites: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA{ 0x00,0x13 }
+ TLSCipherSuites: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA { 0xC0,0x0D }
+ TLSCipherSuites: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA{ 0xC0,0x03 }
+ TLSCipherSuites: TLS_RSA_WITH_3DES_EDE_CBC_SHA { 0x00,0x0A }
+ TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA { 0xC0,0x13 }
+ TLSCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA{ 0xC0,0x09 }
+ TLSCipherSuites: TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA{ 0xC0,0x1F }
+ TLSCipherSuites: TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA{ 0xC0,0x1E }
+ TLSCipherSuites: TLS_DHE_RSA_WITH_AES_128_CBC_SHA{ 0x00, 0x33 }
+ TLSCipherSuites: TLS_DHE_DSS_WITH_AES_128_CBC_SHA
Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*
Running `make test` with Clang sanitizers results in some issues with unaligned pointers surrounding some uses of buffers cast to a size_t*. The sanitizers used were `-fsanitize=undefined -fsanitize=address`. Those are conscious choices based on the fact that some CPUs, x86_64 included, are perfectly capable of tolerating unaligned access, in sense that code doesn't crash and produces correct result. In other words, it's legitimate platform-specific behaviour. As a compromise it's possible to arrange it so that build doesn't attempt to utilize this platform capability *if* compiled with -DPEDANTIC. Would it be acceptable compromise? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3437] Bug in TLS Client Hello CipherSuite List
On Sun, Jul 06, 2014 at 10:18:29AM +0200, Kaufmann Stephan via RT wrote:
- TLSCipherSuites: Unknown Cipher { 0x00,0xFF }
That is TLS_EMPTY_RENEGOTIATION_INFO_SCSV.
Hope, I could explain the problem and you can fix it soon and the fix will be
applied soon to all web proxies...
I don't see a problem. Your tool doesn't know about some
cipher as far as I can see.
I'm not sure what is exactly in between, but as far as I can see
that is causing the problem and there is nothing wrong with the
handshake.
The was introduced as part of the secure renegiotation. See
RFC 5746.
Kurt
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*
On Sun, Jul 06, 2014 at 10:25:19AM +0200, Andy Polyakov via RT wrote: Running `make test` with Clang sanitizers results in some issues with unaligned pointers surrounding some uses of buffers cast to a size_t*. The sanitizers used were `-fsanitize=undefined -fsanitize=address`. Those are conscious choices based on the fact that some CPUs, x86_64 included, are perfectly capable of tolerating unaligned access, in sense that code doesn't crash and produces correct result. In other words, it's legitimate platform-specific behaviour. As a compromise it's possible to arrange it so that build doesn't attempt to utilize this platform capability *if* compiled with -DPEDANTIC. Would it be acceptable compromise? It already seems to be controlled by the STRICT_ALIGNMENT define, which looks like: #define STRICT_ALIGNMENT 1 #if defined(__i386) || defined(__i386__)|| \ defined(__x86_64) || defined(__x86_64__) || \ defined(_M_IX86)|| defined(_M_AMD64)|| defined(_M_X64) || \ defined(__aarch64__)|| \ defined(__s390__) || defined(__s390x__) # undef STRICT_ALIGNMENT #endif This are the result I get without the strict alignment: without EVP (and AES-NI): type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128 cbc 109991.09k 121907.05k 124370.43k 125518.43k 125509.63k With EVP: aes-128-cbc 659929.40k 717046.56k 726172.76k 731055.52k 732257.95k And with strict alignment: without EVP: type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128 cbc 111016.13k 121922.45k 124197.29k 125595.48k 125438.63k With EVP: type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128-cbc 67.30k 714415.45k 726278.83k 730977.09k 731893.55k I would have no problem with strict alignment being the default when looking at that. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
JPAKE?
Does anyone use it? We're considering removing or refactoring it... __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: JPAKE?
On Sun, Jul 6, 2014 at 1:37 PM, Ben Laurie b...@links.org wrote: Does anyone use it? Not that I'm aware of. It was never enabled in OpenSSH. We're considering removing or refactoring it... __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3434] [PATCH] Add support for key wrapping mode with padding - RFC 5649
On Fri Jul 04 20:33:35 2014, pspa...@redhat.com wrote: [I'm re-sending this e-mail again because I haven't received any reply and it didn't appeared neither on http://rt.openssl.org/NoAuth/Buglist.html nor on -devel list.] Attached patch set adds support for key wrapping mode described in RFC 5649. This mode allows you to wrap keys of any length in range [1, 2^31] bytes and does integrity check after unwrapping. It is an extension of original key wrapping algorithm described in RFC 3394 (this is already implemented as CRYPTO_128_wrap and works only with 64-bit blocks). This patch set also adds test for RFC 3394 and RFC 5649 functionality. I tried to fully describe purpose and implementation directly in the code comments. This patch set is re-implementation from scratch and obsoletes patch attached to ticket 2204 from year 2010. There are a few problems with the patches as supplied. There are several warnings when use the --strict-warnings option to see what they are. There are also some constructs which I think might cause problems on some platforms for example .foo = bar structure initialisation but that's only in the test code but that wont matter if the same functionality is added to evp_test.c .I'm not sure how portable uiint32_t is either. I think we should avoid having a htonl dependency in the code if possible. It's not hard to avoid that. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*
Running `make test` with Clang sanitizers results in some issues with unaligned pointers surrounding some uses of buffers cast to a size_t*. The sanitizers used were `-fsanitize=undefined -fsanitize=address`. Those are conscious choices based on the fact that some CPUs, x86_64 included, are perfectly capable of tolerating unaligned access, in sense that code doesn't crash and produces correct result. In other words, it's legitimate platform-specific behaviour. As a compromise it's possible to arrange it so that build doesn't attempt to utilize this platform capability *if* compiled with -DPEDANTIC. Would it be acceptable compromise? It already seems to be controlled by the STRICT_ALIGNMENT define, which looks like: #define STRICT_ALIGNMENT 1 #if defined(__i386) || defined(__i386__)|| \ defined(__x86_64) || defined(__x86_64__) || \ defined(_M_IX86)|| defined(_M_AMD64)|| defined(_M_X64) || \ defined(__aarch64__)|| \ defined(__s390__) || defined(__s390x__) # undef STRICT_ALIGNMENT #endif Yes, and suggestion is to !defined(PEDANTIC) over whole thing. This are the result I get without the strict alignment: without EVP (and AES-NI): type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128 cbc 109991.09k 121907.05k 124370.43k 125518.43k 125509.63k With EVP: aes-128-cbc 659929.40k 717046.56k 726172.76k 731055.52k 732257.95k And with strict alignment: without EVP: type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128 cbc 111016.13k 121922.45k 124197.29k 125595.48k 125438.63k With EVP: type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128-cbc 67.30k 714415.45k 726278.83k 730977.09k 731893.55k These are all assembly cases, with and without AES-NI and/or EVP, when cbc128.c is not involved. I mean AES CBC-ing is handled in assembly in all these cases, not in cbc128.c. But even if cbc128.c was involved, the benefit can be observed when input or output is actually misaligned, while openssl speed benchmarks ... aligned data. So that above results don't tell anything about benefits of STRICT_ALIGNMENT being undefined. And it's usually around 10%. And indeed, I just measured 12.5% on my computer. [You have to configure with no-asm, and rig apps/speed.c to use misaligned buffers]. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*
On Sun, Jul 06, 2014 at 05:12:42PM +0200, Andy Polyakov via RT wrote: Running `make test` with Clang sanitizers results in some issues with unaligned pointers surrounding some uses of buffers cast to a size_t*. The sanitizers used were `-fsanitize=undefined -fsanitize=address`. Those are conscious choices based on the fact that some CPUs, x86_64 included, are perfectly capable of tolerating unaligned access, in sense that code doesn't crash and produces correct result. In other words, it's legitimate platform-specific behaviour. As a compromise it's possible to arrange it so that build doesn't attempt to utilize this platform capability *if* compiled with -DPEDANTIC. Would it be acceptable compromise? It already seems to be controlled by the STRICT_ALIGNMENT define, which looks like: #define STRICT_ALIGNMENT 1 #if defined(__i386) || defined(__i386__)|| \ defined(__x86_64) || defined(__x86_64__) || \ defined(_M_IX86)|| defined(_M_AMD64)|| defined(_M_X64) || \ defined(__aarch64__)|| \ defined(__s390__) || defined(__s390x__) # undef STRICT_ALIGNMENT #endif Yes, and suggestion is to !defined(PEDANTIC) over whole thing. This are the result I get without the strict alignment: without EVP (and AES-NI): type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128 cbc 109991.09k 121907.05k 124370.43k 125518.43k 125509.63k With EVP: aes-128-cbc 659929.40k 717046.56k 726172.76k 731055.52k 732257.95k And with strict alignment: without EVP: type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128 cbc 111016.13k 121922.45k 124197.29k 125595.48k 125438.63k With EVP: type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128-cbc 67.30k 714415.45k 726278.83k 730977.09k 731893.55k These are all assembly cases, with and without AES-NI and/or EVP, when cbc128.c is not involved. I mean AES CBC-ing is handled in assembly in all these cases, not in cbc128.c. But even if cbc128.c was involved, the benefit can be observed when input or output is actually misaligned, while openssl speed benchmarks ... aligned data. So that above results don't tell anything about benefits of STRICT_ALIGNMENT being undefined. And it's usually around 10%. And indeed, I just measured 12.5% on my computer. [You have to configure with no-asm, and rig apps/speed.c to use misaligned buffers]. So with no-asm with an aligned buffer I end up with: type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128 cbc 221815.09k 235505.86k 237484.26k 238394.37k 238802.26k aes-128-cbc 207397.35k 231086.25k 235446.02k 238599.88k 238622.04k With an unaligned buffer: aes-128 cbc 221833.70k 233167.94k 230320.73k 234839.16k 236371.97k aes-128-cbc 209436.36k 229418.03k 229917.28k 234346.84k 236027.90k If I then turn on strict alignment I get: aligned buffer: aes-128 cbc 217976.36k 235141.91k 236186.03k 238082.39k 239554.35k aes-128-cbc 203719.29k 229814.17k 234827.01k 238313.91k 238441.81k unaligned buffer: aes-128 cbc 202410.53k 222304.58k 224151.72k 226482.52k 227178.68k aes-128-cbc 192809.47k 218801.59k 223360.85k 226003.29k 227447.18k Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #1180] NetWare patch to add gcc support to 0.9.8
Not sure if this is stil an issue. Very old release. Closing the ticket. Is OpenSSL on netware still deployed and useful? Please reply if so. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*
... So that above results don't tell anything about benefits of STRICT_ALIGNMENT being undefined. And it's usually around 10%. And indeed, I just measured 12.5% on my computer. [You have to configure with no-asm, and rig apps/speed.c to use misaligned buffers]. If I then turn on strict alignment I get: aligned buffer: aes-128 cbc 217976.36k 235141.91k 236186.03k 238082.39k 239554.35k aes-128-cbc 203719.29k 229814.17k 234827.01k 238313.91k 238441.81k unaligned buffer: aes-128 cbc 202410.53k 222304.58k 224151.72k 226482.52k 227178.68k aes-128-cbc 192809.47k 218801.59k 223360.85k 226003.29k 227447.18k I.e. 5% difference. Exact difference can of course vary, as it depends on how fast cipher is. Slower cipher is, smaller the difference, because cbc128.c overhead does not depend on cipher. So that exact coefficient depends even on compiler version and optimization level. 10% is something I've measured when cbc128.c was implemented and it was approximately same today on my computer. You've got 5%. Point still is that there is measurable difference. Next question is of course if the difference is significant enough to care about in the context. It should be noted that sanitized code referred to in original report is not necessarily something you'd use in production build, because it's significantly slower because of the additional checks. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: argv/Argv hacks in openssl.c
ควยไร ฮะ เหี้ย From: rs...@akamai.com To: openssl-dev@openssl.org Date: Sat, 5 Jul 2014 12:45:34 -0400 Subject: argv/Argv hacks in openssl.c There’s a bunch of hacks in apps/openssl.c to work around some old VMS releases; the coment is dated 2011-03-22.I am going to delete it.Speak up now if you can justify keeping it. -- Principal Security EngineerAkamai Technologies, Cambridge, MAIM: rs...@jabber.me; Twitter: RichSalz
RE: argv/Argv hacks in openssl.c
From: ann-i...@hotmail.com To: openssl-dev@openssl.org Subject: RE: argv/Argv hacks in openssl.c Date: Mon, 7 Jul 2014 01:15:18 +0700 ควยไร ฮะ เหี้ย From: rs...@akamai.com To: openssl-dev@openssl.org Date: Sat, 5 Jul 2014 12:45:34 -0400 Subject: argv/Argv hacks in openssl.c There’s a bunch of hacks in apps/openssl.c to work around some old VMS releases; the coment is dated 2011-03-22.I am going to delete it.Speak up now if you can justify keeping it. -- Principal Security EngineerAkamai Technologies, Cambridge, MAIM: rs...@jabber.me; Twitter: RichSalz
Fwd: [openssl.org #3436] Platform strategy
I am not subscribed to the openssl-dev mailing list and I do not think I want to be subscribed. I can offer a HP-UX account to a PA-RISC2 HP-UX 11.23 system Do contact me off-list for details I understand that you close the RT ticket, but I saw no other contact e-mail to post my reaction to. Oorspronkelijke bericht Date: 2014-07-05 23:50 From: Tim Hudson via RT r...@openssl.org To: hmbr...@xs4all.nl Cc: openssl-dev@openssl.org Reply-To: r...@openssl.org I am closing this item as it is not actually a defect (although we do appreciate getting rapid feedback on the roadmap). The discussion in terms of platform strategy should continue on the openssl-dev mailing list as we work through tackling platform related issues. Separately I'm looking through the range of systems and the automated building items that various users have put in place - it is great to see the enthusiasm for the range of platforms OpenSSL works on. If you are able to provide access to a platform to the OpenSSL development team then noting that on openssl-dev would be useful. Thanks, Tim. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*
On Sun, Jul 06, 2014 at 06:57:57PM +0200, Andy Polyakov via RT wrote: ... So that above results don't tell anything about benefits of STRICT_ALIGNMENT being undefined. And it's usually around 10%. And indeed, I just measured 12.5% on my computer. [You have to configure with no-asm, and rig apps/speed.c to use misaligned buffers]. If I then turn on strict alignment I get: aligned buffer: aes-128 cbc 217976.36k 235141.91k 236186.03k 238082.39k 239554.35k aes-128-cbc 203719.29k 229814.17k 234827.01k 238313.91k 238441.81k unaligned buffer: aes-128 cbc 202410.53k 222304.58k 224151.72k 226482.52k 227178.68k aes-128-cbc 192809.47k 218801.59k 223360.85k 226003.29k 227447.18k I.e. 5% difference. Exact difference can of course vary, as it depends on how fast cipher is. Slower cipher is, smaller the difference, because cbc128.c overhead does not depend on cipher. So that exact coefficient depends even on compiler version and optimization level. 10% is something I've measured when cbc128.c was implemented and it was approximately same today on my computer. You've got 5%. Point still is that there is measurable difference. Next question is of course if the difference is significant enough to care about in the context. It should be noted that sanitized code referred to in original report is not necessarily something you'd use in production build, because it's significantly slower because of the additional checks. I think the main question is if this speed difference is a good excuse to use undefined behavior or not. I'm curious where all the unaligned pointers actually come from, since as far as I can see that function doesn't create the unaligned pointers itself and it seems to be other code that seems to be introducing the unaligned buffers and when STRICT_ALIGNMENT is defined it knows how to deal with that. Defining STRICT_ALIGNMENT fixes the warnings in cbc128.c, but there are still in wp_block.c:576-626, md5_dgst.c:108-123 and md32_common.h:399 Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*
Basically this discussion applies even to tickets #3422 and #3423. This means that I'm not going to comment on those tickets, but do whatever we agree on doing here and close them simultaneously. I think the main question is if this speed difference is a good excuse to use undefined behavior or not. As already mentioned, the difference depends on how fast is cipher. As cbc128.c is not cipher-specific, you can't pose question about *this* difference. Well, we can assess current ciphers and say too little, but then we would have to reconsider for each new cipher we add. Or we simply consider this kind of optimization acceptable or not without quantifying. Just in the context of this warning. I brought up quantitative difference only to expose mislead conclusion. And I argue yes, it's justifiable. And as compromise, suggestion is to avoid it in -DPEDANTIC build. So instead of rephrasing question, tell what conclusion do you draw. To recap. Original statement was I have no problem based on this data. But the data is flawed. Yes, indeed. And conclusion is? [And reply to r...@openssl.org]. As for warning. I personally would argue that we are looking at platform-specific i.e. implementation-defined behaviour, not undefined. Once again, this applies to all three tickets. One is effectively identical to this one, second is about variable shift in CAST. As mentioned they all are conscious choices and are proven to work. BTW, specification gives following example of undefined behaviour: EXAMPLE: An example of undefined behavior is the behavior on integer overflow. Well, one can argue about definition of integer, but if we assume any integer, signed or unsigned, then we depend on unsigned addition being non-saturating and overflow being ignored *all* *over* *the* *place*... __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3430] ssltest fails when using -DTEMP_GOST_TLS
Please raise this issue on the openssl-users list - this is preferred way of raising support questions. If there is a definite bug then please re-raise a ticket in RT. Closing this ticket for now. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3433] ESXi 4.1 SSL Patch
Please raise this issue on the openssl-users list - this is the preferred way of raising support questions. If there is a definite bug then please re-raise a ticket in RT. Closing this ticket for now. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3437] Bug in TLS Client Hello CipherSuite List
Copying Kurt Roeckx response to this below (which only went to the openssl-dev
list, and not to RT).
Based on Kurt's response I am closing this ticket for now. Please re-open by
responding to this email if you still think this is a defect.
Matt
On Sun, Jul 06, 2014 at 10:18:29AM +0200, Kaufmann Stephan via RT wrote:
- TLSCipherSuites: Unknown Cipher {
0x00,0xFF }
That is TLS_EMPTY_RENEGOTIATION_INFO_SCSV.
Hope, I could explain the problem and you can fix it soon and the fix
will be applied soon to all web proxies...
I don't see a problem. Your tool doesn't know about some
cipher as far as I can see.
I'm not sure what is exactly in between, but as far as I can see
that is causing the problem and there is nothing wrong with the
handshake.
The was introduced as part of the secure renegiotation. See
RFC 5746.
Kurt
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
[openssl.org #1672] QA bug - unreachable code ./apps/s_server.c with -crl_check
Resolved (finally!). Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #1822] Issues w/ fips Makefile
Old FIPS version, no longer maintained. Marked as resolved. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2233] [BUG] Checkin #19560 causes an DTLS bug
No further feedback, assuming resolved. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #747] -pre and -post cmd line params for openssl cmds
Interesting idea but not really needed now as you can specify -pre and -post commands in the config file. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3132] Query related to d2i_X509 and X509_free
Not a bug report, should be in openssl-users. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3425] Potential padding oracle in evp_enc.c
Not sure what you're pointing out. That there are different return values? This is a local API, so warning users to not expose detail errors would address this, right? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3059] TLS 1.2 CertificateRequests allows MD5
Resolved now. OpenSSL no longer uses MD5 in the supported signature algorithms list. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1372] default config should diable idea
The last patents for IDEA expired in 2012. Now it's free to use. On 3 July 2014 21:24, Rich Salz via RT r...@openssl.org wrote: As the changelog says for 0.9.8, (IDEA remains enabled despite being patented. This is because IDEA is frequently required for interoperability, and there is no license fee for non-commercial use. As before, no-idea can be used to avoid this algorithm.) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
