From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Jun 2 07:32:02 2010 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 43CA53A6826 for ; Wed, 2 Jun 2010 07:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.651 X-Spam-Level: X-Spam-Status: No, score=0.651 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 gv19ZydSTDKB for ; Wed, 2 Jun 2010 07:32:00 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id DC6F43A6827 for ; Wed, 2 Jun 2010 07:31:56 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id BFD4263B1B4; Wed, 2 Jun 2010 14:31:33 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from stalhein.lysator.liu.se (stalhein.lysator.liu.se [130.236.254.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 5D76163B1AF for ; Wed, 2 Jun 2010 14:31:30 +0000 (UTC) Received: from stalhein.lysator.liu.se (localhost [127.0.0.1]) by stalhein.lysator.liu.se (8.14.4+Sun/8.14.4) with ESMTP id o52DJq8P013107; Wed, 2 Jun 2010 15:19:52 +0200 (MEST) Received: (from nisse@localhost) by stalhein.lysator.liu.se (8.14.4+Sun/8.14.4/Submit) id o52DJoj4013106; Wed, 2 Jun 2010 15:19:50 +0200 (MEST) X-Authentication-Warning: stalhein.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: ietf-ssh@NetBSD.org Subject: Re: SSH non-compliance with FIPS 186 References: Date: Wed, 02 Jun 2010 15:19:50 +0200 In-Reply-To: (Peter Gutmann's message of "Wed, 16 Apr 2008 01:36:18 +1200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >From an old discussion on the FIPS 186-3 extensions of DSA... pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > 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. After looking things up (using the somewhat old Handbook of Applied Cryptography as my main reference), it seems that the best known algorithm for discrete logarithms in the small "q-size" subgroup is Pollard \rho or baby-step giant-step, both of complexy O(sqrt(group size)), so that would be roughly 2^80 steps for dsa-sha1 and 2^128 steps for dsa-sha256. While for the large group, the best method is index calculus / number field sieve, which is of roughly the same complexity as factoring numbers of the same size. So the proper ratio between p-size and q-size is related to the relative efficiency of the number field sieve and Pollard \rho. To me, it seems prudent to discourage use of dsa-sha1, for 3 reasons: * General progress on attacking sha1. * 2^80 complexity of discrete logarithm in the small group having uncomfortably small security margin. * Likewise, if complexity of discrete logarithms in the large group is comparable to factoring 1024 bit numbers, that's also not a very large margin to what's practical (and 1024 bit RSA also is not recommended for keys generated today, is it?) So I'd recommend to instead use rsa or dsa-256 with key size of at least 1536 bits. Is this a resonable interpretation of the current state of the art? To me, this is a strong motivation for getting some other good signature algorithm in besides rsa, to be able to move quickly if some serios problem is discovered with rsa (in terms of either implementation bugs or something more fundamental). Should we also look into rsa using some other hash function than sha1? >>> 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. > 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. I'm about to implement this. Does anybody have a server that already implements it, and a spec for the details? Otherwise, here's what I'm considering implementing: : Signature algorithm: DSA, as defined in FIPS 186-3, using SHA256 for : the hash function. : : Algorithm name: "ssh-dsa-sha256@lysator.liu.se" (suggested name : "ssh-dsa-sha256" if/when registered with iana). Rational: "ssh-" : prefix because we use ssh-specific encodings of keys and signatures. : dsa since that's the name of the algorithm, and then "-sha256" since : the algorithm description is parameterized by the hash function. : : Public-key format: : : string "ssh-dsa-sha256" : mpint p : mpint q : mpint g : mpint y : : Except for the name, this syntax is the same as for "ssh-dss". The : prime q must be exactly 256 bits. The prime p is expected to be of : size between 1024 and 3072 bits (do we need to specify exactly which : key sizes should be supported by an implementation advertising this : signature algorithm? We don't do that for any other signature : algorithm, as far as I know). : : Signature format: : : string "ssh-dsa-sha256" : string dsa_signature_blob : : The dsa_signature blob is a string with a 64-octets payload, where the : first 32 represent r, unsigned and in network byte order, and the next : 32 octets represent s. (I'd prefer to depart from this : "signature_blob" thing and instead use separate mpints for r and s, : but I think it's more important to stay consistent with the other : signature algorithms. : : As far as I'm aware, there's no need to add any local-suffix to the : names included in the key and signature formats. Any comments or advice appreciated. Some other comments after implementing the signature algorithm itself: FIPS 186-3 deprecates the old method of generating keys. The new recommended method (for some key sizes) uses an algorithm referred to as "Shawe-Taylor". I have not been able to find that name in the literature. Instead, I implemented key generation based on Maurer's algorithm (which seems to be more or less the same thing) for generating "provable" primes, based on the simplest special case of Pocklington's theorem. I have not been able to find any official or agreed upon test vectors for dsa-sha256. This is a serious problem for testing. If anybody on this list knows about official test vectors, or can provide some test signatures from some other implementation, I'd be grateful. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Jun 2 08:57:32 2010 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 E0BCC3A6826 for ; Wed, 2 Jun 2010 08:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 Ck8he3PlPZSR for ; Wed, 2 Jun 2010 08:57:30 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 7E0BF3A6A07 for ; Wed, 2 Jun 2010 08:57:30 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A51EA63B1B2; Wed, 2 Jun 2010 15:57:09 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by mail.netbsd.org (Postfix) with ESMTP id 6ED5263B1B0 for ; Wed, 2 Jun 2010 15:57:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1275494228; x=1307030228; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20nisse@lysator.liu.se,=20pgut001@cs.auckland.ac.nz |Subject:=20Re:=20SSH=20non-compliance=20with=20FIPS=2018 6|Cc:=20ietf-ssh@NetBSD.org|In-Reply-To:=20|Message-Id:=20|Date:=20Thu,=2003=20Ju n=202010=2002:24:52=20+1200; bh=UBOfRmDI6KMLbtxA0oYMZj1W3y776zeTjpigAR1Q1so=; b=tG6O70DHeE7fOgJnwuYx9rO7FQ4in72pypuuuGkakEvzdUX6DkreS1he xe9yO0lI13JCbLA1yJqGjgMXU6XM48QRMW73ABKFHURCct1CF99WHBMAM wLvkz97CeYBs2MquaUiCyY/qCPeXmWVD2yO740k7oXlljTLH0SyWjYOUU 4=; X-IronPort-AV: E=Sophos;i="4.53,347,1272801600"; d="scan'208";a="9183881" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.207.92 - Outgoing - Outgoing Received: from wintermute02.cs.auckland.ac.nz ([130.216.207.92]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 03 Jun 2010 02:24:52 +1200 Received: from pgut001 by wintermute02.cs.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1OJosG-0006Cd-Ht; Thu, 03 Jun 2010 02:24:52 +1200 From: 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: Thu, 03 Jun 2010 02:24:52 +1200 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) writes: >So I'd recommend to instead use rsa or dsa-256 with key size of at least 1536 >bits. Is this a resonable interpretation of the current state of the art? That's DSA2, which is on pretty unstable ground, AFAIK nothing of any significance implements this (in fact only OpenPGP really mentions it, and it's disabled by default in implementations of that because interoperability is likely to be... limited). >I'm about to implement this. Does anybody have a server that already >implements it, and a spec for the details? Otherwise, here's what I'm >considering implementing: I could implement it fairly quickly. >(I'd prefer to depart from this "signature_blob" thing and instead use >separate mpints for r and s, but I think it's more important to stay >consistent with the other signature algorithms. I would be a lot happier with proper mpints, otherwise for each new hash function (well, hash block size) you need to define a new signature-blob format. If you use mpints then they'll automatically adjust themselves to any size of hash function. >I have not been able to find any official or agreed upon test vectors for >dsa-sha256. This is a serious problem for testing. If anybody on this list >knows about official test vectors, or can provide some test signatures from >some other implementation, I'd be grateful. Yup, see above. Despite the security concerns, I'd recommend, for interop- testing purposes, using standard DSA with SHA1, otherwise you're going to end up having to interop-test both DSA2 and the new signature format at the same time. Peter. From hudds@cctc.net Thu Jun 17 17:14:10 2010 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 800383A6834 for ; Thu, 17 Jun 2010 17:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.809 X-Spam-Level: ** X-Spam-Status: No, score=2.809 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, SARE_SUB_GOOD_DAY=0.679, US_DOLLARS_3=0.63] 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 IL-bCqu4DHiX for ; Thu, 17 Jun 2010 17:14:08 -0700 (PDT) Received: from mailadmin.cctc.net (mail.cctc.net [208.6.233.27]) by core3.amsl.com (Postfix) with ESMTP id E65833A67FC for ; Thu, 17 Jun 2010 17:14:02 -0700 (PDT) Received: from [41.86.134.207] (account hudds@cctc.net) by mailadmin.cctc.net (CommuniGate Pro WEBUSER 5.2.11) with HTTP id 67575125; Thu, 17 Jun 2010 19:14:22 -0500 From: Mr Ling Tia Subject: Good Day X-Mailer: CommuniGate Pro WebUser v5.2.11 Date: Thu, 17 Jun 2010 19:14:22 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8;format="flowed" Content-Transfer-Encoding: 8bit To: undisclosed-recipients:; Good Day, My name is Ling Tia Liu; I work with Industrial and Commercial Bank of China, Hong Kong. I have a business proposal in the tune of $21,300,000.00 US Dollars, to be transferred out of my bank with your assistance. After the successful transfer, we shall share in ratio of 40% for you and 60% for me. Should you be interested, please respond to my letter immediately, so we can commence all arrangements and I will give you more information on the project and how we would handle it.Please treat this business with utmost confidentiality. You can contact me on my private email:(lingtia@discuz.org) along with the Following information's for documentation purpose: (1) Full names: (2) Private phone number: (3) Current residential address: (4) Occupation: (5) Age and Sex: I look forward to hearing from you. Kind Regards, Tai Ling