On my MIPS n32 system, I've been unable to use either ssh or sshd since updating to net-misc/openssh-6.1_p1-r1. Both ssh and sshd appear to fail to parse ECDSA keys. Neither my old host keys work, nor do newly generated ssh keys. When I try to ssh out: flummox src # ssh nonplus key_ec_validate_public: received degenerate public key (nQ != infinity) key_read: key_from_blob AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBEJ9yM9GgOX3bi/RvSAgsztwQaMEgO4K40ofzZAG9AtNUHTEACZYbc77Yzm/FH2An4cT3zVwnNJ30FdYqgbZm00= failed Connection closed by 128.36.233.160 flummox src # Restarting sshd shows this in the console: flummox src # /etc/init.d/sshd restart Could not load host key: /etc/ssh/ssh_host_ecdsa_key * Stopping sshd ... [ ok ] Could not load host key: /etc/ssh/ssh_host_ecdsa_key * Starting sshd ... Could not load host key: /etc/ssh/ssh_host_ecdsa_key [ ok ] flummox src # and this appears in the logs when I try to connect to sshd: May 15 11:36:46 flummox sshd[31205]: error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key May 15 11:36:46 flummox sshd[31205]: SSH: Server;Ltype: Kex;Remote: 128.36.186.75-56964;Enc: arcfour256;MAC: hmac-md5;Comp: none [preauth] May 15 11:36:46 flummox sshd[31205]: error: key_ec_validate_public: received degenerate public key (nQ != infinity) [preauth] May 15 11:36:46 flummox sshd[31205]: fatal: kexecdh_server: invalid client public key [preauth] I've tried re-emerging dev-libs/openssl-1.0.1e-r1 and net-misc/openssh-6.1_p1-r1 with no change in behavior. Reproducible: Always Portage 2.1.11.63 (default/linux/mips/13.0/n32, gcc-4.7.2, glibc-2.17, 3.8.11 mips64) ================================================================= System uname: Linux-3.8.11-mips64-R5000_V2.1_FPU_V1.0-with-gentoo-2.2 KiB Mem: 188828 total, 28520 free KiB Swap: 2098172 total, 2092516 free Timestamp of tree: Tue, 14 May 2013 00:30:01 +0000 ld GNU ld (GNU Binutils) 2.23.1 app-shells/bash: 4.2_p45 dev-lang/python: 2.7.4, 3.2.4 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.11.8 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.69 sys-devel/automake: 1.12.6, 1.13.1 sys-devel/binutils: 2.23.1 sys-devel/gcc: 4.6.3, 4.7.2-r1 sys-devel/gcc-config: 1.8 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.9 (virtual/os-headers) sys-libs/glibc: 2.17 Repositories: gentoo ACCEPT_KEYWORDS="mips ~mips" ACCEPT_LICENSE="* -@EULA" CBUILD="mips64-unknown-linux-gnu" CFLAGS="-Os -march=r5000 -fomit-frame-pointer" CHOST="mips64-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-Os -march=r5000 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FCFLAGS="-Os -march=r5000 -fomit-frame-pointer" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="-Os -march=r5000 -fomit-frame-pointer" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j1" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/mnt/auto/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="berkdb bzip2 cli cracklib crypt cxx device-mapper gdbm gpm iconv ipv6 lzma memlimit mips modules mudflap ncurses nls nptl offensive pam pcre readline session ssl tcpd unicode zlib" ALSA_CARDS="au1x00" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-3" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" RUBY_TARGETS="ruby18 ruby19" USERLAND="GNU" VIDEO_CARDS="fbdev impact newport dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
"since updating to net-misc/openssh-6.1_p1-r1" So i presume the same key works with anything old than that?
I see the same issue after downgrading to net-misc/openssh-5.9_p1-r4, so this doesn't appear to be an openssh issue. I know that openssh stopped working sometime before Sat May 4. I had been catching up on emerge -uD updates, before that date. qlop shows: Sat Apr 27 21:04:00 2013 >>> sys-libs/timezone-data-2013c Sat Apr 27 21:06:19 2013 >>> sys-devel/autoconf-wrapper-13 Sat Apr 27 21:12:22 2013 >>> sys-apps/pciutils-3.2.0 Sat Apr 27 21:20:33 2013 >>> sys-process/lsof-4.87-r1 Sat Apr 27 21:31:39 2013 >>> media-libs/libpng-1.6.2 Sun Apr 28 00:06:17 2013 >>> dev-libs/openssl-1.0.1e-r1 Wed May 1 11:22:19 2013 >>> sys-apps/ethtool-3.9 Wed May 1 11:27:09 2013 >>> dev-perl/Text-Unidecode-0.40.0 Wed May 1 11:34:46 2013 >>> dev-perl/libintl-perl-1.210.0 Wed May 1 11:38:16 2013 >>> perl-core/File-Spec-3.400.0 Wed May 1 11:53:10 2013 >>> dev-libs/libtasn1-2.14 Wed May 1 11:56:35 2013 >>> perl-core/JSON-PP-2.272.20 Wed May 1 11:59:42 2013 >>> perl-core/CPAN-Meta-YAML-0.8.0 Wed May 1 12:04:00 2013 >>> perl-core/version-0.990.200 Wed May 1 12:07:44 2013 >>> perl-core/Scalar-List-Utils-1.270.0 Wed May 1 12:09:30 2013 >>> virtual/perl-Test-Simple-0.980.0-r2 Wed May 1 12:13:12 2013 >>> perl-core/IO-1.25 Wed May 1 12:14:54 2013 >>> virtual/perl-File-Temp-0.220.0-r2 Wed May 1 12:18:12 2013 >>> perl-core/ExtUtils-Manifest-1.610.0 Wed May 1 12:21:22 2013 >>> perl-core/ExtUtils-Install-1.540.0 Wed May 1 12:23:04 2013 >>> virtual/perl-ExtUtils-Command-1.170.0-r3 Wed May 1 12:24:45 2013 >>> virtual/perl-File-Spec-3.400.0 Wed May 1 12:26:27 2013 >>> virtual/perl-JSON-PP-2.272.20 Wed May 1 12:28:18 2013 >>> virtual/perl-CPAN-Meta-YAML-0.8.0 Wed May 1 12:29:59 2013 >>> virtual/perl-version-0.990.200 Wed May 1 12:31:41 2013 >>> virtual/perl-Scalar-List-Utils-1.270.0 Wed May 1 12:33:23 2013 >>> virtual/perl-IO-1.25 Wed May 1 12:35:05 2013 >>> virtual/perl-ExtUtils-Manifest-1.610.0 Wed May 1 12:36:55 2013 >>> virtual/perl-ExtUtils-Install-1.540.0 Wed May 1 13:12:45 2013 >>> dev-libs/libgcrypt-1.5.2 Wed May 1 13:49:08 2013 >>> dev-libs/nettle-2.7 Wed May 1 13:52:14 2013 >>> perl-core/Parse-CPAN-Meta-1.440.400 Wed May 1 13:55:24 2013 >>> perl-core/CPAN-Meta-Requirements-2.122.0 Wed May 1 13:57:17 2013 >>> virtual/perl-Parse-CPAN-Meta-1.440.400 Wed May 1 13:58:59 2013 >>> virtual/perl-CPAN-Meta-Requirements-2.122.0 Wed May 1 14:10:22 2013 >>> x11-libs/libdrm-2.4.44 Wed May 1 14:31:48 2013 >>> net-firewall/iptables-1.4.18 Wed May 1 14:44:43 2013 >>> x11-libs/libXi-1.7.1 Wed May 1 14:48:55 2013 >>> perl-core/ExtUtils-MakeMaker-6.640.0 Wed May 1 14:50:37 2013 >>> virtual/perl-ExtUtils-MakeMaker-6.640.0 Wed May 1 14:53:54 2013 >>> perl-core/CPAN-Meta-2.120.921 Wed May 1 14:55:36 2013 >>> virtual/perl-CPAN-Meta-2.120.921 Wed May 1 14:58:39 2013 >>> dev-perl/Unicode-EastAsianWidth-1.330.0 Wed May 1 15:26:03 2013 >>> dev-libs/libpcre-8.32-r1 Wed May 1 17:13:31 2013 >>> dev-lang/python-2.7.4 Wed May 1 18:31:27 2013 >>> dev-vcs/git-1.8.2.1 Wed May 1 19:10:49 2013 >>> sys-apps/texinfo-5.1 Wed May 1 21:04:06 2013 >>> dev-scheme/guile-1.8.8-r1 Wed May 1 21:08:33 2013 >>> net-misc/whois-5.0.24 Wed May 1 21:41:14 2013 >>> sys-devel/autogen-5.17.3 The only thing that jumps out at me is openssl. I'll attempt to downgrade openssl and see if that helps.
Downgrading to dev-libs/openssl-1.0.1e resolved the problem. flummox src # /etc/init.d/sshd restart * Stopping sshd ... [ ok ] * Starting sshd ... [ ok ] flummox src # flummox ssh # ssh baffle Password: Password: Last login: Thu May 16 20:29:14 EDT 2013 from loretta on pts/0 baffle ~ # ssh flummox Password: Last login: Sat May 4 11:28:40 EDT 2013 on tty1 flummox ~ # flummox ~ # qlop -l | tail -4 Wed May 15 01:36:46 2013 >>> dev-libs/openssl-1.0.1e-r1 Wed May 15 02:38:17 2013 >>> net-misc/openssh-6.1_p1-r1 Thu May 16 17:11:54 2013 >>> net-misc/openssh-5.9_p1-r4 Thu May 16 23:57:17 2013 >>> dev-libs/openssl-1.0.1e flummox ~ #
post the full build log of openssl-1.0.1e-r1 as an attachment might be that the optimized 64bit code does not work well on ABIs like n32 where sizeof(long) != sizeof(__uint128_t) that and the bad-mac-aes-ni.patch are the only differences between 1.0.1e-r1. so try building with only one of those at a time and see what fails.
Created attachment 348926 [details] openssl-1.0.1e-r1 build log
Build log attached. Next I will try compiling with one patch at a time.
Comment on attachment 348926 [details] openssl-1.0.1e-r1 build log so enable-ec_nistp_64_gcc_128 is being passed here which means your compiler should support __uint128_t (which is what we expected)
I compiled openssl-1.0.1e-r1 without the openssl-1.0.1e-bad-mac-aes-ni.patch, but am openssh is still unable to parse ecdsa keys. Next I'll add openssl-1.0.1e-bad-mac-aes-ni.patch to openssl-1.0.1e.ebuild and see if openssh works after that. I assume this is an appropriate way to test if the optimized 64bit code changes are causing the problem.
openssl-1.0.1e.ebuild with the openssl-1.0.1e-bad-mac-aes-ni.patch added works fine. Looks like the optimized 64-bit code is causing the ecdsa parsing problem.
at this point, someone with a mips box probably needs to debug this might want to try a gcc-4.6 and gcc-4.8 compiler too
It might worth masking this version for now until we fix this problem. @MIPS any objections to mask this version?
(In reply to Markos Chandras from comment #11) > It might worth masking this version for now until we fix this problem. @MIPS > any objections to mask this version? Please do so. I have not had the time to look at this.
+ 16 Jun 2013; Markos Chandras <hwoarang@gentoo.org> package.mask: + Mask openssl-1.0.1e-r1 per #469976 +
(In reply to Markos Chandras from comment #13) more specifically, that's arch/mips/package.mask, not the common package.mask
(In reply to SpanKY from comment #14) > (In reply to Markos Chandras from comment #13) > > more specifically, that's arch/mips/package.mask, not the common package.mask yeah, the change was correct i just diffed from the wrong directory. sorry about the confusion.
It is indeed ec_nistp_64_gcc_128 that's causing the problem. I can reproduce on mips64/n32. I can't reproduce in my mips64/n64 chroot. > might be that the optimized 64bit code does not work well on ABIs like n32 where sizeof(long) != sizeof(__uint128_t) long is 8 on n64 and 4 on n32. __uint128_t is 16. I think you'd have a hard time finding a platform where sizeof(long) == 16. It could be that a problem of the code assuming sizeof(long) == sizeof(void *).
I *think* this bug won't bite o32 ABI/userlands, just to add. I've been using ECDSA keys on my SGI O2 for some time now, and haven't run into this problem, even with the affected openssl installed.
(In reply to Matt Turner from comment #16) > It is indeed ec_nistp_64_gcc_128 that's causing the problem. I can reproduce > on mips64/n32. I can't reproduce in my mips64/n64 chroot. > > > might be that the optimized 64bit code does not work well on ABIs like n32 where sizeof(long) != sizeof(__uint128_t) > > long is 8 on n64 and 4 on n32. __uint128_t is 16. I think you'd have a hard > time finding a platform where sizeof(long) == 16. > > It could be that a problem of the code assuming sizeof(long) == sizeof(void > *). I believe the assumption is correct. I am next to zero familiar with the openssl code but i see the following in eg crypto/ec/ec_curve.c static void subtract_u64(u64* result, u64* carry, u64 v) { uint128_t r = *result; well this will not work on MIPS64/n32 since uint128_t = 16 and unsigned long long (u64) is 8. I presume this may cause problems later one during some arithmetic operations (just an assumption) Maybe we should disable the 64bit code in 32bit ABIs? Maybe x32 also has the same problem? Mike can you test x32?
This problem now exists on ppc64 as well. Again, downgrading from openssl-10.0.1e-r1 to openssl-1.0.1e resolved the issue. Portage 2.2.1 (default/linux/powerpc/ppc64/13.0/64bit-userland, gcc-4.6.3, glibc-2.15-r3, 3.9.11 ppc64) ================================================================= System uname: Linux-3.9.11-ppc64-PPC970MP,_altivec_supported-with-gentoo-2.2 KiB Mem: 2956736 total, 887956 free KiB Swap: 4194300 total, 4193972 free Timestamp of tree: Wed, 18 Sep 2013 14:00:01 +0000 ld GNU ld (GNU Binutils) 2.23.1 app-shells/bash: 4.2_p45 dev-lang/python: 2.7.5-r2, 3.2.5-r2 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.11.8 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.69 sys-devel/automake: 1.12.6, 1.13.4 sys-devel/binutils: 2.23.1 sys-devel/gcc: 4.6.3 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.9 (virtual/os-headers) sys-libs/glibc: 2.15-r3 Repositories: gentoo portage-overlay ACCEPT_KEYWORDS="ppc64" ACCEPT_LICENSE="* -@EULA" CBUILD="powerpc64-unknown-linux-gnu" CFLAGS="-O2 -pipe -mcpu=970 -mtune=970 -maltivec -mabi=altivec" CHOST="powerpc64-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe -mcpu=970 -mtune=970 -maltivec -mabi=altivec" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -pipe -mcpu=970 -mtune=970 -maltivec -mabi=altivec" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="-O2 -pipe -mcpu=970 -mtune=970 -maltivec -mabi=altivec" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j3 -l 2.0" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/mnt/auto/portage" PORTDIR_OVERLAY="/usr/local/portage-overlay" USE="acl altivec berkdb bzip2 cli cracklib crypt cxx dri fortran gdbm iconv ipv6 logrotate mbox modules mudflap ncurses nls nptl offensive openmp pam pcre ppc64 readline session ssl tcpd threads unicode zlib" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en en_US" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" QEMU_SOFTMMU_TARGETS="ppc64 ppc" RUBY_TARGETS="ruby19 ruby18" USERLAND="GNU" VIDEO_CARDS="dummy fbdev modesetting nouveau radeon" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, SYNC, USE_PYTHON
(In reply to Markos Chandras from comment #18) > (In reply to Matt Turner from comment #16) > > It is indeed ec_nistp_64_gcc_128 that's causing the problem. I can reproduce > > on mips64/n32. I can't reproduce in my mips64/n64 chroot. > > > > > might be that the optimized 64bit code does not work well on ABIs like n32 where sizeof(long) != sizeof(__uint128_t) > > > > long is 8 on n64 and 4 on n32. __uint128_t is 16. I think you'd have a hard > > time finding a platform where sizeof(long) == 16. > > > > It could be that a problem of the code assuming sizeof(long) == sizeof(void > > *). > > I believe the assumption is correct. I am next to zero familiar with the > openssl code but i see the following in eg crypto/ec/ec_curve.c > > static void subtract_u64(u64* result, u64* carry, u64 v) > { > uint128_t r = *result; > > well this will not work on MIPS64/n32 since uint128_t = 16 and unsigned long > long (u64) is 8. I presume this may cause problems later one during some > arithmetic operations (just an assumption) > > Maybe we should disable the 64bit code in 32bit ABIs? Maybe x32 also has the > same problem? Mike can you test x32? I will fix this by disabling the 64-bit code for mips && abi=n32 The rest of the arches can follow if they want to
Commit message: Disable 128bit math logic for now http://sources.gentoo.org/dev-libs/openssl/openssl-1.0.1e-r2.ebuild?rev=1.1
the ppc64 logic seems to generate bad ECDSA keys, but it can read good keys
breaks on s390x too
an expedited resolution for at least amd64 would be helpful; this impacts tor performance dramatically, at least according to the error message: [notice] We were built to run on a 64-bit CPU, with OpenSSL 1.0.1 or later, but with a version of OpenSSL that apparently lacks accelerated support for the NIST P-224 and P-256 groups. Building openssl with such support (using the enable-ec_nistp_64_gcc_128 option when configuring it) would make ECDH much faster.
why was this option dropped on all arches?
(In reply to Julian Ospald (hasufell) from comment #25) read the bug. the code has been shown to not be generally bit clean. the fact that it incidentally seems to work on some arches isn't good enough.
(In reply to SpanKY from comment #26) > (In reply to Julian Ospald (hasufell) from comment #25) > > read the bug. the code has been shown to not be generally bit clean. the > fact that it incidentally seems to work on some arches isn't good enough. No evidence was shown for it to pose risks on amd64 systems. Therefore, it should be enabled or enable-able on such systems for performance reasons.
(In reply to Alex Xu (Hello71) from comment #27) considering it manifests on many arches, it's a lot saner to keep it completely disabled than try to selectively enable. it's not worth the burden at this time.
Hey! I have an idea: how about making it a USE flag.
WAKE UP! This bug is stupid.
Is this bug reported to upstream? As I get by googling near all linux distros turn this on on amd64.
(In reply to Marckus Knight from comment #30) if you have nothing to contribute, then go away
lolwut? Nothing to contribute? Buddy, I'm sorry if you got annoyed but this bug is almost a year old and disabling these algorithms by default is just *not* a logical approach. The logical approach is what I suggested before: disable it on MIPS only, make it a useflag or whatever and close the bug. If everyone who has commit access just keeps sitting on their hands like they're doing now, don't blame it on me.
(In reply to Marckus Knight from comment #33) > The logical approach is what I suggested before: > disable it on MIPS only, make it a useflag or whatever and close the bug. We've been trying to get away from doing arch-specific things in ebuilds for a long while now. Especially on core system packages like OpenSSL. And it's not just MIPS that is affected, but PPC 64-bit and S390x systems. Hence, the disabling of the feature until it is fixed upstream. And given the recent happy fun with OpenSSL, there's no telling what's going to change upstream. The openssl-dev list came alive recently with patches from all sorts of people poking at the code, so maybe this problem will eventually resolve itself in a future version.
Ok, ok, maybe it was not very classy for me to moan about a _dis_abled OpenSSL "feature ;-)" So I admit. But only to that! <grin>
(In reply to Marckus Knight from comment #33) your pointless "lols" accomplish nothing, nor does complaining about other people not doing free work for you. if you wish to contribute, then do it in code, rather than spamming bugs with unhelpful posts. the feature is not enabled by default for anyone in upstream openssl, and read comment 26 and 28 again.
This bug appears to have been ... addressed. Openssl-1.0.1h Changes: "Add optional 64-bit optimized implementations of elliptic curves NIST-P224, NIST-P256, NIST-P521, with constant-time single point multiplication on typical inputs. Compiler support for the nonstandard type __uint128_t is required to use this (present in gcc 4.4 and later, for 64-bit builds)." Further, the code specified here, "sizeof(__uint128_t)" does not appear anywhere in the source tree. The ebuild still has this section commented out in the ebuild, however.
(In reply to Jack Daniels from comment #37) > This bug appears to have been ... addressed. > > Openssl-1.0.1h Changes: > "Add optional 64-bit optimized implementations of elliptic curves NIST-P224, > NIST-P256, NIST-P521, with constant-time single point multiplication on > typical inputs. Compiler support for the nonstandard type __uint128_t is > required to use this (present in gcc 4.4 and later, for 64-bit builds)." > > Further, the code specified here, "sizeof(__uint128_t)" does not appear > anywhere in the source tree. > > The ebuild still has this section commented out in the ebuild, however. Can anyone from MIPS, PPC, or s390x test this now? Uncommenting lines 132-137 and then trying to create and use ECDSA keys should be sufficient? Thanks.
Per darksde's request, I am pointing out that I have added an openssl ebuild to my overlay (hnaparst). The ebuild has a nist use flag, turned on by default.
(In reply to Jeremy Olexa (darkside) from comment #38) > (In reply to Jack Daniels from comment #37) > > This bug appears to have been ... addressed. > > > > Openssl-1.0.1h Changes: > > "Add optional 64-bit optimized implementations of elliptic curves NIST-P224, > > NIST-P256, NIST-P521, with constant-time single point multiplication on > > typical inputs. Compiler support for the nonstandard type __uint128_t is > > required to use this (present in gcc 4.4 and later, for 64-bit builds)." > > > > Further, the code specified here, "sizeof(__uint128_t)" does not appear > > anywhere in the source tree. > > > > The ebuild still has this section commented out in the ebuild, however. > > Can anyone from MIPS, PPC, or s390x test this now? Uncommenting lines > 132-137 and then trying to create and use ECDSA keys should be sufficient? > Thanks. It still does not seem to work on mips64/n32
Given there are use cases for this configuration option, and given that this is is appearing to be an architecture-specific issue at this time, would it be reasonable to make this a use flag that's enabled on x86 an disabled on MIPS by default? Or are we going the 'openssup upstream needs to fix this' route?
(In reply to Eric Gisse from comment #41) x86/x86_64 can easily hit alignment issues when dealing with SSE vectorization just like other arches. when gcc sees things like __int128, it assumes the variables are correctly aligned, and thus generate insns that require that alignment. when that alignment is violated at runtime, x86 code will happily crash just like arm/mips/s390/ppc/etc... this is why x86's ABI changed the stack alignment to 8 bytes -- to support SSE code generation. if openssl isn't aligning its buffers correctly, then hoping it continues to accidentally behave on x86_64 isn't sufficient. i'm not going to sign off on it.
I filed a but against tor related to a (IMO superfluous) warning message which encourage people to use OpenSSL with the mentioned NIST algorithms. Might somebody give the tor people a short feedback here : https://trac.torproject.org/projects/tor/ticket/14092#comment:1 if the issue is still present and where ?
Certificates are being issued from CA's with ECDSA. As other distro's have this enabled, this should probably be a useflag as I can no longer communicate to these servers using Gentoo amd64, and have to fall back to plain text. Is this still broken on MIPS? As EC is becoming more prevalent/popular, this is becoming a privacy issue.
(In reply to Kyle Sanderson from comment #44) i think you're confused about this bug. this has nothing to do with whether ECDSA is supported in openssl. ECDSA is enabled when you have USE=-bindist. this bug is purely about internal optimization.
(In reply to SpanKY from comment #45) > (In reply to Kyle Sanderson from comment #44) > > i think you're confused about this bug. This is correct. > ECDSA is enabled when you have USE=-bindist. > this bug is purely about internal optimization. Recompiling open(ssl/ssh) with this resolved my connectivity issues (including previous bouncing when it was downgraded to sslv3). Thanks for the tip.
Is it still the case? The current solution disables optimized code paths for all the arches, not only MIPS.
https://github.com/gentoo/gentoo/pull/5974 pull me plz
i don't think we should just re-enable this code and hope for the best. if this code breaks, it means we make systems unreachable or fails to correctly generate keys, both of which are pretty critical/basic functions of openssl. i.e. this needs someone to audit the code in question (we have references here) to make sure it's using properly defined/aligned buffers.
Srsly? Even Debian does this, and openssl people themselves don't have any prejudices about the code: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698447 https://wiki.openssl.org/index.php/Compilation_and_Installation
(In reply to Sergey 'L29Ah' Alirzaev from comment #50) i'm not sure what point you're trying to make. we have clear evidence & experience showing the code is buggy. we're not going to ignore that simply because it doesn't crash on your machine. pointing at openssl docs as some sort of proof that it's bug free is obviously not useful considering we know OpenSSL always has bugs. so until someone spends time on looking at the code, this bug isn't going to change status.
Can we follow Debian's lead here an enable this on amd64 only? See: https://salsa.debian.org/debian/openssl/-/blob/debian/unstable/debian/rules#L43
(In reply to matoro from comment #53) > Can we follow Debian's lead here an enable this on amd64 only? See: > https://salsa.debian.org/debian/openssl/-/blob/debian/unstable/debian/ > rules#L43 See: https://bugs.gentoo.org/469976#c26 https://bugs.gentoo.org/469976#c28 https://bugs.gentoo.org/469976#c34 https://bugs.gentoo.org/469976#c36 https://bugs.gentoo.org/469976#c42 https://bugs.gentoo.org/469976#c51 no, I don't think we should. It's the same strict aliasing in OpenSSL for me (which we've disabled since ~2005): https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-1.1.1q.ebuild#n120. Not unless it's proven to be fine.
(In reply to Sam James from comment #54) > (In reply to matoro from comment #53) > > Can we follow Debian's lead here an enable this on amd64 only? See: > > https://salsa.debian.org/debian/openssl/-/blob/debian/unstable/debian/ > > rules#L43 > > See: > https://bugs.gentoo.org/469976#c26 > https://bugs.gentoo.org/469976#c28 > https://bugs.gentoo.org/469976#c34 > https://bugs.gentoo.org/469976#c36 > https://bugs.gentoo.org/469976#c42 > https://bugs.gentoo.org/469976#c51 > > no, I don't think we should. It's the same strict aliasing in OpenSSL for me > (which we've disabled since ~2005): > https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-1.1. > 1q.ebuild#n120. > > Not unless it's proven to be fine. So is the reasoning that Debian only has one known set of CFLAGS to deal with, vs we have to anticipate things like LTO? If so could we go ahead and close this as not going to happen in Gentoo and state the reasoning?
(In reply to matoro from comment #55) > (In reply to Sam James from comment #54) > > (In reply to matoro from comment #53) > > > Can we follow Debian's lead here an enable this on amd64 only? See: > > > https://salsa.debian.org/debian/openssl/-/blob/debian/unstable/debian/ > > > rules#L43 > > > > See: > > https://bugs.gentoo.org/469976#c26 > > https://bugs.gentoo.org/469976#c28 > > https://bugs.gentoo.org/469976#c34 > > https://bugs.gentoo.org/469976#c36 > > https://bugs.gentoo.org/469976#c42 > > https://bugs.gentoo.org/469976#c51 > > > > no, I don't think we should. It's the same strict aliasing in OpenSSL for me > > (which we've disabled since ~2005): > > https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-1.1. > > 1q.ebuild#n120. > > > > Not unless it's proven to be fine. > > So is the reasoning that Debian only has one known set of CFLAGS to deal > with, vs we have to anticipate things like LTO? If so could we go ahead and > close this as not going to happen in Gentoo and state the reasoning? Debian can do what Debian wants. We're more conservative on some things. The code is bad and therefore whether or not it works is accidental. But yeah, I think what you say is a big part of it -- Debian can at least test the binaries they produce and be sure those are the only things being used, whereas we need to cater for various compiler versions and such. Let's close.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=67d5e8becd1d75d307864ad28a6fd2304be64602 commit 67d5e8becd1d75d307864ad28a6fd2304be64602 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-10-08 16:15:54 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-10-08 16:16:44 +0000 dev-libs/openssl: elaborate on ec_nistp_64_gcc_128 reasoning, forward comment to 3.x Bug: https://bugs.gentoo.org/469976 Signed-off-by: Sam James <sam@gentoo.org> dev-libs/openssl/openssl-1.0.2u-r1.ebuild | 19 ++++++++++--------- dev-libs/openssl/openssl-1.1.1q.ebuild | 14 ++++++++------ dev-libs/openssl/openssl-3.0.5.ebuild | 12 ++++++++++++ 3 files changed, 30 insertions(+), 15 deletions(-)
This might be actually fixed now (see https://github.com/openssl/openssl/issues/12247) but I'm in no rush to remove the change in the ebuild, especially not without actually checking.
(In reply to Sam James from comment #58) > This might be actually fixed now (see > https://github.com/openssl/openssl/issues/12247) but I'm in no rush to > remove the change in the ebuild, especially not without actually checking. (... because of the history of aliasing issues detailed in the ebuild.)
