From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Apr 15 01:19:50 2008 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 844CC28C2F6 for ; Tue, 15 Apr 2008 01:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N231Qs9lwfx0 for ; Tue, 15 Apr 2008 01:19:49 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 86D2128C2B3 for ; Tue, 15 Apr 2008 01:19:49 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4BBFE63B116; Tue, 15 Apr 2008 08:20:15 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by mail.netbsd.org (Postfix) with ESMTP id 2048963B10C for ; Tue, 15 Apr 2008 08:20:12 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id DFBDD4808D9 for ; Tue, 15 Apr 2008 19:16:03 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAJML8efDb1F for ; Tue, 15 Apr 2008 19:16:03 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id C831D4808D3 for ; Tue, 15 Apr 2008 19:16:03 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id C330119EC0B9 for ; Tue, 15 Apr 2008 19:16:03 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1JlfOd-0006HY-MW for ietf-ssh@NetBSD.org; Tue, 15 Apr 2008 19:16:03 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-ssh@NetBSD.org Subject: SSH non-compliance with FIPS 186 Message-Id: Date: Tue, 15 Apr 2008 19:16:03 +1200 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Someone's just pointed out a problem with SSH's use of DSA keys: The RFC claims that "signing and verifying using this key format is done according to the Digital Signature Standard [FIPS-186-2]", but either the spec or many (all?) implementations aren't actually compliant with FIPS 186. RFC 4253 hardcodes r and s as 160 bits, but this is only valid for FIPS 186-2 with a 1024-bit key size. Use of a key size > 1024 bits isn't allowed in FIPS 186-2. FIPS 186-3 does allow keys > 1024 bits but requires a corresponding increase in the size of q because increasing p while keeping q fixed at 160 bits provides no increase in security. The real problem is the problematic use of 'dss_signature_blob', which (unlike all other public-key related formats) uses a fixed size for the fields, with no provision for specifying length information. Since it's unlikely that everyone will change their implementations to limit DSA keys to 1024 bits as is required for FIPS compliance when q = 160 bits, I'd like to propose a correction to the spec with a new DSA sig format: string "ssh-dss-fips" // Or whatever mpint r mpint s to allow use with with keys generated according to FIPS 186. Comments? Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Apr 15 05:22:41 2008 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32AAC28C3D4 for ; Tue, 15 Apr 2008 05:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0Iog06q9KeD for ; Tue, 15 Apr 2008 05:22:37 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 0E7473A6EC2 for ; Tue, 15 Apr 2008 05:22:37 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E62F863B21F; Tue, 15 Apr 2008 12:23:01 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from mail.lysator.liu.se (unknown [IPv6:2001:6b0:17:f0a0:202:b3ff:fe35:7167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTP id 76A2C63B219 for ; Tue, 15 Apr 2008 12:22:59 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id D30DF200A27C; Tue, 15 Apr 2008 14:22:56 +0200 (CEST) Received: from mail.lysator.liu.se ([127.0.0.1]) by localhost (lenin.lysator.liu.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 18394-01-52; Tue, 15 Apr 2008 14:22:56 +0200 (CEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id 3C81A200A287; Tue, 15 Apr 2008 14:22:56 +0200 (CEST) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.13.4+Sun/8.13.4) with ESMTP id m3FCMtcs011063; Tue, 15 Apr 2008 14:22:55 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.13.4+Sun/8.12.8/Submit) id m3FCMrcI011062; Tue, 15 Apr 2008 14:22:53 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: ietf-ssh@NetBSD.org Subject: Re: SSH non-compliance with FIPS 186 References: From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Tue, 15 Apr 2008 14:22:53 +0200 In-Reply-To: (Peter Gutmann's message of "Tue, 15 Apr 2008 19:16:03 +1200") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > Someone's just pointed out a problem with SSH's use of DSA keys: The RFC > claims that "signing and verifying using this key format is done according to > the Digital Signature Standard [FIPS-186-2]", but either the spec or many > (all?) implementations aren't actually compliant with FIPS 186. RFC 4253 > hardcodes r and s as 160 bits, but this is only valid for FIPS 186-2 with a > 1024-bit key size. I haven't followed the updates of DSA, so my take has been that DSA with key size larger than 1024 is non-standard, and of questionable value since the size of the q subgroup is the same. I'd recommend anybody who needs larger keys to use RSA instead. > Use of a key size > 1024 bits isn't allowed in FIPS 186-2. FIPS > 186-3 does allow keys > 1024 bits but requires a corresponding > increase in the size of q because increasing p while keeping q fixed > at 160 bits provides no increase in security. Could you give a brief description? As far as I remember, the 160 bits in DSA is intimately tied to the digest size of sha1. Do the updated DSA specify other hash functions (sha-256 or sha-512)? > The real problem is the problematic use of 'dss_signature_blob', which (unlike > all other public-key related formats) uses a fixed size for the fields, with > no provision for specifying length information. I remember I commented on that wart in the early days of the wg, and that it was motivated by compatibility with some existing crypto toolkits. > I'd like to propose a > correction to the spec with a new DSA sig format: > > string "ssh-dss-fips" // Or whatever > mpint r > mpint s > > to allow use with with keys generated according to FIPS 186. Comments? It ought to get a new signature algorithm id as well. Regards, /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Apr 15 06:36:05 2008 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07B1528C3E4 for ; Tue, 15 Apr 2008 06:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dEfQe3Jj5uw for ; Tue, 15 Apr 2008 06:36:00 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 8131F28C3D4 for ; Tue, 15 Apr 2008 06:36:00 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 605B363B248; Tue, 15 Apr 2008 13:36:26 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by mail.netbsd.org (Postfix) with ESMTP id E89EA63B220 for ; Tue, 15 Apr 2008 13:36:22 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 08EBF480543; Wed, 16 Apr 2008 01:36:21 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ac-a4Lsiz95j; Wed, 16 Apr 2008 01:36:20 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id D8CB248053C; Wed, 16 Apr 2008 01:36:20 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id CD31119EC0B9; Wed, 16 Apr 2008 01:36:18 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1JllKc-0007QX-Ma; Wed, 16 Apr 2008 01:36:18 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: nisse@lysator.liu.se, pgut001@cs.auckland.ac.nz Subject: Re: SSH non-compliance with FIPS 186 Cc: ietf-ssh@NetBSD.org In-Reply-To: Message-Id: Date: Wed, 16 Apr 2008 01:36:18 +1200 Sender: ietf-ssh-owner@NetBSD.org Precedence: list nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) writes: >pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: >> Someone's just pointed out a problem with SSH's use of DSA keys: The RFC >> claims that "signing and verifying using this key format is done according to >> the Digital Signature Standard [FIPS-186-2]", but either the spec or many >> (all?) implementations aren't actually compliant with FIPS 186. RFC 4253 >> hardcodes r and s as 160 bits, but this is only valid for FIPS 186-2 with a >> 1024-bit key size. > >I haven't followed the updates of DSA, so my take has been that DSA with key >size larger than 1024 is non-standard, and of questionable value since the >size of the q subgroup is the same. FIPS 186 allows key sizes up to either 3072 or 4096 bits. [Pause] It's 3072 bits, with a corresponding subgroup size of 256 bits (I guess they were nervous about SHA-512 and so stopped there :-). >> Use of a key size > 1024 bits isn't allowed in FIPS 186-2. FIPS >> 186-3 does allow keys > 1024 bits but requires a corresponding >> increase in the size of q because increasing p while keeping q fixed >> at 160 bits provides no increase in security. > >Could you give a brief description? As far as I remember, the 160 bits in DSA >is intimately tied to the digest size of sha1. It's a triplet { p-size, q-size, hash-size } where hash-size == q-size. If you increase p-size without a corresponding increase in q-size/hash-size you get no effective increase in security. I've always seen the details on this ascribed to an unnamed paper by Michael Wiener, but the closest I can find is "On Diffie-Hellman Key Agreement with Short Exponents", which Citeseer has here: http://citeseer.ist.psu.edu/734853.html. It doesn't provide details on calculation of q for p > 1024 bits, although it does explain the reason for the magic value of 160 bits. (This is actually rather interesting, there's no original source that I can identify for the table of p vs. q values. As far as I can see all the online versions were taken from the table I used in my code, and I got that from Colin Plumb. Hmm...). >Do the updated DSA specify other hash functions (sha-256 or sha-512)? Yes, you have to use a hash function of size >= the subgroup size. So SHA-256 covers all the options up to 3072-bit keys. >> I'd like to propose a >> correction to the spec with a new DSA sig format: >> >> string "ssh-dss-fips" // Or whatever >> mpint r >> mpint s >> >> to allow use with with keys generated according to FIPS 186. Comments? > >It ought to get a new signature algorithm id as well. Having looked at it again, I'd propose "ssh-dsa". "ssh-dss" has always bugged me because the NIST/FIPS digital signature standard (DSS) covers a whole range of algorithms and not just DSA. So RSA is "ssh-dss" just as much as DSA is. "ssh-dsa" makes it explicit what the algorithm being used really is, and updates it to be compliant with current versions of DSA. If anyone wants to make the change and do some interop testing, let me know. Shouldn't be too hard, just advertise "ssh-dsa" in the handshake and add another case statement for the sig format. Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Apr 15 18:28:17 2008 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 574E73A6AA6 for ; Tue, 15 Apr 2008 18:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ui3EQuJMgCrT for ; Tue, 15 Apr 2008 18:28:16 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id B25BD3A6EA4 for ; Tue, 15 Apr 2008 18:28:15 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id DAEFD63B116; Wed, 16 Apr 2008 01:28:42 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from natsu.mindrot.org (natsu.mindrot.org [203.209.195.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTP id C0F0763B101 for ; Wed, 16 Apr 2008 01:28:41 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 1002) id A4A7869AFC; Wed, 16 Apr 2008 09:33:29 +1000 (EST) Received: from fuyu.mindrot.org (fuyu.mindrot.org [203.217.30.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "fuyu.mindrot.org", Issuer "StartCom Class 1 Primary Intermediate Free CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTP id 84B3169AA5; Wed, 16 Apr 2008 09:33:25 +1000 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id B13ABA4F67; Wed, 16 Apr 2008 09:33:24 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id AC059A4F54; Wed, 16 Apr 2008 09:33:24 +1000 (EST) Date: Wed, 16 Apr 2008 09:33:24 +1000 (EST) From: Damien Miller To: Peter Gutmann cc: ietf-ssh@NetBSD.org Subject: Re: SSH non-compliance with FIPS 186 In-Reply-To: Message-ID: References: User-Agent: Alpine 1.00 (BSO 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, 15 Apr 2008, Peter Gutmann wrote: > The real problem is the problematic use of 'dss_signature_blob', which > (unlike all other public-key related formats) uses a fixed size for > the fields, with no provision for specifying length information. Since > it's unlikely that everyone will change their implementations to limit > DSA keys to 1024 bits as is required for FIPS compliance when q = 160 > bits, I'd like to propose a correction to the spec with a new DSA sig > format: > > string "ssh-dss-fips" // Or whatever > mpint r > mpint s > > to allow use with with keys generated according to FIPS 186. Comments? Should this include the hash algorithm too? You could figure it out from the lengths of r and s, but things could become ambiguous if a future DSA spec lists new hashes with 160 or 256 bit digest lengths. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Apr 15 23:05:48 2008 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 965933A6C23 for ; Tue, 15 Apr 2008 23:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3X6oZvCVYkw for ; Tue, 15 Apr 2008 23:05:47 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 1BEDB3A6BDD for ; Tue, 15 Apr 2008 23:05:47 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 003BE63B115; Wed, 16 Apr 2008 06:06:15 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by mail.netbsd.org (Postfix) with ESMTP id 63CB263B103 for ; Wed, 16 Apr 2008 06:06:11 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id E89B7480818; Wed, 16 Apr 2008 18:06:09 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHRNM2FDhDmN; Wed, 16 Apr 2008 18:06:09 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id CF5B1480817; Wed, 16 Apr 2008 18:06:09 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 3902919EC0B9; Wed, 16 Apr 2008 18:06:09 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1Jm0mX-0003s7-3D; Wed, 16 Apr 2008 18:06:09 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: djm@mindrot.org, pgut001@cs.auckland.ac.nz Subject: Re: SSH non-compliance with FIPS 186 Cc: ietf-ssh@NetBSD.org In-Reply-To: Message-Id: Date: Wed, 16 Apr 2008 18:06:09 +1200 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Damien Miller writes: >Should this include the hash algorithm too? You could figure it out from the >lengths of r and s, but things could become ambiguous if a future DSA spec >lists new hashes with 160 or 256 bit digest lengths. Good point, the current DSA spec (FIPS 186-3 [0]) already lists hashes other than SHA-1 so yes, there should be a provision for extra hashes (this also provides an escape hatch if the ongoing gnawing at SHA-1 is finally successful). At the moment there's only SHA-1 and SHA-256 specified, so I'd suggest: "ssh-dsa" // Implies the traditional "with SHA-1" "ssh-dsa-sha256" // Self-explanatory with possibly a note to implementors to expect "ssh-dsa-sha512" at some point in the future, and then "ssh-dsa-ahs" in 2011 when the Advanced Hash Standard appears. SHA-512 is awkward to implement on non-64-bit processors so I wouldn't make it mandatory, as indeed FIPS 186 doesn't. (If people don't object to excessive tinkering, defining an equivalent for RSA by slipping in a "ssh-rsa-sha256" might also be useful). Peter. [0] The NIST web pages are somewhat out of date in places, the current 186-3 is listed as a draft with comments closing in June 2006, but the rumblings I've heard are that either you need to be 186-3 ready now or very shortly. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Apr 15 23:32:21 2008 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6919628C23C for ; Tue, 15 Apr 2008 23:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcGV4OCUqdMg for ; Tue, 15 Apr 2008 23:32:20 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 72E7B28C1F7 for ; Tue, 15 Apr 2008 23:32:20 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 09E7E63B123; Wed, 16 Apr 2008 06:32:50 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from mail.lysator.liu.se (unknown [IPv6:2001:6b0:17:f0a0:202:b3ff:fe35:7167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTP id 4FDEF63B101 for ; Wed, 16 Apr 2008 06:32:47 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id D2CF8200A280; Wed, 16 Apr 2008 08:32:44 +0200 (CEST) Received: from mail.lysator.liu.se ([127.0.0.1]) by localhost (lenin.lysator.liu.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 05531-01-17; Wed, 16 Apr 2008 08:32:44 +0200 (CEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id 5EF1E200A27E; Wed, 16 Apr 2008 08:32:44 +0200 (CEST) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.13.4+Sun/8.13.4) with ESMTP id m3G6WhvE004813; Wed, 16 Apr 2008 08:32:43 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.13.4+Sun/8.12.8/Submit) id m3G6WbYi004812; Wed, 16 Apr 2008 08:32:37 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: djm@mindrot.org, ietf-ssh@NetBSD.org Subject: Re: SSH non-compliance with FIPS 186 References: From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Wed, 16 Apr 2008 08:32:37 +0200 In-Reply-To: (Peter Gutmann's message of "Wed, 16 Apr 2008 18:06:09 +1200") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: >>Should this include the hash algorithm too? You could figure it out from the >>lengths of r and s, but things could become ambiguous if a future DSA spec >>lists new hashes with 160 or 256 bit digest lengths. Agree, I was just about to suggest that. And if r and s are coded as mpint, rather than fixed size strings, then you can't infer the hash size from the sizes of r and s in a 100% reliable manner, only with a very high probability... > At the moment there's only SHA-1 and SHA-256 specified, so I'd > suggest: > > "ssh-dsa" // Implies the traditional "with SHA-1" I'm not sure it makes much sense to introduce this alternative to the old "ssh-dss" now, even if we all agree the old way is ugly. And if you really want to introduce it, why not use "ssh-dsa-sha1", to be explicit? > "ssh-dsa-sha256" // Self-explanatory This makes a lot of sense, and seems like a useful addition. And about the details of the naming (one of the great unsolved problems in CS ;-), the "ssh-"-prefix seems somewhat redundant, but maybe it's good for consistency. /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Apr 15 23:46:05 2008 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 882FC28C3B7 for ; Tue, 15 Apr 2008 23:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[AWL=-0.377, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZxpbF7H806o for ; Tue, 15 Apr 2008 23:46:04 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id BED573A6C0D for ; Tue, 15 Apr 2008 23:46:00 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id AB40F63B103; Wed, 16 Apr 2008 06:46:29 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 29EE263B101 for ; Wed, 16 Apr 2008 06:46:27 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id CAA20135; Wed, 16 Apr 2008 02:46:26 -0400 (EDT) From: der Mouse Message-Id: <200804160646.CAA20135@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Wed, 16 Apr 2008 02:30:45 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: SSH non-compliance with FIPS 186 In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org Precedence: list > SHA-512 is awkward to implement on non-64-bit processors Hmm? I didn't find it so. It would have been awkward without an at-least-64-bit integer data type, but, given that, it doesn't much matter - well, not to awkwardness, at least - how much juggling the compiler has to do behind the scenes to implement that data type. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 16 09:23:07 2008 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C6953A6A54 for ; Wed, 16 Apr 2008 09:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fj+-yclL2b1g for ; Wed, 16 Apr 2008 09:23:06 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 676023A6D33 for ; Wed, 16 Apr 2008 09:23:05 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C8C4C63B123; Wed, 16 Apr 2008 16:23:33 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by mail.netbsd.org (Postfix) with ESMTP id 5B2B863B103 for ; Wed, 16 Apr 2008 16:23:31 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id D17561877A; Thu, 17 Apr 2008 03:21:47 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whTmQuMzmYBP; Thu, 17 Apr 2008 03:21:47 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 8349D185D2; Thu, 17 Apr 2008 03:21:47 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 8C63019EC0B9; Thu, 17 Apr 2008 03:21:46 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1Jm9SE-0004tg-Du; Thu, 17 Apr 2008 03:21:46 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: nisse@lysator.liu.se, pgut001@cs.auckland.ac.nz Subject: Re: SSH non-compliance with FIPS 186 Cc: djm@mindrot.org, ietf-ssh@NetBSD.org In-Reply-To: Message-Id: Date: Thu, 17 Apr 2008 03:21:46 +1200 Sender: ietf-ssh-owner@NetBSD.org Precedence: list nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) writes: >> At the moment there's only SHA-1 and SHA-256 specified, so I'd >> suggest: >> >> "ssh-dsa" // Implies the traditional "with SHA-1" > >I'm not sure it makes much sense to introduce this alternative to the old >"ssh-dss" now, even if we all agree the old way is ugly. I can think of two reasons, firstly it's a general-purpose mechanism so the only extra overhead in supporting "ssh-dsa-sha1" alongside "ssh-dsa-sha256" is the addition of an extra string to a lookup table (that is, the same code that does "ssh-dsa-sha256" also does "ssh-dsa-sha1"), and secondly because FIPS 186 doesn't say that the hash size has to match q exactly but merely that you use the leftmost (sizeof-q) bits of the hash, so that you could use e.g. a 1536- bit DSA key with SHA-1. Another way of looking at this is that you need about 2800 bits of key to match 256 bits of security in your hash function, so you may not want to default to SHA-256 for all keys over 1024 bits. (Actually I'm not terribly fussed over this, it just seemed that since support for "ssh-dsa-sha1" comes free with "ssh-dsa-sha256" there didn't seem to be a strong reason not to do it). >And if you really want to introduce it, why not use "ssh-dsa-sha1", to be >explicit? Sure, sounds good to me. der Mouse writes: >> SHA-512 is awkward to implement on non-64-bit processors > >Hmm? I didn't find it so. It would have been awkward without an at- >least-64-bit integer data type, but, given that, it doesn't much matter - >well, not to awkwardness, at least - how much juggling the compiler has to do Sorry, I meant "systems where the compiler can't fake 64-bit support". There are still quite a number of non-mainstream and embedded systems where the largest supported data type is 32 bits, and trying to build this yourself using toothpicks and rubber bands isn't much fun. It also becomes quite a maintenance hassle because you end up having to support two lots of code, one of which mostly only gets built on wierd platforms with limited debugging support. Peter.