[openssl-dev] [openssl.org #4305] ChaCha20 assembly bugs

Hi folks, I've started playing with the ChaCha20 assembly that was recently checked in and found a few problems. Most of these do not affect OpenSSL as you only ever call ChaCha20_ctr32 on a whole number of blocks. But this isn't documented as a constraint in internal/chacha.h and the assembly has

Re: [openssl-dev] [openssl.org #4229] Bug - OpenSSL 1.0.2e on AIX has sha256p8-ppc.s assembler build issue...

You can also add some more macros to the perlasm which already translates a LOT of opcodes into something older assemblers won't choke on.Pete-"openssl-dev" wrote: -To: robert.go...@igt.comFrom: Jeremy Farrell via RT Sent by: "openssl-dev" Date: 02/13/2016

Re: [openssl-dev] [openssl.org #4229] Bug - OpenSSL 1.0.2e on AIX has sha256p8-ppc.s assembler build issue...

You can also add some more macros to the perlasm which already translates a LOT of opcodes into something older assemblers won't choke on. Pete -"openssl-dev" wrote: -To: robert.go...@igt.com From: Jeremy Farrell via RT Sent by: "openssl-dev" Date: 02/13/2016 03:46AM Cc: openssl-dev@ope

[openssl-dev] [openssl.org #4304] [Patch] Support HTTP-on-HTTPS-Error for OpenSSL 1.1.0

Hi there, please find attached a patch proposal to reintroduce the HTTP-on-HTTPS detection for OpenSSL 1.1.0. The feature is present until 1.0.2, but although the error codes are still in the 1.1.0 header files, the detection is gone. Comments welcome! Regards, Rainer -- Ticket here: http:

Re: [openssl-dev] 3DES is a HIGH-strength cipher?

> On Feb 12, 2016, at 7:21 PM, Richard Moore wrote: > > Yeah, the apache docs didn't say this for /many/ years and it was rejected > when I reported it as a security problem. The docs had been correct I believe > with some older versions of openssl but the more general point is that users > n

Re: [openssl-dev] 3DES is a HIGH-strength cipher?

On 13 February 2016 at 00:16, Viktor Dukhovni wrote: > > > On Feb 12, 2016, at 6:55 PM, Richard Moore > wrote: > > > > ​Personally I think the fact that HIGH includes ciphersuites that offer > no MITM protection means that those who trust it have already been totally > betrayed. > > The correct

Re: [openssl-dev] 3DES is a HIGH-strength cipher?

> On Feb 12, 2016, at 6:55 PM, Richard Moore wrote: > > ​Personally I think the fact that HIGH includes ciphersuites that offer no > MITM protection means that those who trust it have already been totally > betrayed. The correct way to use high-grade ciphers is. "DEFAULT:!EXPORT:!LOW

Re: [openssl-dev] 3DES is a HIGH-strength cipher?

On 12 February 2016 at 21:29, Salz, Rich wrote: > > > Well, it would be a major compatibility break for 1.0.2 and earlier, so > no go > > there. As for 1.1.0, folks > > Or those who trust us to say what HIGH means should, well, not be lied to. > > Something must be changed for 1.1 Either 3DES m

Re: [openssl-dev] [openssl.org #4229] Bug - OpenSSL 1.0.2e on AIX has sha256p8-ppc.s assembler build issue...

Hi, Per Jeremy Farrell's suggestion, specifying the "-no-asm" option worked and I was able to get through the build. Regarding the "stvx" instruction, here is a bit clearer set of info to map to why that instruction seemed to be the issue: ./crypto/sha/sha256p8-ppc.s AES_ASM -c -o sha256p8-pp

Re: [openssl-dev] 3DES is a HIGH-strength cipher?

I think you should revert to your earlier comment - that High, Medium, Low are inherently awful. Maybe color codes? ;-) I consider 3DES-EDE to be adequately strong. The block size is a problem, speed in software is a problem, etc. but it has been remarkably resilient against differential cryptanal

Re: [openssl-dev] 3DES is a HIGH-strength cipher?

> Well, it would be a major compatibility break for 1.0.2 and earlier, so no go > there. As for 1.1.0, folks Or those who trust us to say what HIGH means should, well, not be lied to. Something must be changed for 1.1 Either 3DES moves out of HIGH or the definition of HIGH as documented in th

Re: [openssl-dev] 3DES is a HIGH-strength cipher?

> On Feb 12, 2016, at 4:06 PM, Phil Pearl wrote: > > I have to agree. The docs on 'cipher' in no way convey that HIGH has > any correlation to MTI (http://tools.ietf.org/html/rfc5246#section-9). > My interpretation of the I IN MTI to mean "Implement" (an > implementation detail necessary to mee

Re: [openssl-dev] 3DES is a HIGH-strength cipher?

Seconding Uri and Todd's views... On Feb 12, 2016, at 3:36 PM, Todd Short wrote: >So, if it’s “mandatory”, then it should be in the default set of > ciphers, not necessarily the “HIGH” set. > > I’m selecting “HIGH” because I want 128-bit+ ciphers, not a cipher > that that has subsequently found

Re: [openssl-dev] 3DES is a HIGH-strength cipher?

Conversely, if you do want 3DES set your cipherlist to DEFAULT:3DES Or someone fix the manpage. :( -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] 3DES is a HIGH-strength cipher?

> On Feb 12, 2016, at 3:52 PM, Short, Todd wrote: > > So, if it’s “mandatory”, then it should be in the default set of ciphers, not > necessarily the “HIGH” set. > > I’m selecting “HIGH” because I want 128-bit+ ciphers, not a cipher that that > has subsequently found to be weaker than previou

Re: [openssl-dev] 3DES is a HIGH-strength cipher?

> I used to think that MTI doesn’t mean “Mandatory To Offer”. My codebase must > have it, but my server (and/or client) configuration may explicitly forbid > it. Is there anything wrong with this view? No. At least within the TLS WG this has been brought up multiple times. :) -- openssl-dev m

Re: [openssl-dev] 3DES is a HIGH-strength cipher?

> So, if it’s “mandatory”, then it should be in the default set of ciphers, not > necessarily the “HIGH” set. > > I’m selecting “HIGH” because I want 128-bit+ ciphers, not a cipher that that > has subsequently found to be weaker than previously thought. I used to think that MTI doesn’t mean “Mand

Re: [openssl-dev] [openssl.org #4218] Invalid typecasting in CRYPTO_ctr128_encrypt

>>> OpenSSL 1.0.2e >>> >>> At line 156 of crypto/modes/ctr128.c >>> >>> const unsigned char *in, >>> unsigned char *out, >>> unsigned char ivec[16], >>> unsigned char ecount_buf[16] >>> >>>*(size_t *)(out + n) = >>>*(size_t *)(in + n) ^ *(size_t *)(ecount_buf + n); >>> >>> If the buffe

Re: [openssl-dev] 3DES is a HIGH-strength cipher?

So, if it’s “mandatory”, then it should be in the default set of ciphers, not necessarily the “HIGH” set. I’m selecting “HIGH” because I want 128-bit+ ciphers, not a cipher that that has subsequently found to be weaker than previously thought. -- -Todd Short // tsh...@akamai.com

Re: [openssl-dev] 3DES is a HIGH-strength cipher?

> Now let's not make stuff up: Caught me, I should have looked it up first. :) > Since many users enable just HIGH ciphers, they must not exclude the MTI > ciphers. Sob. "So let's lie because many users don't know what to do." -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org

Re: [openssl-dev] 3DES is a HIGH-strength cipher?

> On Feb 12, 2016, at 3:15 PM, Salz, Rich wrote: > > So is RC4 and we don't see that as HIGH. HIGH implies strength, not MTI-ness. Now let's not make stuff up: http://tools.ietf.org/html/rfc5246#section-9 9. Mandatory Cipher Suites In the absence of an application profile standard specif

Re: [openssl-dev] 3DES is a HIGH-strength cipher?

> 3DES is an MTI ciphersuite for TLS, so it must stay HIGH for now. Say what? So is RC4 and we don't see that as HIGH. HIGH implies strength, not MTI-ness. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] 3DES is a HIGH-strength cipher?

> On Feb 12, 2016, at 1:59 PM, Short, Todd wrote: > > This is a bit contradictory. According to the OpenSSL cipher documentation, > HIGH refers to 128-bit, or stronger, ciphers. > > Should 3DES ciphers be moved to the MEDIUM category? 3DES is an MTI ciphersuite for TLS, so it must stay HIGH f

Re: [openssl-dev] 3DES is a HIGH-strength cipher?

My personal opinion is that things like HIGH MEDIUM LOW are bad things ☺ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] 3DES is a HIGH-strength cipher?

On 12 February 2016 at 18:59, Short, Todd wrote: > Hi, > > In OpenSSL 1.0.2, and 1.0.1i, 3DES-CBC’s bit-strength was changed from 168 > to 112, which makes sense. However, it is still considered a HIGH-strength > cipher. > > RC4 is listed as having a bit strength of MEDIUM, and is a 128-bit > str

[openssl-dev] 3DES is a HIGH-strength cipher?

Hi, In OpenSSL 1.0.2, and 1.0.1i, 3DES-CBC’s bit-strength was changed from 168 to 112, which makes sense. However, it is still considered a HIGH-strength cipher. RC4 is listed as having a bit strength of MEDIUM, and is a 128-bit strength cipher (kinda). This is a bit contradictory. According t

[openssl-dev] [openssl.org #4303] OpenSSL 1.1.0 renegotiation problem (s_server/s_client)

Using OpenSSL 1.1.0pre2 I see renegotiation problems between s_client and s_server (but also in Apache mod_ssl). First starting: s_server -cert server.crt -key server.pem -accept 8443 -debug -state Using default temp DH parameters ACCEPT Now starting s_client -connect localhost:8443 -de

Re: [openssl-dev] [openssl.org #4229] Bug - OpenSSL 1.0.2e on AIX has sha256p8-ppc.s assembler build issue...

On 11/02/2016 22:36, Andy Polyakov via RT wrote: >> I am attempting to build OpenSSL 1.0.2e on AIX and I'm seeing an issue with >> the "stvx" assembler instruction in the sha256p8-ppc.s module. I have built >> prior version OpenSSL packages on AIX without issue until now (prior was >> 1.0.1c),

[openssl-dev] [openssl.org #4302] Documentation error in apps/x509.html: -[digest] option

https://www.openssl.org/docs/manmaster/apps/x509.html says: > -[digest] > > the digest to use. This affects any signing or display option that uses a > message digest, such as the -fingerprint, >-signkey and -CA options. Any digest supported by the OpenSSL dgst command can be used. If n

Re: [openssl-dev] openssl-SNAP-20160212 issue

On Fri, Feb 12, 2016 at 02:44:29PM +, Matt Caswell wrote: > > > On 12/02/16 14:31, The Doctor wrote: > > Here is another fix needed: > > > > making all in ssl... > > gcc -I.. -I../include -DDSO_DLFCN -DHAVE_DLFCN_H > > -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_THREADS -DOPENSSL_PIC > > -DOPEN

Re: [openssl-dev] openssl-SNAP-20160212 issue

On 12/02/16 14:31, The Doctor wrote: > Here is another fix needed: > > making all in ssl... > gcc -I.. -I../include -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_EXPERIMENTAL_JPAKE > -DOPENSSL_THREADS -DOPENSSL_PIC -DOPENSSL_BN_ASM_PART_WORDS > -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DS

[openssl-dev] openssl-SNAP-20160212 issue

Here is another fix needed: making all in ssl... gcc -I.. -I../include -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_THREADS -DOPENSSL_PIC -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAE

Re: [openssl-dev] [openssl.org #3759] [PATCH] crypto: use bigint in x86-64 perl

> When building on x32 systems where the default type is 32bit, make sure > we can transparently represent 64bit integers. Otherwise we end up with > build errors like: > /usr/bin/perl asm/ghash-x86_64.pl elf > ghash-x86_64.s > Integer overflow in hexadecimal number at asm/../../perlasm/x86_64-xla

[openssl-dev] [openssl.org #3854] openssl.cnf in openssl-1.0.1m still uses default_bits=1024

We cleaned this up a little: - crypto/conf/ssleay.cnf was obsolete and is gone from the master branch. - the req app now uses 2048 bits as a default if no other defaults are given. ssleay.txt is already gone from the master branch, and the test/ ones are used in tests. Cheers, Emilia -- Ticket

Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

Bonjour, Le 12 févr. 2016 à 01:11, Blumenthal, Uri - 0553 - MITLL mailto:u...@ll.mit.edu>> a écrit : Again, you are right, but what's the lesser evil‎ - being unable to use the new OpenSSL because it refuses to deal with the cert that some dim-witten TPM maker screwed up, or accept a certifica

Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

FYI, I checked other machines that have a TPM device manufactured by STM, but I could not find another with a serial number less than 20 bytes (I guess they do padding in that case). I also have a certificate from an Atmel device where I get a notice that the serial number is negative. For me pers

Re: [openssl-dev] [openssl.org #4171] Compile failure on OS X 10.7 clang with OpenSSL 1.0.2e

Hi, > https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=301a6dcd4590fb2f69d08259577e215b4cc3caa3#patch5 > added a check to see if it should use the ADDX instructions based on the > clang version. Unfortunately, on older versions of clang on OS X this check > incorrectly returns true

Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

Bonjour, Le 12 févr. 2016 à 01:11, Blumenthal, Uri - 0553 - MITLL mailto:u...@ll.mit.edu>> a écrit : Again, you are right, but what's the lesser evil‎ - being unable to use the new OpenSSL because it refuses to deal with the cert that some dim-witten TPM maker screwed up, or accept a certifica