From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu May 4 23:04:58 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7E1129454 for ; Thu, 4 May 2017 23:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJOkyMkJVZn0 for ; Thu, 4 May 2017 23:04:57 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2615A12944C for ; Thu, 4 May 2017 23:04:57 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id B6A0584DA7; Fri, 5 May 2017 06:04:53 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 6BA5184DA4; Fri, 5 May 2017 06:04:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 4A12284D9C for ; Thu, 4 May 2017 20:57:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id MuUSwWWsEy8o for ; Thu, 4 May 2017 20:57:23 +0000 (UTC) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 9BDD084D81 for ; Thu, 4 May 2017 20:57:19 +0000 (UTC) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from thunderbird-2.linux.ds.cam.ac.uk ([131.111.9.24]:59270) by ppsw-41.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) id 1d6NoK-0001gk-Qi (Exim 4.89) (return-path ); Thu, 04 May 2017 21:57:16 +0100 Received: from bjh21 (helo=localhost) by thunderbird-2.linux.ds.cam.ac.uk with local-esmtp (Exim 4.86_2) (envelope-from ) id 1d6NoK-0007Yt-6M; Thu, 04 May 2017 21:57:16 +0100 Date: Thu, 4 May 2017 21:57:16 +0100 (BST) From: Ben Harris To: "Mark D. Baushke" cc: denis bider , ietf-ssh@netbsd.org, curdle Subject: Re: [Curdle] eddsa25519 & eddsa448 for use with SSH In-Reply-To: <17136.1493159459@eng-mail01.juniper.net> Message-ID: References: <53117.1493095177@eng-mail01.juniper.net> <17136.1493159459@eng-mail01.juniper.net> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list List-Unsubscribe: On Tue, 25 Apr 2017, Mark D. Baushke wrote: > denis bider writes: > >> I believe the spec for ssh-ed25519 is already an active draft under >> the purview of Curdle: >> >> https://tools.ietf.org/html/draft-ietf-curdle-ssh-ed25519-00 > > You are correct. This one is expired. I wonder if Ben Harris is likely > to resubmit it? I'm not in any imminent danger of doing so. If someone were to pick it up and make it useful I would be very happy, but I'm a bit short of energy for navigating bureaucracies at the moment. -- Ben Harris From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed May 10 09:18:39 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B5F129C66 for ; Wed, 10 May 2017 09:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id daewEKX0EC7V for ; Wed, 10 May 2017 09:18:38 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E54D7129C56 for ; Wed, 10 May 2017 09:18:37 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id D533D85569; Wed, 10 May 2017 16:18:35 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id CFA1784DA8 for ; Wed, 10 May 2017 16:18:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.netbsd.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id e0XYmIuY1kVG for ; Wed, 10 May 2017 16:18:33 +0000 (UTC) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on072e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe41::72e]) by mail.netbsd.org (Postfix) with ESMTP id 9344484CDB for ; Wed, 10 May 2017 16:18:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9LR1jh7Y8ILJ3AtRCwJ57z8LHtDnqEmvUJQDfYfRJVw=; b=TuMVqdLPhmNWRgWGTd3S3QYrQBuUNtWC+joIEpcoDoEq0oUvoG2EK7V14EgohDa9fTPqNpCT7qIKLgPj6utWQtkUhS+eKFvF1SDzKEcBW4aQbtmJCo0vClh5aEjb2+z7Pc4B19nbrlDRpifqETiDWJYd2HFelyl60MZL4iIKC0g= Received: from BN6PR05MB2916.namprd05.prod.outlook.com (10.173.18.137) by BN6PR05MB2916.namprd05.prod.outlook.com (10.173.18.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Wed, 10 May 2017 16:18:29 +0000 Received: from BN6PR05MB2916.namprd05.prod.outlook.com ([10.173.18.137]) by BN6PR05MB2916.namprd05.prod.outlook.com ([10.173.18.137]) with mapi id 15.01.1084.017; Wed, 10 May 2017 16:18:29 +0000 From: Mark Baushke To: "ietf-ssh@NetBSD.org" CC: "curdle@ietf.org" , Eric Rescorla Subject: ssh-ed25519 implementations Thread-Topic: ssh-ed25519 implementations Thread-Index: AQHSyakPmB025K0AyEG1vsM36lGUqQ== Date: Wed, 10 May 2017 16:18:29 +0000 Message-ID: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: NetBSD.org; dkim=none (message not signed) header.d=none;NetBSD.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.239.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;BN6PR05MB2916;7:7gnGkpz9aQM1h14FcAYB/Q69U2YPThT1C4zvBUF9xlboB2GVAeAVRH8GduxgoLr1BGtL2kDEjlaFHVj8ssJ++1m7zPOWU83gqXzQAMD74wbiVIrnfJ1NFeLP2AJBPQNH956jR3gG0Z5fVgsD7IjFH1ODZqRRsufP8gLl2ALziFvViScSBNYt5PGakYS8+84CeaEyzDjz7vc+PpJ60X9uh6PTPtGDGdbgIcmchrsN7W2jix6gw831WNs6cEpJdK2cbByDDOoOHls4jmc9TP0fZ6mdZ7p6bwA/i21yxZZgovcMcf5ghipDJP6EJ2pLx7byDySMCdA0uQ8lv8zmPnduAw== x-ms-office365-filtering-correlation-id: 1d95b54b-32b4-45d3-5db7-08d497c031df x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081);SRVR:BN6PR05MB2916; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123558100)(20161123560025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148);SRVR:BN6PR05MB2916;BCL:0;PCL:0;RULEID:;SRVR:BN6PR05MB2916; x-forefront-prvs: 03030B9493 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39450400003)(39840400002)(39410400002)(39400400002)(39850400002)(39860400002)(2501003)(2906002)(5660300001)(66066001)(82746002)(3660700001)(3280700002)(478600001)(189998001)(6916009)(83716003)(81166006)(54356999)(50986999)(4326008)(8936002)(25786009)(8676002)(38730400002)(6486002)(86362001)(6436002)(2900100001)(77096006)(99286003)(53936002)(7736002)(305945005)(36756003)(122556002)(6506006)(33656002)(5640700003)(2351001)(102836003)(6116002)(3846002)(110136004)(6306002)(6512007)(54906002)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BN6PR05MB2916;H:BN6PR05MB2916.namprd05.prod.outlook.com;FPR:;SPF:None;MLV:sfv;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2017 16:18:29.2029 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB2916 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list List-Unsubscribe: Hi, Eric Rescorla has brought to my attention that in https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04 it is currently specifying the SSH encoding of secrets on the wire using the mpint process as described in section 5 of [RFC4251] while RFC 7748 describes using a little-endian format: GF(2^448 - 2^224 - 1) and are encoded as an array of bytes, u, in little-endian order such that u[0] + 256*u[1] + 256^2*u[2] + ... + This seems to be what is being implemeneted for curve25519-sha256@libssh.org, so I should make an explicit note of this in the draft. However, I am unaware of any curve448-sha512 implementations at present and would like consensus that it should also follow the mpint method rather than the RFC 7748 method. Please reply to curdle@ietf.org with your opinions. Thank you, -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed May 10 09:57:50 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037F7129B8D for ; Wed, 10 May 2017 09:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jaPU4l9p9xOr for ; Wed, 10 May 2017 09:57:44 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EDC312945B for ; Wed, 10 May 2017 09:57:44 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 574E08556D; Wed, 10 May 2017 16:57:42 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 61F2384CEE for ; Wed, 10 May 2017 16:57:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id Gtn2aTclDqnl for ; Wed, 10 May 2017 16:57:37 +0000 (UTC) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on072b.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe45::72b]) by mail.netbsd.org (Postfix) with ESMTP id AA85C84CDB for ; Wed, 10 May 2017 16:57:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HMdb4XeNk35iGPeZ+lwZnRJbAqcSMSaLcbrzDC2Mg58=; b=iudELkJCM01AI157JUSUpMSbR3UpqYC8UG6RJVzOO9iG9rzzsBXa+Y2FIHkntc0+jS6warj1I5baJD06v9l0WsPOlnTqM/bW7xq/cRn1uZoQXIUWMcKEFUytIX2FMmmgE5tdYuv2e4ZAFmzWpbuXN3G3vq/BE9rnEzPaQY73BT4= Received: from BY1PR0501CA0032.namprd05.prod.outlook.com (10.162.139.42) by MWHPR05MB2911.namprd05.prod.outlook.com (10.168.245.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Wed, 10 May 2017 16:57:33 +0000 Received: from DM3NAM05FT034.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::203) by BY1PR0501CA0032.outlook.office365.com (2a01:111:e400:4821::42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.5 via Frontend Transport; Wed, 10 May 2017 16:57:33 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by DM3NAM05FT034.mail.protection.outlook.com (10.152.98.146) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1075.12 via Frontend Transport; Wed, 10 May 2017 16:57:32 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 10 May 2017 09:57:26 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v4AGvQJM029327; Wed, 10 May 2017 09:57:26 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 2E0EF11513; Wed, 10 May 2017 09:57:26 -0700 (PDT) To: Eric Rescorla CC: "ietf-ssh@NetBSD.org" , "curdle@ietf.org" Subject: Re: ssh-ed25519 implementations In-Reply-To: References: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> Comments: In-reply-to: Eric Rescorla message dated "Wed, 10 May 2017 09:20:37 -0700." From: "Mark D. Baushke" Date: Wed, 10 May 2017 09:57:26 -0700 Message-ID: <46168.1494435446@eng-mail01.juniper.net> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12;IPV:NLI;CTRY:US;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(39410400002)(39850400002)(39400400002)(39450400003)(39840400002)(39860400002)(2980300002)(199003)(189002)(377454003)(24454002)(9170700003)(2810700001)(229853002)(81166006)(8676002)(7126002)(7696004)(53546009)(77096006)(86362001)(2906002)(5003940100001)(8936002)(5660300001)(7846003)(6916009)(2950100002)(50986999)(345774005)(189998001)(48376002)(50466002)(53936002)(53416004)(55016002)(105596002)(356003)(478600001)(117636001)(76506005)(47776003)(6306002)(6266002)(54356999)(54906002)(4326008)(110136004)(38730400002)(106466001)(305945005)(76176999)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:MWHPR05MB2911;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;MLV:sfv;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;DM3NAM05FT034;1:fLc6js7/Z9FzTN68CzzD8Oz5PemvvkZ6rsvbqckoYcaRGiGGO3GDT/rwEm4aDjatzM6mrxOPF262ftB6nixmdEVVSgf76tYdQx1XoBxlk6uuRnlhqp3wjojiqRtqZCz36Vk8zTCcG7rV3vitsonn6aupg4aAyUGGxb5A8KcCL4/wEe0rXkE47UnnVKktnG4x61eqypSCqt8A6rIPyvxMQBRy6HjhxELV3nQpnHldXmjHwRTykvVIJK+H/VjkMvLIehhGfplDgy0Ky8vdsS0VlFoakOVGHQAAfGLmx4EirMYljDzd5fLgF5p9DGZluHG5tKNBCrkdLXzrPIV19y2YigSu+uK8Kc9zik9oYtZxSG4NyBLsMkoLOSl0QV3TCM+MioiYovRFyNuDq1RoEIxGUUdVZ3zpRTbMFQXHyOwaY5u0LKvvf7F5Ck1g4vpINE1oAKl3XFx1pD1hhGl/x9pYwBs5HtmtCSBtPwg3nbnLbmD7VxzIHQSMOZaSyvjP459kHinL/dMHXI6VhAVFwHLj5EwSYoZPWn7RDBWBFpV+/gcud71UoyTzB2yU93fnVLkRnvNtYyBW1zsoZLFygXW0BYyh5j2kR0L93Mzlqd9VSj0= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a4e02a59-14ac-4df3-fcba-08d497c5a6fa X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075);SRVR:MWHPR05MB2911; X-Microsoft-Exchange-Diagnostics: 1;MWHPR05MB2911;3:Zrm7UG1Vdp/e3kSzOXPYecddbl6pWk5G2XCYNOqdFnxQINFw5EQK2Dt01OgPi3Dvfn0es6jy5LyHpMS0nAH1+FH0Is2R5vJt8L4hkMm676gXdhjXGHGzqdybG1dN+VQeYJjAcZ5V/apuzmTQh9GfBomiTnzv2zfpOMZP2tx+3JmIFA14Y015P+z11I8eBFMh+hj/UVt9PSPj3EuDniqVoVjrd+L0FtEbDLyJirlCOc/IazIrpGyuWuK7KPyc4KqC6BkW46PT1g7CyDgcsq40ogPRRgCWplh+LrK2ZkxqYh6hZZwa5zFlaPrOeISI0qJCHPImkcWKt8aL92+hw01eUawUqgNNCag+dTMPAdlNznMU4YNGOg1Ktsv7zPP/684K2NVBhbC96RCzLruhqMMw7ID72FTkyeUWEGj8OWc6xBb9iSueoD4HxHVEcHwrG5dcqEF9BBfodVDwRqFbboJyx19VUEDZrzb3Rnz0Td7fBSPQelmWbTyTCNDsbFNSNTve X-Microsoft-Exchange-Diagnostics: 1;MWHPR05MB2911;25:x0tfS421EZmzkCCi7SDA57v5BumqTxZ3lzlqo375UF/DoumszhkaSgjzbeE/85PXq5ae3uEK3I7a5P3xZ2TzgoBvr4fUmiAS/yfIyLVbW6uy/M4hEwU6QC00rI2PwCk9Aprc6MvgjnYZsTY84xzBjmgM2bUxdSow9Y+PDyPdcRwWR3yeEOVXhYPsLEdk6O5QTXdHM0zUY5X4KaZUbw1fML7GW/S1OVPBQR5sHBFB9YRMYh8GLBxwc9Wx6ZmnTJf8iULg2U1b4FGM5ipyqKBISkExyVsQjiq8YBMD+iUZx7HMiiA8o7CL2/YDLNSz3VkbVchI13qdaDiA3rijhjbSrWAx4aLTOcSyEKxhfdb8uuPqIY+DMVWH6EocRcEdNPOOePnut3AcVQfDb5Je0/u3jR0x5NGac6B1tvXDcgWld8yiZz/sLhVFGKd7bHwoiew2LqnCyd+TxMs2cag/GxZ9mudo0sAnl7Ytb1zPHkAK3mQ=;31:9rOzBfe5m89zTnK+wxkagUDH02mvpPMikf233V5Nu2UX23Ue6kqk5tBLWUoQ9v1HjzgXUmaUSDtIe0jkrx/ZCxNS9P6LqNxd+HBtdWiwk7g857ZQsfgybcjk4oyHh/CbV1LamWkpirNkPm8QvoNCl/T5WQHgk6SouTdghphDlDB/QJ7b9SKVyjvhfXdSeeSMOegHEVoH/TvI/H22YqtUxa3fcLBcpgi9MVOy0PDZ2cMHTLn1k1S+x/FRdtueoMT0xla2AEV3aAbCQjEF3n1M2oOk3hafJhzSN7nnKELQVrU= X-Microsoft-Exchange-Diagnostics: 1;MWHPR05MB2911;20:Yt2128DOb+Vo/NxYujn6RN3A2Qwvdu1ECS83S4YYqEIQueBarOwsAU0Qnmds551fSegVC391aPMVhWzusc7C3bwDVn0DiLXMmsEbMg/xkJ9QsnlU+2hQH8CVX8cw+KJJXr+4ETthVXWWFg4gRPjojfYxQsw/ylZcPhA83EoBwgxHuMQ1IuQYUtFXTDM70EWnUve9cD3tZQ537Kjl3huiYhp7KfPkiMtcN1oE71D/4Ta/V7oal170WjjuwHz9C8+b80GKPXaOCpCRQe+7Zpg/7Kpu230vZVkw623uzMLWuSCY+FrxLst+SHJzxEn+0hqvs0W+4GG96Dqm+OZ6crDRqjXSfitZw6OfGtEdge3nJ5+ZCEisyWqm53v487PVonOOWmdTDbQurL9mqfNUFQQWz4mi4K/t0NFWVIiel/pg4N5NiNVTq78g42YpnF/tHjdfS1SP4XxpuuvPSDj6xUrDOhybBXH8FAreByNMRcjBf72AHGDJxmG1KwFf0d7b3jMI X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040450)(601004)(2401047)(5005006)(13017025)(13015025)(13024025)(8121501046)(13023025)(13018025)(93006095)(93003095)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148);SRVR:MWHPR05MB2911;BCL:0;PCL:0;RULEID:;SRVR:MWHPR05MB2911; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;MWHPR05MB2911;4:zgJd3k+Q4J5fHuG2/p1EKqokrEFqwIxwrJ4Xpvravj?= =?us-ascii?Q?5U70Hpkb90tEkUwPFIJw3ECr/8DKrC+Yht8p4hguScjqopXr1wOpQ4Az5w2u?= =?us-ascii?Q?cvd8jPVc4sq1YzzT3ZFPy/GVSBMdSHx340LGkyM5ZoqALEsc/zXMIPmQ75M3?= =?us-ascii?Q?42Yk2H9xOFvBDEgIVhtGvQzJEE79pEdO5WrGcTgBA5sUfQiUDS1z/w4FRSUe?= =?us-ascii?Q?+Y+pJP75WVWsrZDXnGMcVq3s14tdRBIoXk2xkJPXHH9ReYFzQcQGmHRgjQbZ?= =?us-ascii?Q?ba4TXYryj/Qhu0/rxGHNlfG4wQe+hsSeLQ98H74Kn78vMFlBIL9oPgkqufFz?= =?us-ascii?Q?VNrDzQzmcgyas8AyeajV1abmgCeL9/EWV8P7wxNhnJ3GMGRfDW0bgs7PbmEv?= =?us-ascii?Q?WAZlCy3eCCUaY5BQ3jlpWfguCj0uL5xl12+QCXj9Le4kXXATaDBIQ1aFV2Wd?= =?us-ascii?Q?WY2jLFfiB6kEhPI0cPK08+0Tq4ssAiGHMs+hKo5JSHVp+mZBN55ieTk5F6gw?= =?us-ascii?Q?1OzdlpVPYiSAgHnLz3avVVPUF8uMLPehTrtJxmIEqF53EIejmAmO/kiPG5D3?= =?us-ascii?Q?Kv+s/umYjCYwOrjdd+K+4iuXmJv1GD4beDFZ9bTlGSrdOwO5oxh0rBpeVbG1?= =?us-ascii?Q?pUSRUvuuCmqAKTAILtmH2Cay5l8yVpJ2r9EhMG1PfV2Krs+OSTGQ6SdkbElh?= =?us-ascii?Q?uWW8/jqQ1dZj2jqu77fW1wudtd1goV9JUQ9xmth0xdCcaL2yOVUmYi5XnvuE?= =?us-ascii?Q?Uaajq8QoEFMUXWfJ3ZdztX5YT4jBZ77zABOn9yPLLcyR9R20RY+RmxXvvIcU?= =?us-ascii?Q?/cGaZUjhLKQNOpwOj7wkiTVcOoHD4cJTsueuk1LBImqEFOBwKK0633f93mGp?= =?us-ascii?Q?eXZDfTg2XKa2FJAmF4vqY9EHXTk7b7un6texMV1cHYSsjpuuLNSlLNuowOP3?= =?us-ascii?Q?/yYjpeQPF2FuS9qsU7VeSBVjWTJZEwtzKRSVUM1N2sbdHYcNybDO7jzOzhlJ?= =?us-ascii?Q?M=3D?= X-Forefront-PRVS: 03030B9493 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;MWHPR05MB2911;23:GTZv/7sjGUWPb+5fw7niVGGO/J9tbwjjktCNBIC9C?= =?us-ascii?Q?0W8j3H6jD8ghf3h+6uINF/w1IHKd2U6IXQ1MqwTANyUTRQm4utXQwyRIeVYP?= =?us-ascii?Q?lUX7APpVNW9lnlVd6tvxZqMdXirjBvzhD5IReIkZfsmUCiyj1T4i+yeCeoUJ?= =?us-ascii?Q?UHmE47mglOFxQLnAFlgQZ7A/MddKOdrpFmZrpwfQthCGO3tdx+ykGAAXA4bI?= =?us-ascii?Q?aW9zmrpdZhCtc675HLJSnNMEJ0TyG/OTATIBi4UvkgAMMGBvqVawT2BnFA2K?= =?us-ascii?Q?eMoAQjGLtEPsN2fOx0sNIbZuIkuCgw/tHypo4NaQqFm1g97Lz9yIl5qGxzPh?= =?us-ascii?Q?fzOWuH2LiCsudUgns0CilGG+jfWjsRj7kpm2aM2hVjcKlqrJ8O2Fhhrc59oC?= =?us-ascii?Q?1czposVUlNcij2JrICwNJVq7nO8FbotRLMPujV8r8MqUIET6pp5a5C6ujN4j?= =?us-ascii?Q?9+EjOCvn5eKykvS+eNuarV8MM4TRJv2QUa2O14qy77sMl5U08SoAfqgk/tYc?= =?us-ascii?Q?5N+jQhZjfprCqSftYQbgPInsbJSQRVQJ+4VESTPIOdnLcFVUztkQoiYb/u81?= =?us-ascii?Q?vY7DdIiMY2/CZg9CJGtugzdem9qCGco4rRmBlByxnUZEQOHOb223ochasDW+?= =?us-ascii?Q?5jkmKDIDwiaDRlk+gHbIfIPMUNMuoo9YzFsEj3ETJH5ts+63KhR857q7D9JQ?= =?us-ascii?Q?Cpbn04lpKmhtRLYEOg3hRRWZQqCNgbwi7fdDv0o8sKc4rj14xJtE4PvG31/5?= =?us-ascii?Q?6UeVJhfsmql2iQd0AqBBWDMZowO/B+z6uvTIyT/NxIEXJeSSy1+K5G+uL+mF?= =?us-ascii?Q?XTBwvpqHdPU/MwZ7BQMQHjYMHMbHx6s1Lg8LGm7f8UqFry3APYRvJBTjIIKa?= =?us-ascii?Q?Gup/hMZG9lM+njMUUTwyt0P4y88OwfxUSDLXWtYt2p+RDr4/+jkowXe6R+NG?= =?us-ascii?Q?lCoN6z9yIypi3pyHy7XdIX+gZlf1ShsrYVRDamj4yLeES0rDL5erHnXCzn1/?= =?us-ascii?Q?D1K63ulKUVqDVDDq8j/le2/2/a+R9xDTrzTKGhYp+PO1ZkkB4g/hjskzjWgK?= =?us-ascii?Q?4BP88EaAhj1bO0/rJqr3RzetSDgK/q6jKkmZ0qzqjB5BgAloD2kfhezUFzec?= =?us-ascii?Q?jJkdjJ2d0cQwAiwyZqAOZiHzouPp6yzgALQHx/+QPe1G1qUoyJ8VtJ+zWYfr?= =?us-ascii?Q?VTty4qi6iwuXEaFZTigVV4U1kuJJIZurVuKCwQtHMnOIuJWM+qKkpRxD3GYb?= =?us-ascii?Q?4mI2JMqR8GGYPiWSTHyoK6ky4Ruul2UJcx8ogGbBsdz7M6Zx+Vm+keBpPsfo?= =?us-ascii?Q?qd7n6VhJeE6OT1gWqMWjcT3OM0DwrHSMD+MMf9XCkYf?= X-Microsoft-Exchange-Diagnostics: 1;MWHPR05MB2911;6:dq+wNX8gyETl/bfbqgkS0k5BxP5k9thPm6MApkngntQUg4/uI39B87Gkj3trCiQAJpTPjw7EZu+i3lD+Iq0M1SZASpbgI3nUgxv+99ffP+/aZ9gUkO1sP9hfI5gOGoZb3TUg+Q/X/cWvER9RjF6v+FJlGpMKPfEs438/xy5ZmxKNS6beDRxplJzsoDIRbyVYltbTF4+gbGyhnNQHZ0jnTCG6zl6ZyBbZZ+vFm3LqmJmiwWk44h1VEtHNiB3n9kA6V1mya0uFbDTTtAlpI37gUA3Wlb9KTBk9+KGqoFPyP0Bt76SFmuFFAUpZjYU64JfHlPz9iYae8agafyav3aiIeFjvVoiuNlvi3UtIc0EpxEL7GmdozX1mNNLI9j32Y+aiv0M0GDBI0LwZ3oDg7wmoAG86j00Cn/yFyXQiyCPjTvdMjtMgRlz7+T56BsQPu/sOSwsfo5lLR7Iw3UeMXXarZMBi7kzLVYRd2sHDIKnpvuQ7iUoQxVZMf62iDywGigtDp9IfH5E9fXt76rStpvGwr47niqDUBwW01o2yYWDz67A=;5:B/zK53qa5dnjIbMT569poA0CvLHkk5QxZdxfzmezbc9ah6fqTSjtIyVXfvNrBSxWH5fOnERq70rM7QxQrvinYr6UDEcr019ES8T92DHiajyfpauD4r76cgkbPuwRGrGWIf24xxBHsm80W3bkNXOFjA==;24:gdRC41hFq/SvGRprBDO9mkz1qbqcf22jv3V3WtR5ZUE7F/alQLl+IBotcDHpsmU42mrb086624OkzLjDckYrcZ3LoMpxuTQVf8azpcdVdQQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;MWHPR05MB2911;7:Fv6XPXdKSwKjeI0fu5Mr1JzviJrEx6giNSafrLuCuNkyxE/Ns2EO2CogcoctVMoGhjcjJFMBEET+FHyTZgE6k30caVZ5zVP2Rmkt0iFvfUcUqYCTRJuNaw4paGvTjWH5VxrPuhQamZffikbf5DvEwFpbly3RKKVxUgq6hVz7wGDsBhKZCW6F4W1w+0zaSvzoeJvOPgTVysXJX2wdaPkZpfufoMoee5KKdk9kN/oGzxHpYqvqdB0jiMql6ebPxpbqYGVwJtr1PQ63Mvn2JKn4OFjhHtU5Uhqa3zBYCnXPAc3y+YCFqhm0QvojfFu2mcHa0WjD2qaIULdiZjN4CG4exA== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 May 2017 16:57:32.8537 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.12];Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB2911 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list List-Unsubscribe: Eric Rescorla writes: > On Wed, May 10, 2017 at 9:18 AM, Mark Baushke wrote: > > > Hi, > > > > Eric Rescorla has brought to my attention that in > > https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04 it is > > currently specifying the SSH encoding of secrets on the wire using the > > mpint process as described in section 5 of [RFC4251] while RFC 7748 > > describes using a little-endian format: > > > > GF(2^448 - 2^224 - 1) and are encoded as an array of bytes, u, > > in little-endian order such that u[0] + 256*u[1] + 256^2*u[2] + ... + > > > > This seems to be what is being implemeneted for > > curve25519-sha256@libssh.org, so I should make > > an explicit note of this in the draft. > > > > Thanks. To be clear, I'm not saying this is the wrong thing in the draft > (though I do think it's kind of an unfortunate outcome). I just think it's > critically important to be clear. Thank you for the clarification. I agree it is unfortunate. > > However, I am unaware of any curve448-sha512 implementations at > > present and would like consensus that it should also follow the mpint > > method rather than the RFC 7748 method. > > > > I tend to think the 7748 method, but all the options are pretty terrible > here I am agnostic on the best way to deal with curve448 for SSH. I agree all options are unlpleasant. RFC 8032 vs implementations for ssh-ed25519 will have the same issue. So, if https://tools.ietf.org/html/draft-ietf-curdle-ssh-ed25519 is updated to point to RFC 8032, it will likely need to worry about the mpint vs little-endian encoding issue as well. :-( -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed May 10 18:47:55 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E09FF129501 for ; Wed, 10 May 2017 18:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDCatzJavOVA for ; Wed, 10 May 2017 18:47:54 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DD4B1275C5 for ; Wed, 10 May 2017 18:47:54 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 18E3084D94; Thu, 11 May 2017 01:39:48 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 4DDE384D78 for ; Thu, 11 May 2017 01:39:45 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.netbsd.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id t8zxzW1ZVcmp for ; Thu, 11 May 2017 01:39:44 +0000 (UTC) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on072a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe44::72a]) by mail.netbsd.org (Postfix) with ESMTP id 7A5C184CDB for ; Thu, 11 May 2017 01:39:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xeYYTv4024rfXDlKRo7fvC9RvMAIz24AoAFXs/L7ck4=; b=Ur3Ko7+4bZvakjhufD4lxLN2TYH/Mcw1K/IYCNKizhmS6mSui6ytyo608lXBT+GSVXarayle+LyLC37oDgOVuEydAJI1Y9fyJm5uU2hvaboJUndRuOa24MIgeYQeoqCAese8HtLDWCC/decDN2E8fFHVxULO5pnWDgg/bMev3ys= Received: from CO2PR05CA0071.namprd05.prod.outlook.com (10.166.88.167) by DM5PR05MB2908.namprd05.prod.outlook.com (10.168.176.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Thu, 11 May 2017 01:39:40 +0000 Received: from BY2NAM05FT025.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::204) by CO2PR05CA0071.outlook.office365.com (2603:10b6:102:2::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7 via Frontend Transport; Thu, 11 May 2017 01:39:40 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; NetBSD.org; dkim=none (message not signed) header.d=none;NetBSD.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by BY2NAM05FT025.mail.protection.outlook.com (10.152.100.162) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1075.12 via Frontend Transport; Thu, 11 May 2017 01:39:39 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 10 May 2017 18:39:20 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v4B1dKsO004080; Wed, 10 May 2017 18:39:20 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 9D0241145A; Wed, 10 May 2017 18:39:19 -0700 (PDT) To: From: "Mark D. Baushke" Subject: ssh-ed25519 implementations Date: Wed, 10 May 2017 18:39:19 -0700 Message-ID: <72914.1494466759@eng-mail01.juniper.net> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12;IPV:NLI;CTRY:US;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(39410400002)(39450400003)(39860400002)(39850400002)(39840400002)(39400400002)(2980300002)(189002)(199003)(9170700003)(305945005)(2906002)(6392003)(7846003)(6916009)(48376002)(50986999)(50466002)(5660300001)(55016002)(47776003)(5003940100001)(8676002)(117636001)(86362001)(81166006)(8936002)(54356999)(6266002)(105596002)(106466001)(478600001)(2351001)(6306002)(53416004)(2810700001)(77096006)(356003)(110136004)(38730400002)(7696004)(189998001)(53936002)(7126002)(76506005)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:DM5PR05MB2908;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;MLV:sfv;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BY2NAM05FT025;1:pjqDIV0IiNCGXxDVul8nE2KhuefCU0udSNK678lYN+TnvAr/lPQO8rE6GEz3GXAh1lBC8t/mYcJf0LLxC/mTL3HXJ+O8B7fLmKz/Ng/Jw56d0vMHnrGJIkuB0kjsc020mKxBoOtO+ahuC7tbl98thMHaYdYP0IBiEwQ3mLf6wNvNr0Sf8Al1ymiVeWtjg9djUr9Ch8BCGKvPidah1GKv9FgQ6u1IMvt6JnF71pmaeqT3WNoM30LUSwFHZBUKAcDx7Q5qDuDBvRJNEpbpCu+BHr0uNPArK2bKpF0mh6f5KVKPnaBgC9jabs4j1wjA4nxbOz109tQTI/mg64fizhkcOGJR3ZAqSXOMaY7UQMIVoyHpt/qB6QLlKzCtwbMYNwc/X0KIHBPd5zqcPgF29iijsQbDbzSiJi1IxBwJa4hsMF2YdGH2PKEhJ3It4LGAnboBBOFp71AG4pI/eAPTUKPbPqyzaQj9q6BMxaqN2rWZQp1A4ql8NHAW6PDGgdcH0ylIUm3aPPTgo7NFMGKRyxKu/GoDeD5cmREJm2hHtNNkyOEP+qo4dzwijomxRoY2lzLZ X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 97720a8a-8547-4c4a-e5a8-08d4980e9718 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075);SRVR:DM5PR05MB2908; X-Microsoft-Exchange-Diagnostics: 1;DM5PR05MB2908;3:4BlmlsvinJLCq3ewFn2evo9Anr4SWIs0tLA1dK4f1IaZ5nptigc7SzqiL46g36LaK7M3UJB0pBs6GUQf+xAt5Fr9IIfhk5BKkxcwHSu4DrmPZHZVn87u5glyGBauTgSZkRZ6Sznj8/5c2M5AHUicqKrlW3E4ui6w/qvr89YouJmU2arsMwoSt5H6W4beNpVg27geN7zjaMsp+pW9yntmteDDcZf+ZPZuOACLCPGyoo78VXrWAS+UyrwIQfrSj9NmViOrfC4jfmghWkR2NRZPiWqxVRcxOhf2JDtiLcCeU10X974O8/PAl/pZxDd0fIlWqambEkmajr/d4morVvEQylo6xggOHnlfxTg4Jmy3SYb9xuxu+FGVogwAdEuFoiwkVhV8rmWb3u95VNnarj/yH3XxvN5/PiMYQpE2OF+WxK72RyxAMw3BUknYYm4+NXacwB6YiOg8mrlv2sWxN6ddiYbD2cfTDyMJe30SY5Vm54UF3GGuo1Xckh5bhhRLqRbn X-Microsoft-Exchange-Diagnostics: 1;DM5PR05MB2908;25:bMyl2hBepQSmCNBTDD8NpE8hizt34BNLMeE2x5Y3RyWPCebUxB0rMoz/5TF0edLFjkruXnYJ1sE4myokuL26/eqkzP/7FzCaUUmnH2/gPHxCHjpeUWQ+4bqMNr/jvcI2s5vVfE+plffbsJ3eiAbYMrw4HHIz8sB+1hxJ2KM5tRT9wfxpRpCmvk7brIdpUHGk4P00MfY1F+X1hd3fh+CDrLcWRSQnqq6iEThbtgdEenu2TbEIWBbatVl7uqRrev5+adSeRcWnNJutdeWPoHlggE/IDGa4yegNjVaXTJvPZihKTOqO4O9HI9UP7600TcSwLWArORpUs4D66zzHztXLW5da+z8KmOxZo6YyhuG8SUyaqpR0MjTyyqsP4W0B3NnBwstdxbkUiBdnkAOWKrc+Bl2sk7YLapHUjKTToACMOUUijKDGZof07YZUZAo9BL9bU0MVb1k8yhnRaEDx37fTi91EzUjok8nOLJd4epXAXDY=;31:/G/LqGohBd2BI/E/87Y8yWVTfEo0xesb8mPcozePuVCexzSGQMPEiPuPQ5BQlbfsPWuQ1WZ09GcrkF0iWf6LUN1dkhDPyU/2YIUCsGSCTArduDAsVQBwSCCaHVc6ExdZNCiirX9h5QqV7kxliepLXh6Pba6Wu+CHWTtZP2SJuolaqR6aTSgXvKS8HKC68V9k9h8kpn/XFkYxg0j2ogfz2gXgBj4yweThB2DINUycppR7aedvur3FUwhawprl/35y5E03fQDtnsdZdOgar0+h6g== X-Microsoft-Exchange-Diagnostics: 1;DM5PR05MB2908;20:6PMpzX8NVpHY7EVvTr216jxu3d7alcIRZBRjalzQLzUe2RDzjSKOZU3/w5ur5QGQz1Ssg0QGFS/dSjf0LD7YxpBXx64j/LSEAXhrHRQvoomN97XMC9LlBXC39CSjtWSq9oDkUDV3pZm83e7nRaB9Fe4dpa6XRUkhYnUIF2bb2BxEbvFh5q2J/DOg2D+lq1jf9k5THwzJ6STRJ2KiozcM4G2x+xuupD4PdLF0KGGt9BsN8hV3DlCw4hiFPPaaFMICueqbUJAB2UVrMiLCUfciEZNjgdxcJSAaOF3zbAT6K9L/hihmR9ABg6wO9JAPyLLAv9ML34eaPHG/9ZKiAysomURpMOHwf4tteDkaOKO5vwGaprmw5iIHPQu1zNX///14POFtspmEcpGRgYH53DUr6PV//hXxBa5fednY6rIxo8Gly4+fSX3tIvZd1jqi/4pr5HsTgVJRTVJ1jFWEN5q+pmLaStc47GLAc5AiX0vnt+XkfUUFsd+UGNaWcSFJCLEu X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040450)(601004)(2401047)(13024025)(13023025)(13018025)(8121501046)(5005006)(13015025)(13017025)(3002001)(93006095)(93003095)(10201501046)(6055026)(6041248)(20161123558100)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148);SRVR:DM5PR05MB2908;BCL:0;PCL:0;RULEID:;SRVR:DM5PR05MB2908; X-Microsoft-Exchange-Diagnostics: 1;DM5PR05MB2908;4:oUipjwyrSK/YuioUzxMaaOnhfDc9+9NAaD0fzV7t+mdqptf82Ml2xI7GnICXYcysk7XOGPamXVjiTMLthGmhhnx04FXiqBSwlAlCRBC0WJjMIHl3kVBNCYrNL+VSXItmiSDwsAZi5U2SJD2XohUO9JH8FJviyuCuazEsVIdaBAdgRfA+xGMs4E04Uep74EbUt2QplIvzCgmKV5XLupE6BE33kILEBPNSXqdLfr5Py2x+CF+m5YpyTsIyL7zW57sWJZsKB/3wh/+IJgPrIXDM01difVY4eY6tRysLKMyx1owqJE8c60P6RUr0MahYqhbrR4ssGHLsKGtB2cbsrygoewJTg6JVoiYh4z2ZiFjfyx+Wb7TAc3uxzQgkFczrgKgMwCKaqpMFwAafZW4Ui4PK7lrh3N8glMkf6XM+lD8C7ZC6cEARQFOAZQNZmFcd82pF43gtNBEpo5XZI8XmN2FJiLuXSHBQfTSMhfg/5FVcKGM1uwNxe2MWkTpljnSZA0S/1kIhT2CqVvNUoWMnGBbrVPRqs4OWVaWOnGqrdm34u2++YoNtO5tzGaxrsT7BZoTE5QjJLWGU/LT0ap+tEMohfehJeC7v1WzsF4nHa3Qb/wFoYYrdlQdyqqufwR0crqTn0L8YHxqYg7qR/oKe7oK2Y8Ien5eLB+Oi0f/er5FonSid/vcmxK24NsM2cOYqlENj+Yo9JPUEh+OUIjZAAqtGPASzQ+I70ooyXv9uWiSPYMZjJz1Y5EqSACfAGrLWwn5mqKAl3XkuMEyBJ2rlgV3VWmT9AjIeSmYa88w90RqXaZpJ4HxFjFDoHSJ81kA2yCzUyoNzA6EBIWcNTmFDG/pYoVr96DOPFbmW4fjwZV719wEf69+sZlahDK8D5Jx71vi7nPyw6itWy7GU0NbVV4Ilk6niVCPbRXGTneRtYG0IQNiFphgmJeUVrsf9Y0VFRQ80 X-Forefront-PRVS: 0304E36CA3 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;DM5PR05MB2908;23:9B4XooLGK2X1TVINNPSLsu/VihY8zyoJaaSlyw/K4?= =?us-ascii?Q?c0JA3R8ljhZk2CQvpvs6Po42igUv+0MeoMjgGCb7JaJxCaorvNwsX2gYa06E?= =?us-ascii?Q?ENyMV+DRn+pQG0hyctSS2QXKc5r1vvM0LoQTzx2EQCRuPsYSR+Miv0Gx87zK?= =?us-ascii?Q?3MKTbKebMWbobGn3ulv+GPAEEZR1ZWcExJ0SNqW8kD3yQbQ+4/mSMwtEkYc7?= =?us-ascii?Q?WgPdjum5bj/V1aq2IVxJLYuHx3KmJcOyobWSamFM4lvj8z+cSd9xSkhv8BqO?= =?us-ascii?Q?J+BQQXX3Fc9MDfne1eqMy8cE8+SRVjvnq3u/MuJNFoufyDcx8E73Jy1OROD3?= =?us-ascii?Q?ClShCnZHzeaca3ksN4XpDHsLCzQPUALssTGG552Kv3Brkv3JCQDRCUM4zz6y?= =?us-ascii?Q?ZqOMQACvH0erQJtdJNVARaL5crXztz5hrXIkAMkdEAA+2vUcbqjppFcd6YzD?= =?us-ascii?Q?8FppZw8fb/F8htbvWsKJKon0VCQN00HEkHEKaRXMpcvvghI7mc72lpx1oRkk?= =?us-ascii?Q?MxJ9P2dFZWjLg2SJjnTeAceQvIziblbgX+F4OEbdfeIkF1gOz+8r5h4id3fl?= =?us-ascii?Q?b7WjVoGfrjcqARTEiM14V7V1CW33MwQl0CTD8+WKAc+e4neyhdW4reScbUYk?= =?us-ascii?Q?o8Qa/dK9evANIrmcLC5wnhp6loL+ActamJtAWzeMXebgnealM/PcW6YedFcJ?= =?us-ascii?Q?RD8lgJuPOWlDVMZ0qTJGfcKlU3g3nnDCjcczhtCsnxk8g2Whs0DfiHLFRIHi?= =?us-ascii?Q?upsK4XuyRfK3S5Q3VN4orfMx6B+wrhWboEDoDIRP1DITX6/8rbtBcy/PXZOC?= =?us-ascii?Q?ld+EH0MJTJ/BNrDU3/KQfyxuaE06H9eFPLU9p4jVkuBVIlTxcX4Z9piuTxhO?= =?us-ascii?Q?24gVdtP7oIE6ofJxCEiT70QxDAnIeo7HBcUNbgVjDVKMzFhZuE3e0R9l41HE?= =?us-ascii?Q?LSErc5M0W5BVrZ6iGzgOAllnwt/DL49ALy78FsaA7vEv8KtqadXfOwdlyc+2?= =?us-ascii?Q?Cpiu4AgznV/GaM/XuiEdpdVXoJuV36vj4MPtnYBC1afGPgcaPpJk8aNBXt5k?= =?us-ascii?Q?J+sAN+xWV8AyG3Vv79GDaQrMGhTGZ0Ldnf6+WfcenJA3e33p8AlbM0V6kWOx?= =?us-ascii?Q?Q4s9VP5w5mIkqLzXN/QOzBs9LRXVhVclbhAhtZS8bN/Q2mve9PCEw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;DM5PR05MB2908;6:qx2XyvSiRz3XZYKFWoU+sU5+jdLgplSyaQCcIvdwMmvYTv8Vdvnm8xdnuY4sooRpIkk/VGVjMrgsW707eESD2Izewb3Wjf+CNCded8EYy3RxB0nERbAq+Lk1Jf75hEcGO31SZpvYRiXEXXGNUCVp4hb7MscLWK7FaEdJ0eMSCOdDTf+KeULpBnl9iTE1tofUh9jl8G4wchraRM/G69lncCwFer7OXC41Di9ALhYfvrGKP1O1GIthw4g/i/5zOCx1iHNxj9kvDTZLXVTNoYdHTFpr6pKZ6Ip1nhIk1neL4aV2QdUadGBuckNfOIdHAu6b9xu34rCbsuEoIUeoEvKuVkxeosxa6A2uVwvq8Xz90Z330PF0UGJnL/aVLNRd1x/C6BFxbMsaHAuGDF9VtL1az3vlr2mMbzjE8E9/uFaCVa3zrgH41mOqrxc07mMdSZ7pM/Dy3HKNrTt8M4mcrMgQZDV46fd1FMkAG4nbZBSAIKEBdYeWnK3tyvbINWyjpj9N+cHAIgCxde62U3aJRAwH6sqKeIIbbZt3gSDoosEHFvg=;5:GMDTBdXGAiD2XGRee6Bk6Z3g1rPZ4FHhtZEoVAoZPIS3jGxD7eVeO6bQT7NKb3ELYhXrstF5l3HU3imUxxkuZDiCSff3+vA36BXcnH2aayILYt3fe5b5eCjmrP6pIuFX8hNa6ESUHtGjrzHIUtHR1w==;24:zwZRhAkYmF3fvMkNAD/V05T+j/i5Xef3trmw4vmPBvPOwBr2+CM67HiF5LFSnP9NPNgl7rDBddHF6iuncpYUoSFjPEuCnRhR7Suis67WxhE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;DM5PR05MB2908;7:dtcIv7+YNhZ504/j6bYAVEbgIEd3plo/8AN8aixyp9WunmrjkddF+qWtAaG0h7hjvJAjdHM5Zuci3hKsHfB1DYdULDXfkAEBpCw/0tdDY12n2KKYfxpxTmjx8OpGJuq7h82gcHkzgahLFk/knBPl+idqFtfvPhHMq1AQMywWdPchWvanr5WFe4txXiJJAnubF/HXNW2aBF6/OVTZqr3Za16eOOTeUcRpmkkcPDqa/E4jSw+rhq9XiFvjwyMZj442yMrm0FBbG4mB9X6i5sa3N0RgTEDZ/irGtflFGHXlV8SSt/9icmD+q1uVZWK5VHNIhKU23TqZH3QjuosDjD/LMw== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 May 2017 01:39:39.5682 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.12];Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB2908 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list List-Unsubscribe: [Second attempt. my first attempt got bounced by fraud detection checks for some unknown reason. -- mdb] Hi, Eric Rescorla has brought to my attention that in https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04 it is currently specifying the SSH encoding of secrets on the wire using the mpint process as described in section 5 of [RFC4251] while RFC 7748 describes using a little-endian format: GF(2^448 - 2^224 - 1) and are encoded as an array of bytes, u, in little-endian order such that u[0] + 256*u[1] + 256^2*u[2] + ... + This seems to be what is being implemeneted for curve25519-sha256@libssh.org, so I should make an explicit note of this in the draft. However, I am unaware of any curve448-sha512 implementations at present and would like consensus that it should also follow the mpint method rather than the RFC 7748 method. Please reply to curdle@ietf.org with your opinions. Thank you, -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed May 10 22:21:21 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8908127444 for ; Wed, 10 May 2017 22:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iuuo8LNyITcR for ; Wed, 10 May 2017 22:21:20 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9031E126C2F for ; Wed, 10 May 2017 22:21:20 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 48320855B0; Thu, 11 May 2017 05:21:20 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id E5636855AA; Thu, 11 May 2017 05:21:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 9DCAA84DA8 for ; Wed, 10 May 2017 16:21:19 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id fIhzGWLCe3VT for ; Wed, 10 May 2017 16:21:19 +0000 (UTC) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id E038B84CDB for ; Wed, 10 May 2017 16:21:18 +0000 (UTC) Received: by mail-yb0-x22c.google.com with SMTP id j17so198514ybj.0 for ; Wed, 10 May 2017 09:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=v5q25DHV0VtWSwMMM3z71duY/zhjrRsrpeNjuvpEKHU=; b=hQqf7Ns4qcUDjC+y9g42+obT1yRyTHGMZAM8hmf2UzbxJQvfb/QG6tRf3xJGW55fda u2k6TpQY/N1E5HwUDU7iZnr+nt4jvBCi8OCvsiVMrjJMsZJXaCKWD9csi9i6DNG7o18h iLMkr+haiTDPlXQkNyrdIEpatK6B6Vvxi96K7pEqFIpOK+uWOJL5VjQ+nCfAvUhXP4zX KjwZ7VRihtDzZITHf8UuGFk0G60n17nUckvagfIamCDu9iLRba0GcC03SwWGcd9F+nko JE4Muh3MktRUZsPCI3MyscPA6nuyMxKL30WJSyOO3KFEOOriZ8kjVQjcHDn2+FJRTwWc OTmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=v5q25DHV0VtWSwMMM3z71duY/zhjrRsrpeNjuvpEKHU=; b=n6hYxR4eOINeGvSE4rE/a2UPNBol78Y/+Ph5vNszl9Ae1dO8yz4FsA6lScFhJ5UfJx oSdy/cRbsbw5+OzCtRvpRLaFNH7cRMYtFrk0erAZPYZ6K3W+p1x+fGaNXwA7RDogOw8j FY6S7G5iWZfuZdLoO4AoQg1UUbg5oBan/aiVw/JshEdCtrYLnuGVDd6qOEFZt4pVIqTK MA8GGmhDnPCkeYL/jufbiDYwKGN4p7/zQbE2/Ez6sx9mjnCb4l2EMdR0SxvPCjnxQX07 6gxX6Q+cc8fKDhjMDPy6LgLm8f28/OMarJYY9py1nQEnR13ElVVcdKyRi7jGCds6rlc7 bSfQ== X-Gm-Message-State: AODbwcCob+LuTsXjQvGdxza+MbnRFhgCkwAEMSQfYZ4wzeyYd6ioPD7Y 1gXKPjEFDSbHHi96jWDHrPtnIHo0uUbM X-Received: by 10.37.218.145 with SMTP id n139mr5487597ybf.117.1494433277914; Wed, 10 May 2017 09:21:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Wed, 10 May 2017 09:20:37 -0700 (PDT) In-Reply-To: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> References: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> From: Eric Rescorla Date: Wed, 10 May 2017 09:20:37 -0700 Message-ID: Subject: Re: ssh-ed25519 implementations To: Mark Baushke Cc: "ietf-ssh@NetBSD.org" , "curdle@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c07e820abd3f4054f2ddcac Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list List-Unsubscribe: --94eb2c07e820abd3f4054f2ddcac Content-Type: text/plain; charset=UTF-8 On Wed, May 10, 2017 at 9:18 AM, Mark Baushke wrote: > Hi, > > Eric Rescorla has brought to my attention that in > https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04 it is > currently specifying the SSH encoding of secrets on the wire using the > mpint process as described in section 5 of [RFC4251] while RFC 7748 > describes using a little-endian format: > > GF(2^448 - 2^224 - 1) and are encoded as an array of bytes, u, > in little-endian order such that u[0] + 256*u[1] + 256^2*u[2] + ... + > > This seems to be what is being implemeneted for > curve25519-sha256@libssh.org, so I should make > an explicit note of this in the draft. > Thanks. To be clear, I'm not saying this is the wrong thing in the draft (though I do think it's kind of an unfortunate outcome). I just think it's critically important to be clear. > > However, I am unaware of any curve448-sha512 implementations at > present and would like consensus that it should also follow the mpint > method rather than the RFC 7748 method. > I tend to think the 7748 method, but all the options are pretty terrible here -Ekr > > Please reply to curdle@ietf.org with your opinions. > > Thank you, > -- Mark > > --94eb2c07e820abd3f4054f2ddcac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, May 10, 2017 at 9:18 AM, Mark Baushke <mdb@juniper.net> wrote:
Hi,

Eric Rescorla <ekr@rtfm.com> has = brought to my attention that in
https://tools.ietf.org/html/draft-ie= tf-curdle-ssh-curves-04 it is
currently specifying the SSH encoding of secrets on the wire using the
mpint process as described in section 5 of [RFC4251] while RFC 7748
describes using a little-endian format:

=C2=A0 GF(2^448 - 2^224 - 1) and are encoded as an array of bytes, u,
=C2=A0 in little-endian order such that u[0] + 256*u[1] + 256^2*u[2] + ... = +

This seems to be what is being implemeneted for
curve25519-sha256@libssh.or= g, so I should make
an explicit note of this in the draft.

= Thanks. To be clear, I'm not saying this is the wrong thing in the draf= t
(though I do think it's kind of an unfortunate outcome). I = just think it's
critically important to be clear.
= =C2=A0

However, I am unaware of any curve448-sha512 implementations at
present and would like consensus that it should also follow the mpint
method rather than the RFC 7748 method.

I tend to think the 7748 method, but all the options are pretty terrible h= ere

-Ekr
=C2=A0

Please reply to curdle@ietf.org with= your opinions.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thank you,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mark


--94eb2c07e820abd3f4054f2ddcac-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed May 10 22:22:05 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A3C127444 for ; Wed, 10 May 2017 22:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=timeheart.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtRGDrlhBY29 for ; Wed, 10 May 2017 22:22:03 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE423126C2F for ; Wed, 10 May 2017 22:22:00 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 6461B855AA; Thu, 11 May 2017 05:21:59 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 0B726855A3; Thu, 11 May 2017 05:21:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id E0BB884DAA for ; Thu, 11 May 2017 02:49:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=timeheart.net Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id 3ggA1Ej36aU5 for ; Thu, 11 May 2017 02:49:33 +0000 (UTC) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 0829484CD8 for ; Thu, 11 May 2017 02:49:32 +0000 (UTC) Received: by mail-pf0-x232.google.com with SMTP id n23so1723051pfb.2 for ; Wed, 10 May 2017 19:49:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timeheart.net; s=mail; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=hPIwb7fpi9Nrv8RUa7DTjE4iC6XJ3cnT3cY0MhWq+80=; b=UsHslBSMnOSAce3knbV/TUFamDyOX5vmEdphL55JKcOQNB4QYKGmd6NwE37N9J9QGe EwRWNdWTP/lpkPpb9g0DP9yWHRqqY8/uHo7LNVja0aoSr65Gw7bjV8useYRrwpmmAWUd SAMGsxoNrr9YYQnyUC72rfeSl9EUmgJnkUOOw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=hPIwb7fpi9Nrv8RUa7DTjE4iC6XJ3cnT3cY0MhWq+80=; b=OLNMv8/1wqOo1hbm28CXfEeLTiEhH6VZXyu9lR3LnxqdfwtHm1famB9bkHy1mVEwH1 9+kujGBRoSv9KQCIyxEj7dCSjRMc8OiE18jJdDaT7j3j0Vxs7YY7gm010+9jm0RanA/C rJFpZMtKwsV1KxsqC4nZGltreAMQozSxTv4C/oOnnVowkCEvByJlEFNxyNZn82qtUYT9 1XRks/VwucV9eEPTAB6AjFZ0tqnFqCy6TNDJnrqKERT86txPdfhhNu73uT7l97Cu1XZA dqFGD0/zPRJyM0BpQ1zrdvkWjiihps5YZX4VlF1j0US66kgnbddUZC7TFFl92dULtMF2 nc9Q== X-Gm-Message-State: AODbwcBQBQsHf732Qj+E5b6fI408VGZEvMrTdQpz8AIOeP/hJNEz986y IYm7MGUUPatxgg== X-Received: by 10.84.130.7 with SMTP id 7mr12474829plc.35.1494470971492; Wed, 10 May 2017 19:49:31 -0700 (PDT) Received: from ?IPv6:2601:647:4282:2200:cfa:5497:d692:7eeb? ([2601:647:4282:2200:cfa:5497:d692:7eeb]) by smtp.gmail.com with ESMTPSA id z68sm416169pgz.14.2017.05.10.19.49.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 May 2017 19:49:30 -0700 (PDT) From: Ron Frederick Message-Id: <0BC6F061-CBFB-4935-9C00-42CB1741543D@timeheart.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_E671D99B-B3F3-4360-A53E-275EF6CD33BA" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: ssh-ed25519 implementations Date: Wed, 10 May 2017 19:49:29 -0700 In-Reply-To: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> Cc: "ietf-ssh@NetBSD.org" , "curdle@ietf.org" To: Mark Baushke References: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> X-Mailer: Apple Mail (2.3273) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list List-Unsubscribe: --Apple-Mail=_E671D99B-B3F3-4360-A53E-275EF6CD33BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On May 10, 2017, at 9:18 AM, Mark Baushke wrote: > Eric Rescorla has brought to my attention that in > https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04 it is > currently specifying the SSH encoding of secrets on the wire using the > mpint process as described in section 5 of [RFC4251] while RFC 7748 > describes using a little-endian format: >=20 > GF(2^448 - 2^224 - 1) and are encoded as an array of bytes, u, > in little-endian order such that u[0] + 256*u[1] + 256^2*u[2] + ... + >=20 > This seems to be what is being implemeneted for > curve25519-sha256@libssh.org, so I should make > an explicit note of this in the draft. >=20 > However, I am unaware of any curve448-sha512 implementations at > present and would like consensus that it should also follow the mpint > method rather than the RFC 7748 method. >=20 > Please reply to curdle@ietf.org with your opinions. I have implemented for ssh-ed25519 public keys and certificates in = AsyncSSH, and my implementation currently uses opaque byte strings taken = from the implementation of curve25519 in libsodium when encoding public = and private keys. These byte strings are encoded as SSH =E2=80=98string=E2= =80=99 values (4-byte big-endian string length followed by an array of = bytes of that length). The public key is a single string value and the = private key is the concatenation of two string values (public key = followed by private key, each with its own preceding 4-byte length = value). This implementation interoperates with OpenSSH. More details can be found in the Internet Draft at: https://tools.ietf.org/html/draft-bjh21-ssh-ed25519-00 = This refers to: https://tools.ietf.org/html/draft-josefsson-eddsa-ed25519-03 = I have also implemented curve25519-sha256@libssh.org = key exchange as documented at: = https://git.libssh.org/projects/libssh.git/plain/doc/curve25519-sha256@lib= ssh.org.txt = OpenSSH also implements this, and makes it available under both this = name and more recently as just =E2=80=9Ccurve25519-sha256=E2=80=9D. Here, the public key values exchanged in messages like KEX_ECDH_INIT and = KEX_ECDH_REPLY are opaque byte strings similar to the above. As = discussed in https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04 = , the final = computed shared secret value is converted to an integer by taking the = 32-byte point obtained by scalar multiplication and treating the bytes = as a bigendian (network byte order) value, but this value is never = directly sent on the wire, so I=E2=80=99m not sure the =E2=80=9Cmpint" = encoding ever applies to it. The only values on the wire are the public = keys and signature values, all of which are encoded as strings. --=20 Ron Frederick ronf@timeheart.net --Apple-Mail=_E671D99B-B3F3-4360-A53E-275EF6CD33BA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On May 10, 2017, at 9:18 AM, Mark Baushke <mdb@juniper.net> = wrote:
Eric = Rescorla <ekr@rtfm.com> has brought to my attention that in
https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04= it is
currently specifying the SSH encoding of secrets on = the wire using the
mpint process as described in section 5 = of [RFC4251] while RFC 7748
describes using a = little-endian format:

 GF(2^448 - = 2^224 - 1) and are encoded as an array of bytes, u,
=  in little-endian order such that u[0] + 256*u[1] + 256^2*u[2] + = ... +

This seems to be what is being = implemeneted for
curve25519-sha256@libssh.org, so I should make
an explicit note of this in the draft.

However, I am unaware of any curve448-sha512 implementations = at
present and would like consensus that it should also = follow the mpint
method rather than the RFC 7748 = method.

Please reply to curdle@ietf.org with your = opinions.
I have implemented for ssh-ed25519 public keys and = certificates in AsyncSSH, and my implementation currently uses opaque = byte strings taken from the implementation of curve25519 in libsodium = when encoding public and private keys. These byte strings are encoded as = SSH =E2=80=98string=E2=80=99 values (4-byte big-endian string length = followed by an array of bytes of that length). The public key is a = single string value and the private key is the concatenation of two = string values (public key followed by private key, each with its own = preceding 4-byte length value). This implementation interoperates with = OpenSSH.

More = details can be found in the Internet Draft at:

https://tools.ietf.org/html/draft-bjh21-ssh-ed25519-00

This refers = to:

https://tools.ietf.org/html/draft-josefsson-eddsa-ed25519-03

I have also = implemented curve25519-sha256@libssh.org key exchange as = documented at:

https://git.libssh.org/projects/libssh.git/plain/doc/curve25519= -sha256@libssh.org.txt

OpenSSH also implements this, and makes it available under = both this name and more recently as just = =E2=80=9Ccurve25519-sha256=E2=80=9D.

Here, the public key values exchanged = in messages like KEX_ECDH_INIT and KEX_ECDH_REPLY are opaque byte = strings similar to the above. As discussed in https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04= , the final computed shared secret value is converted to an integer by = taking the 32-byte point obtained by scalar multiplication and treating = the bytes as a bigendian (network byte order) value, but this value is = never directly sent on the wire, so I=E2=80=99m not sure the =E2=80=9Cmpin= t" encoding ever applies to it. The only values on the wire are the = public keys and signature values, all of which are encoded as = strings.
-- 
Ron Frederick
ronf@timeheart.net



= --Apple-Mail=_E671D99B-B3F3-4360-A53E-275EF6CD33BA-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed May 10 22:22:09 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295EA128BC8 for ; Wed, 10 May 2017 22:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=timeheart.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CS_IDpoxzsAE for ; Wed, 10 May 2017 22:22:07 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D481127601 for ; Wed, 10 May 2017 22:22:07 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 5064884DA9; Thu, 11 May 2017 05:22:03 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id E946E84CEA; Thu, 11 May 2017 05:22:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id E0BB884DAA for ; Thu, 11 May 2017 02:49:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=timeheart.net Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id 3ggA1Ej36aU5 for ; Thu, 11 May 2017 02:49:33 +0000 (UTC) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 0829484CD8 for ; Thu, 11 May 2017 02:49:32 +0000 (UTC) Received: by mail-pf0-x232.google.com with SMTP id n23so1723051pfb.2 for ; Wed, 10 May 2017 19:49:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timeheart.net; s=mail; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=hPIwb7fpi9Nrv8RUa7DTjE4iC6XJ3cnT3cY0MhWq+80=; b=UsHslBSMnOSAce3knbV/TUFamDyOX5vmEdphL55JKcOQNB4QYKGmd6NwE37N9J9QGe EwRWNdWTP/lpkPpb9g0DP9yWHRqqY8/uHo7LNVja0aoSr65Gw7bjV8useYRrwpmmAWUd SAMGsxoNrr9YYQnyUC72rfeSl9EUmgJnkUOOw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=hPIwb7fpi9Nrv8RUa7DTjE4iC6XJ3cnT3cY0MhWq+80=; b=OLNMv8/1wqOo1hbm28CXfEeLTiEhH6VZXyu9lR3LnxqdfwtHm1famB9bkHy1mVEwH1 9+kujGBRoSv9KQCIyxEj7dCSjRMc8OiE18jJdDaT7j3j0Vxs7YY7gm010+9jm0RanA/C rJFpZMtKwsV1KxsqC4nZGltreAMQozSxTv4C/oOnnVowkCEvByJlEFNxyNZn82qtUYT9 1XRks/VwucV9eEPTAB6AjFZ0tqnFqCy6TNDJnrqKERT86txPdfhhNu73uT7l97Cu1XZA dqFGD0/zPRJyM0BpQ1zrdvkWjiihps5YZX4VlF1j0US66kgnbddUZC7TFFl92dULtMF2 nc9Q== X-Gm-Message-State: AODbwcBQBQsHf732Qj+E5b6fI408VGZEvMrTdQpz8AIOeP/hJNEz986y IYm7MGUUPatxgg== X-Received: by 10.84.130.7 with SMTP id 7mr12474829plc.35.1494470971492; Wed, 10 May 2017 19:49:31 -0700 (PDT) Received: from ?IPv6:2601:647:4282:2200:cfa:5497:d692:7eeb? ([2601:647:4282:2200:cfa:5497:d692:7eeb]) by smtp.gmail.com with ESMTPSA id z68sm416169pgz.14.2017.05.10.19.49.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 May 2017 19:49:30 -0700 (PDT) From: Ron Frederick Message-Id: <0BC6F061-CBFB-4935-9C00-42CB1741543D@timeheart.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_E671D99B-B3F3-4360-A53E-275EF6CD33BA" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: ssh-ed25519 implementations Date: Wed, 10 May 2017 19:49:29 -0700 In-Reply-To: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> Cc: "ietf-ssh@NetBSD.org" , "curdle@ietf.org" To: Mark Baushke References: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> X-Mailer: Apple Mail (2.3273) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list List-Unsubscribe: --Apple-Mail=_E671D99B-B3F3-4360-A53E-275EF6CD33BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On May 10, 2017, at 9:18 AM, Mark Baushke wrote: > Eric Rescorla has brought to my attention that in > https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04 it is > currently specifying the SSH encoding of secrets on the wire using the > mpint process as described in section 5 of [RFC4251] while RFC 7748 > describes using a little-endian format: >=20 > GF(2^448 - 2^224 - 1) and are encoded as an array of bytes, u, > in little-endian order such that u[0] + 256*u[1] + 256^2*u[2] + ... + >=20 > This seems to be what is being implemeneted for > curve25519-sha256@libssh.org, so I should make > an explicit note of this in the draft. >=20 > However, I am unaware of any curve448-sha512 implementations at > present and would like consensus that it should also follow the mpint > method rather than the RFC 7748 method. >=20 > Please reply to curdle@ietf.org with your opinions. I have implemented for ssh-ed25519 public keys and certificates in = AsyncSSH, and my implementation currently uses opaque byte strings taken = from the implementation of curve25519 in libsodium when encoding public = and private keys. These byte strings are encoded as SSH =E2=80=98string=E2= =80=99 values (4-byte big-endian string length followed by an array of = bytes of that length). The public key is a single string value and the = private key is the concatenation of two string values (public key = followed by private key, each with its own preceding 4-byte length = value). This implementation interoperates with OpenSSH. More details can be found in the Internet Draft at: https://tools.ietf.org/html/draft-bjh21-ssh-ed25519-00 = This refers to: https://tools.ietf.org/html/draft-josefsson-eddsa-ed25519-03 = I have also implemented curve25519-sha256@libssh.org = key exchange as documented at: = https://git.libssh.org/projects/libssh.git/plain/doc/curve25519-sha256@lib= ssh.org.txt = OpenSSH also implements this, and makes it available under both this = name and more recently as just =E2=80=9Ccurve25519-sha256=E2=80=9D. Here, the public key values exchanged in messages like KEX_ECDH_INIT and = KEX_ECDH_REPLY are opaque byte strings similar to the above. As = discussed in https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04 = , the final = computed shared secret value is converted to an integer by taking the = 32-byte point obtained by scalar multiplication and treating the bytes = as a bigendian (network byte order) value, but this value is never = directly sent on the wire, so I=E2=80=99m not sure the =E2=80=9Cmpint" = encoding ever applies to it. The only values on the wire are the public = keys and signature values, all of which are encoded as strings. --=20 Ron Frederick ronf@timeheart.net --Apple-Mail=_E671D99B-B3F3-4360-A53E-275EF6CD33BA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On May 10, 2017, at 9:18 AM, Mark Baushke <mdb@juniper.net> = wrote:
Eric = Rescorla <ekr@rtfm.com> has brought to my attention that in
https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04= it is
currently specifying the SSH encoding of secrets on = the wire using the
mpint process as described in section 5 = of [RFC4251] while RFC 7748
describes using a = little-endian format:

 GF(2^448 - = 2^224 - 1) and are encoded as an array of bytes, u,
=  in little-endian order such that u[0] + 256*u[1] + 256^2*u[2] + = ... +

This seems to be what is being = implemeneted for
curve25519-sha256@libssh.org, so I should make
an explicit note of this in the draft.

However, I am unaware of any curve448-sha512 implementations = at
present and would like consensus that it should also = follow the mpint
method rather than the RFC 7748 = method.

Please reply to curdle@ietf.org with your = opinions.
I have implemented for ssh-ed25519 public keys and = certificates in AsyncSSH, and my implementation currently uses opaque = byte strings taken from the implementation of curve25519 in libsodium = when encoding public and private keys. These byte strings are encoded as = SSH =E2=80=98string=E2=80=99 values (4-byte big-endian string length = followed by an array of bytes of that length). The public key is a = single string value and the private key is the concatenation of two = string values (public key followed by private key, each with its own = preceding 4-byte length value). This implementation interoperates with = OpenSSH.

More = details can be found in the Internet Draft at:

https://tools.ietf.org/html/draft-bjh21-ssh-ed25519-00

This refers = to:

https://tools.ietf.org/html/draft-josefsson-eddsa-ed25519-03

I have also = implemented curve25519-sha256@libssh.org key exchange as = documented at:

https://git.libssh.org/projects/libssh.git/plain/doc/curve25519= -sha256@libssh.org.txt

OpenSSH also implements this, and makes it available under = both this name and more recently as just = =E2=80=9Ccurve25519-sha256=E2=80=9D.

Here, the public key values exchanged = in messages like KEX_ECDH_INIT and KEX_ECDH_REPLY are opaque byte = strings similar to the above. As discussed in https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04= , the final computed shared secret value is converted to an integer by = taking the 32-byte point obtained by scalar multiplication and treating = the bytes as a bigendian (network byte order) value, but this value is = never directly sent on the wire, so I=E2=80=99m not sure the =E2=80=9Cmpin= t" encoding ever applies to it. The only values on the wire are the = public keys and signature values, all of which are encoded as = strings.
-- 
Ron Frederick
ronf@timeheart.net



= --Apple-Mail=_E671D99B-B3F3-4360-A53E-275EF6CD33BA-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed May 10 22:22:21 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E3C128BC8 for ; Wed, 10 May 2017 22:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.39 X-Spam-Level: X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=denisbider.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1sC6_opZMge for ; Wed, 10 May 2017 22:22:18 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5851C129AF4 for ; Wed, 10 May 2017 22:22:12 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 26F4F855B2; Thu, 11 May 2017 05:22:10 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id CCEE7855A7; Thu, 11 May 2017 05:22:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 4850585599 for ; Thu, 11 May 2017 03:53:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.com Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.netbsd.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id jgZvf-MPzN4C for ; Thu, 11 May 2017 03:53:49 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 9CD0C84CE1 for ; Thu, 11 May 2017 03:53:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to: references; bh=IgVov2NUbTGjomFsLNS2rO5UJqS9kkxV4NHqBfjNGE8=; b=QrMZCeBZIZrdzV7dV9YlZpXU1V84nP+Ojf6BFZTvk0aWC2chyXrwNKurmnsHO13jkfb0pHWHnbTW2 KhyHB6ou9dgAuHLLjpm9Z2QY73fDZRUO6wGf4HbqTT3/Uymdb/Bj8h6AaYGI8VYhhy5JYxrMm8nnZI 6dSvVEukuM+yuUJfSImL4EWiOIGOUpWUYwm5/A7SbVJapQz4Zg5U7oUIPUvBPKkYDtVKFZzgarK6VF BBN/vbtNKC0L7dBX+Y6fgomPbBC6M3P2usj0MRalgM2zyrp7dpEb2yaTRQI6km9mxRuvwRBdO8WDHf syjSI5/glQU9yv7zQn81wF4Zj/pk2VQ== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com with ESMTPSA (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Thu, 11 May 2017 04:53:44 +0100 Message-ID: From: "denis bider \(Bitvise\)" To: , "Mark D. Baushke" References: <72914.1494466759@eng-mail01.juniper.net> In-Reply-To: <72914.1494466759@eng-mail01.juniper.net> Subject: Re: ssh-ed25519 implementations Date: Wed, 10 May 2017 21:53:01 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0099_01D2C9D7.CB6F8240" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0099_01D2C9D7.CB6F8240 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Mark! For curve448-sha512, I have no objections for either choice of encoding. = What=E2=80=99s more important than the choice of encoding is that there = isn=E2=80=99t doubt about the choice of encoding. That being said, I agree it may be slightly preferable to use signed = mpint, given that this would be consistent with all other SSH key = exchange methods, including Curve25519, and it would be weird for = Curve448 to depart from this. denis From: Mark D. Baushke=20 Sent: Wednesday, May 10, 2017 19:39 To: ietf-ssh@NetBSD.org=20 Subject: ssh-ed25519 implementations [Second attempt. my first attempt got bounced by fraud detection checks for some unknown reason. -- mdb] Hi, Eric Rescorla has brought to my attention that in https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04 it is currently specifying the SSH encoding of secrets on the wire using the mpint process as described in section 5 of [RFC4251] while RFC 7748 describes using a little-endian format: GF(2^448 - 2^224 - 1) and are encoded as an array of bytes, u, in little-endian order such that u[0] + 256*u[1] + 256^2*u[2] + ... + This seems to be what is being implemeneted for curve25519-sha256@libssh.org, so I should make an explicit note of this in the draft. However, I am unaware of any curve448-sha512 implementations at present and would like consensus that it should also follow the mpint method rather than the RFC 7748 method. Please reply to curdle@ietf.org with your opinions. Thank you, -- Mark ------=_NextPart_000_0099_01D2C9D7.CB6F8240 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Mark!
 
For curve448-sha512, I have no objections for either choice of = encoding.=20 What=E2=80=99s more important than the choice of encoding is that there = isn=E2=80=99t doubt=20 about the choice of encoding.
 
That being said, I agree it may be slightly preferable to use = signed mpint,=20 given that this would be consistent with all other SSH key exchange = methods,=20 including Curve25519, and it would be weird for Curve448 to depart from=20 this.
 
denis
 
 
Sent: Wednesday, May 10, 2017 19:39
Subject: ssh-ed25519 implementations
 

[Second=20 attempt. my first attempt got bounced by fraud detection checks
for = some=20 unknown reason. -- mdb]

Hi,

Eric Rescorla = <ekr@rtfm.com> has=20 brought to my attention that=20 in
https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04 it=20 is
currently specifying the SSH encoding of secrets on the wire using = the
mpint process as described in section 5 of [RFC4251] while RFC=20 7748
describes using a little-endian format:

  GF(2^448 - = 2^224 -=20 1) and are encoded as an array of bytes, u,
  in little-endian = order=20 such that u[0] + 256*u[1] + 256^2*u[2] + ... +

This seems to be = what is=20 being implemeneted for
curve25519-sha256@libssh.org, so I should = make
an=20 explicit note of this in the draft.

However, I am unaware of any=20 curve448-sha512 implementations at
present and would like consensus = that it=20 should also follow the mpint
method rather than the RFC 7748=20 method.

Please reply to curdle@ietf.org with your=20 opinions.

        Thank=20 you,
        --=20 Mark
------=_NextPart_000_0099_01D2C9D7.CB6F8240-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu May 11 06:37:00 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2193D12EB99 for ; Thu, 11 May 2017 06:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIN_eYbzTQeN for ; Thu, 11 May 2017 06:36:53 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCB21129B38 for ; Thu, 11 May 2017 06:32:47 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 360AF84E01; Thu, 11 May 2017 13:32:46 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id A6FBC84CF0 for ; Thu, 11 May 2017 13:32:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id yl9vqagihNu3 for ; Thu, 11 May 2017 13:32:41 +0000 (UTC) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on072e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe40::72e]) by mail.netbsd.org (Postfix) with ESMTP id C72D084CE1 for ; Thu, 11 May 2017 13:32:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YsdaRhjQmrIqlMXY0GDgL4JY6kJys4f7RE+xoRuExIM=; b=KcUSuhmiBEB3iCYZv3oM1BKw7b1byP1KUidy7f+1qNwMdvCz/LRuOLzp6Z9jquuOnHt2ro4HR5nvDP+VS0ib29jhrZE2S00nbnoAAjhruFs0w6xda5l/G9Jph0QXVp/cJdMAIiOUm8IwuZjBTWkTNymupYClbEhH/vLhfqQJhRk= Received: from CY1PR05CA0004.namprd05.prod.outlook.com (10.166.186.142) by CY4PR05MB2902.namprd05.prod.outlook.com (10.169.183.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.5; Thu, 11 May 2017 13:32:38 +0000 Received: from CO1NAM05FT041.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e50::205) by CY1PR05CA0004.outlook.office365.com (2a01:111:e400:c5a4::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7 via Frontend Transport; Thu, 11 May 2017 13:32:38 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by CO1NAM05FT041.mail.protection.outlook.com (10.152.96.154) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1075.12 via Frontend Transport; Thu, 11 May 2017 13:32:37 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 11 May 2017 06:32:36 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v4BDWYq0027592; Thu, 11 May 2017 06:32:34 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 7B18411446; Thu, 11 May 2017 06:32:32 -0700 (PDT) To: Eric Rescorla , Ron Frederick , "Brian Smith" , denis bider , Simon Tatham CC: "ietf-ssh@NetBSD.org" , "curdle@ietf.org" Subject: Re: ssh-ed25519 implementations In-Reply-To: References: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> Comments: In-reply-to: Eric Rescorla message dated "Wed, 10 May 2017 09:20:37 -0700." From: "Mark D. Baushke" Date: Thu, 11 May 2017 06:32:32 -0700 Message-ID: <36528.1494509552@eng-mail01.juniper.net> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12;IPV:NLI;CTRY:US;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(39400400002)(39840400002)(39450400003)(39410400002)(39860400002)(39850400002)(2980300002)(189002)(199003)(51444003)(9170700003)(2950100002)(76506005)(53416004)(47776003)(105596002)(54906002)(50986999)(229853002)(55016002)(6306002)(8656002)(86362001)(53936002)(77096006)(76176999)(7846003)(6392003)(54356999)(478600001)(305945005)(7696004)(2906002)(2810700001)(106466001)(6266002)(48376002)(6246003)(189998001)(38730400002)(4326008)(356003)(117636001)(7126002)(5003940100001)(8936002)(8676002)(5660300001)(81166006)(50466002)(39060400002)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:CY4PR05MB2902;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;MLV:ovrnspm;MX:1;A:1;PTR:InfoDomainNonexistent;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;CO1NAM05FT041;1:FGKJDnZDyhO1hivfO28qCfuGxdQsq52sE1pCKhC/1XWgY5lgu12kjsrX060awP4btp0NeUp8RDKAX2mxoBaAfpG3vRUQOFhGsCFdSEnxZf64WYB5yvUxrwagc8H966Ij6HGdLVwYPxsgnStt0OD+G2EG6wyqLAXoIqGxma9KlMTD9/0H841ka86LC2Rtw1UEVK2eRA0tv7OsbCe8acNWB/R2nF5F0pn3XZdXkmO6QgrZn5sOPX1f964BhwS3d+czfaEXvRAf3m48O1e4I56LHkMSqtxAPG+zkncUYPHvJQD2BknpxXfOCTll+eAZW7aZv0XxXR6pgimTEMBhR6DWhUz1BcfycD+U4ocCc4E620m1dtyqlvekxRNpA84n307Uz98Z7hkIJWoDduATQD3RB04kD66RjH/ci6yriJr9tM8Cyo5P6PMN5LaYV6BZsBX7/vqk46ATperH/OCZBxokZjlG5GEODt3KWx1OTiLNVIiMYVOa6M636lmz1cJJmnkAAR3FDEmeUrfB7ggrZHZXw9ds7iHrFYx4d7NQssqHL+XxXEUsm4box9kV0PhE3bBJXMV4ylXicFkapwX2Q6r98pxkncz40bUpMPlZ9vXHZ99tN/5G3/D4wI+4CZsabHKL X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY4PR05MB2902: X-MS-Office365-Filtering-Correlation-Id: 148a9d25-8ac7-49d7-f682-08d4987230ea X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(201703131423075)(201703031133081);SRVR:CY4PR05MB2902; X-Microsoft-Exchange-Diagnostics: 1;CY4PR05MB2902;3:iEWZlOm3JpaZfv9rZQRMNKEJofLMVr6LoV3x5MP3YzNA3MyzM3c5+o1CW0au+GjE/94xSH2fu1NtjYuJXaA4dpuBPfruEdL5SmtZWcJ0ZHuFdbijkP4Fsih+RY8POHBuvSPNhlPdHl+NowoH26ldhNE7C4PG7R4Wcb4pQEhZEf5GoGPHi9/bC4A2oQi4LANbiUBi8Dig4UnN0YOtgQjT0FkXWv7C/l8XKU1fwkbz/nKP1nzcHlM0ynvVgsD9jSEX+27ZcSeUQbNTfSra8QzS3TR90+D9FFIW+AGBXXlRcyH0ZpS6as8DJsolOX1LD6LSO5ULBw44Rx4sRki9Bs29xKhse7zloAv5RKwUXPW1rPv93R3syTKvOt3f9/jqr1+ON2Hb6ZShQSymwTOVfBEQgV59ba6Enjj//5cRaV7a8AdoFPh5Vl9EYTK0bG2zS5LrbxqEN4+Td3yFCM7A4ycCbQ== X-Microsoft-Exchange-Diagnostics: 1;CY4PR05MB2902;25:y6yBy1R2eXxgyMvZ+6J39uawfMW5IpRh1nD7G932of7/wh6SRGp3hUe58i5PgwaHs2Lm0tzIrbMCPbY97zDZqB9wpMf6hztQnGJMPoWCzLDjfTamdKJAn2AlWJ+f7es1Yr3/Ssz/gBRJNrWlh1rxyiCeBxHhand28+D+GNRrWjBMcXGsYxdfKoSqN6ZaizHyr+NFHIl8H7MY+r1rNxhIQFTdkjTv9Kw3QdbkpDmE44FrmGywAnSoa9opZhXpsTpiScErOVppgj4TOjbVz9eTaxEwIQiedXi+8DFMr3EpNHy5yW5oISvBtrpFLwzayc7XjGi9Y7pJgs/4z4DSefH6AexukozpQwVp3FhH7sEVT/+OHkziBOgulPnwpbgQdaFEkPc+p693kRDeqfPln1i/b4Uxde5q6C1dfNTwblFMAgev8DQkVGm2CSWS/aGYvM30A2u3xcWGeqpeuAbM9M+qvvXi4EnZurypj7Icho5sKcE=;31:677kC0IycnoldK9J7d0r2CN4HYJ4dUsS/jCu27sTSxD3LZqwx4y9OyMMyA99tPS5ZO60xvxrOJ2l1tddvJN2qA47XYsYmUYD9hGX9Rx160Y5dFErgXuIlh2pG9soJi2eIBd+dU8IUWTxQqioLfv9taEH8YPcbzImycyQEJ58Wo0WK64nMZ918SoI+T0ln2CGfrlqBc6WBJw7UdARWWWk7Ov8nyg9H4vZvObi30PVxgdPrMO/n7Qb36IJd/YzAdjcXrYIp5KSJ82lsa1ddwf1+w== X-Microsoft-Exchange-Diagnostics: 1;CY4PR05MB2902;20:3Paz/HG+0uoOOafyG3sP+2ZZDdmRd1SOg+BtsI2rzldaU0z37hT1NC0W6AD914nYGAKUk1ivY6a3fqNKpZDh3pPwGuIGNw5ArPPEJ+alSAp9oKGPYJQPpof5xRWA4rCy7XlZbQYeDM0MF5CKV+TBSwKrn31r9F2/cqZ4UFyHbOW3D0bfrQldHr1d6GdtSJIVtmUcFF2D/9+TMXJwl0Jttx23bL6HB2HkBkN7T6U/BiRaekJW8kZA4sYVR3iHgi490Rj9M6eHzRUYHbZT/xXSmaSpHZxxER4Xnpi9ngXL4M8qHF90dPlMAJZ2QMqmuqB40S8lnKbJk5my2X+N10pmBL80LR+lUgWKs/T8sVJxxWMiCdt9SlQZHFZIpDKeWHR8c0imgArrgwsAY3tjH7vQJHCBd/lZiKrrmaYjWkLHpgpLHd1erkLH4ObYipateUBYes9Qcobod2Z2Ezum79ost6HAwnqN4xufXbzI//0bdAAYStLNHzzVPNzGnU/Visb3 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(100000700036)(100105000095)(100000701036)(100105300095)(100000702036)(100105100095)(6040450)(601004)(2401047)(13024025)(13018025)(13023025)(13017025)(13015025)(8121501046)(5005006)(3002001)(10201501046)(100000703036)(100105400095)(93006095)(93003095)(6055026)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123558100)(20161123562025)(6072148)(100000704036)(100105200095)(100000705036)(100105500095);SRVR:CY4PR05MB2902;BCL:0;PCL:0;RULEID:(100000800036)(100110000095)(100000801036)(100110300095)(100000802036)(100110100095)(100000803036)(100110400095)(100000804036)(100110200095)(100000805036)(100110500095);SRVR:CY4PR05MB2902; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;CY4PR05MB2902;4:8zsfbIy2kV29uGrLWHiKW4xNYZSlPsg5q5C/a/83WD?= =?us-ascii?Q?nEuRE1iv5NUzywQUQDvCtQWkOCoes5HTYhqtQ73OuUs5cBTn5t3GhepmU2Ur?= =?us-ascii?Q?T+uIPhepVWlapBdnjclvX8s4CguyqxcCyK0t5Y1xfhoKR+zGHQQPW271dcVK?= =?us-ascii?Q?vF3JpFvUC/WjDT8oFqeFfV2He+YostSWzXFGh6fyXXAvyAw9v2jLSVd8Tnyp?= =?us-ascii?Q?B/5hTTIVuygiVWQ/1wOSNIS1JzPwDvaWeNrW6gnaCQtd1c9V6XXqP+HuGIG0?= =?us-ascii?Q?DamaU5LskI5fTg+ukrlG8wt/ySNx6eXr1IRtYTKaVA3THK0/YEHL+KPGDV9L?= =?us-ascii?Q?jP1oJbqEWOuLFBM28kFbjrZaf8N2KEkHey6RC8nxeZ1uIwmEJTpKyb16eeOB?= =?us-ascii?Q?JtfAUkvEkpjedQjbebunARs0x/c4nv8HJ3eShFbYYzZjeAuCJoaINPaNVCLv?= =?us-ascii?Q?BegKQB7HADO6IcRrEreX93IIFU30t6t0Cv9uk9gluEA58LoHoOpuaxcmOS4e?= =?us-ascii?Q?+hveZKeXS74yZCfoYMPMZnBXYR+6lEc/ib3VQOERy16aCrpWAHpIo1VcHIoP?= =?us-ascii?Q?5d6RqEekrLnO5wzYZ+8KUnIDFNd/SLsr3BaLO1JXAjLFYJNC282Tba7jiZvg?= =?us-ascii?Q?T/v34CsigZXO2YXfHRh7De8WHGG5Blk50Qop5/UAUcgvU5YF0dPVJtRJid9e?= =?us-ascii?Q?ddS4EPQ9deJ/4AU4QhVgIUQ9uGYsVQTjt596oUmsieZxjOzyfEfFRH9WSDUB?= =?us-ascii?Q?0RZ7H9Zx2Z4XmT34SjT0R2p2bkKhek/74BDEdcAfuwQWk5OYzsZO3Z3gDbXL?= =?us-ascii?Q?kqDRNUL56rlwQR7+0dBWYK/LshuQZg9laKvjj/ifGggokpLh66aC9otLYRvl?= =?us-ascii?Q?P/86P5zGWQCtbF+1a2RlDBmX2D2vXBsUqVulIIVG0gb9cNF8T2G+wiY8NLn7?= =?us-ascii?Q?Lq8uvKbtwC/IeVX/n4xLqJG/STTWRAEmqTVzHxoKjjZMpbQma5w7pCGTsM2o?= =?us-ascii?Q?aJ4Q0u3MBFyokgPRJ3JC4sdKauL89dQ+3ymS8k5Q+aBuSJi13CMpPzArkXnt?= =?us-ascii?Q?S1JuKvYPf9yjq8iffOoyJho7Vocv/e9ik6+Ovl/h+xOcJpq33By2YpT/Bwxs?= =?us-ascii?Q?VIrHO/+x5mQ+Yk56/qZNm7OUsRh7bixidWodAjxFLrQvvqqKNCGnymR1BrdJ?= =?us-ascii?Q?XWl3K2qi+CbzMw3IVqYzSMEaob+k27tPxJFnyC+tlenmMi7y2CcRjpgRr+BU?= =?us-ascii?Q?ElqLz4UWYnKdFWeVg=3D?= X-Forefront-PRVS: 0304E36CA3 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;CY4PR05MB2902;23:Kgh4Iy3DjsPoTjiAkbBj0K9spzBL5U9oKggvuxIKT?= =?us-ascii?Q?y0bvC/qYrMJPUpjtU8Cv2QbVlQSN3VtkFZwEr+G6PffWOu1z/do/ehgD+Tam?= =?us-ascii?Q?AkpevMRfqCCGtmdUsGvVXZqJSVs4epz9XjaIzfxQKhRBQrz5vHuTGW81CdUs?= =?us-ascii?Q?B6FB6q8hHd73j/KxUa+unlgF8BRCGtXdsLaoa6WT2suBrMajGfTnvtUK6UrT?= =?us-ascii?Q?BmCACi8i5ACTV2zZ2qw9jmgWfwga+TITrA6/NSfnQNMtE/RZOiMmz2Ig+MRF?= =?us-ascii?Q?9O0tPhMGjvkiEPpGAkJrW4ZG85lftQ19Pc0FzwVQNGPBTHoYrptIz9e0pyku?= =?us-ascii?Q?+ryY6xbRdrTw65ywilc+kOLYLtbe+b7rbeKIlCHmOe6QiXB/XG7TatmPkErE?= =?us-ascii?Q?TRgkE4louKGng8wimN/5Lyb5z0y5EkCtTnF9SyCtb+bJkaO5aGDvHSotqE9f?= =?us-ascii?Q?UfCUMdHrUgnCwzwjsKBJrSXQtAAJ/MZ4iFEQ0dCXYHUdeOzc5jv4vEtxt3P2?= =?us-ascii?Q?gU/dvc5uEGz6k8s6vkh7T+EIq4jHOReh+ZWQA+hsT4G3W3lbPB44zACPfdaB?= =?us-ascii?Q?P/kTc5GTHKse0DoK9NrsDcI862p/MWPNxtbSDD9JZcQH0/EBVq9hGS+2zvnj?= =?us-ascii?Q?+ZnzaC+oSJY1n6SCaHBpuMqDEr45DAoDsbjsAq9nFZCYg73eQdpClyWAnpQQ?= =?us-ascii?Q?hVA5dA50jXv+Ps2HxTRs+EolrfFqr8eDM2MwJkwlcz3g1FRS9mK8kEb7M5ww?= =?us-ascii?Q?Jj+q+xX7eNwBtO/ZLJq7g92I8s5jUHTwuTY5iWEiGwB6Ve33xlUEa/vg6KhL?= =?us-ascii?Q?CpEPaGGukXQIfAhHRk9K11/oRKzEOKV1kKsEaVIJS/cRJfamZygaQuMrEffr?= =?us-ascii?Q?KbQbGxtUeRveaybZIIJPobTb1LSfTvLtshCDO+mnS4elM2/LWKtphmxLscUB?= =?us-ascii?Q?SoJu/Wd/JilRDcTNywg7mhVl+KF8oMiU92ABf7NY0PwCKhNRD9/x3Rfzxr1Y?= =?us-ascii?Q?eKAYL+UDANx0AWdtrT2v1nkM6M6LPWWy5LQCJCa5kwRC9yZDBFmih/AO1xmO?= =?us-ascii?Q?wJneSRftVyQm+K6ZmopKMwKQCOhivpwkVSDyzepdMQ2Mi3cvB9bCIN84/jzV?= =?us-ascii?Q?ijq7EXanxi+hf228RkdzZIcy+/BkC3jP1MI7ZilZKPKVv2D7/ipLoWYKezDZ?= =?us-ascii?Q?MPP/4oz+Jf1cNZKGlE/ozKGAe1jBNCLXdO+Uxw7048pS6Fj//U+QTeGvOyti?= =?us-ascii?Q?DAPDwXKzYaVgbl4avF/fYGVE51D2tT7JKGTHlN6dIWpoE7SzzZlN1YK4qXZr?= =?us-ascii?Q?y0xhGZEijbJ+gW8QFxFqhk=3D?= X-Microsoft-Exchange-Diagnostics: 1;CY4PR05MB2902;6:F2lgybfrGeQ7Ab6k6e0Uu5NyKjZADjWhlaSABvByAgLgGxiupz0IxD3gLwCEFUXDAX42BetyJPDEm8BPiNW1YKNn+eQhcNiJRS6If1aSajQMQ3cZtgknXcC1XdtBkmKtIIGi5W1pPodUhcLXQd0JtaxIimJ90DWVfc+o3/36KH3yRG2BJ9T7IdVyxBHI302e7NMc1ResZR93Q/e4HnBthG1BO9QMt0v+Nyxnt06E+rgpiXqwMHz5DN2zosh0fB3JL0hwmRB68HvCArKVXO4ENnLg+2rWh2rTkt/RpsxgMehxi8JE0fPniU+3h8He+Ckt2A/rB3WZys/clNZQLON+3JyLH4WUlBLnSrfaOJYGae2ZTficzu/ChisTv8RbVEHqg5GkKK9qniXV7SLQunuN/YLJMJTLeECxbCpcvtHgJpBTIQI/vgH7ZzNcdbdnlv6BzhwHVlTMRQ9mPgiZ2lrrjBzVeZ/QxMHo3iVpuW7TqN31ibw9WmiDn64Sss+YFA7aM4OIEvQuEun8SRdtfeW5ovtA66Om5wCDIfapnA5Eaw8= X-Microsoft-Exchange-Diagnostics: 1;CY4PR05MB2902;5:5fKX/bc2F4Ec5mO5f7ic11+sUM4sER6XBERS5U+0pMae3ziNVFwVS8cOOhvtgLONWGYT78EeLNXv0Agr0V7rUo7WX+rFCB7ILykQQZJSPMty8xo/Nz6u7zvjL1Yw8W+dTgkUqK4NRqT+I2wBCVs6Y7rAlITq7aOxMk34xsx4DopAZbK0drEh47YZp3+NGg87od1VX2TmHlBMvacZyqHgIICOY2zLQt7Eqlnui2irwH/om8NbrCgFXMXfP1QBEeutMu/H7Tc98lX83j1wiAy3tQOAAFYKfCM77Yf/5wyJVPUK5B+qwzTTQTEEAFtk3/hYPeQrti1qAdwQRqDGT7gKhqeOCcB+6mHJOSZHTLli3MO93YxBJVu0r8zOG5a+eh4ZD2jbUY/TudPCgRP+suea1eQWBh2AjhV9IaZkw8b8/KDa9W0+SjGGuI0ffftHq82g38Krq3pWDCmgz6OM3VKfdCdCcigbCloSAMONtBvL8yXNWObiDDazBHdreupRFBAo;24:/s3ZbLTL77k/VwrWzMBh1osWH1qBkUUX/OcPa8AffxtUAOpSG13UME5L3qVI4hGYma8a8XCw+XGequPnNHbxbyXAr803qFDB3BbM5pPKd1g= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;CY4PR05MB2902;7:ke5I83yxoOQ0r//GkpktxacsmJDlBS86M/daTp5ZvQKDKvrmPACcprQAI0vL+6ozJKaXT44X6e3ecJ3SS6HXwZ+dPAibhEOzkfgbKm2dLAAA2lfSLJLB1tvMVcKxEQhmoC4YSDD/n68vzGjJkZmFeq7JExMXgxRmWhjxY0MJciUsQBdghDn7xRh3JihQn1+/8pOQBYRjaWsKjtt0lPD1YD2Tg0LVjpEDAsb/cBqpcEwgtmetKn+pL1nUX0S/ermXiAsQPiEhYleF+DMaNrrOUx5L8Y+25Y3K32TKyhcGgkOlUJiWtZLe7LEkTKsqM09uxFAKQWU9/H0vPRl6+6uo7w== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 May 2017 13:32:37.7839 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.12];Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB2902 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list List-Unsubscribe: Hi Eric & Ron & Brian & Simon, Given input from folks so far, I think it would be better if both Curve25519 and Curve448 continued to use the "mpint" format for K when generating a hash even though this is not what RFC7748 suggests. Would it make sense to include the following text to the end of section 2.1 of https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04 ? When performing the X25519 or X448 operations, the integer values there will be encoded into byte strings by doing a fix-length unsigned litle-endian conversion, per [RFC7748]. It is only later when these byte strings are then passed to the ECDH code in SSH that the bytes are re-interpreted as a fixed-length unsigned big-endian integer value K, and then later that K value is encoded as a variable-length signed "mpint" before being fed to the hash algorithm used for key generation. to help clarify the differences between RFC7748 and what is happening in SSH? Much of this text is borrowed from what Ron Frederick has written to me, any remaining confusion is my fault. I think that the above text should help clear up the confusion that Eric noted in this section of code. If there are no problems with this text, I will release the -05 draft with it. Thank you, -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu May 11 07:46:15 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9B9130141 for ; Thu, 11 May 2017 07:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9i9oTBdJehPg for ; Thu, 11 May 2017 07:46:14 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 405B113145C for ; Thu, 11 May 2017 07:39:29 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id C953684D95; Thu, 11 May 2017 14:39:27 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 12BA884D7F for ; Thu, 11 May 2017 14:39:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.netbsd.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id w6qB4qeZkK1k for ; Thu, 11 May 2017 14:39:24 +0000 (UTC) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on071f.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe49::71f]) by mail.netbsd.org (Postfix) with ESMTP id 5569984CF0 for ; Thu, 11 May 2017 14:39:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=//2uhS/xEAJNL5YxufE+luly9MaUNcnKjxgcQMD6gmo=; b=jZZPxAz4opSlUmtdFO8IgcU7KCB86Upx8obBDNLBmEYdOLBM9kUnMhvkduOBgjq+QhGOoYlK39eVgBH0cCqvpGhoAPvVipgtmquTYpaAji84FcpKeiQHs7aQil5vxNQLtewB+lPHlNibkfzaNi8VIfpFbD+gXCNfQilLGsX87t0= Received: from DM5PR05CA0013.namprd05.prod.outlook.com (10.173.226.23) by BLUPR05MB259.namprd05.prod.outlook.com (10.141.22.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Thu, 11 May 2017 14:39:20 +0000 Received: from BY2NAM05FT034.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::208) by DM5PR05CA0013.outlook.office365.com (2603:10b6:3:d4::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7 via Frontend Transport; Thu, 11 May 2017 14:39:20 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by BY2NAM05FT034.mail.protection.outlook.com (10.152.100.171) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1075.12 via Frontend Transport; Thu, 11 May 2017 14:39:19 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 11 May 2017 07:39:12 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v4BEdBr6007206; Thu, 11 May 2017 07:39:11 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 3A22111446; Thu, 11 May 2017 07:39:11 -0700 (PDT) To: =?UTF-8?Q?Stefan_B=c3=bchler?= CC: "curdle@ietf.org" , "ietf-ssh@NetBSD.org" Subject: Re: [Curdle] ssh-ed25519 implementations In-Reply-To: <76604306-d93a-5156-2350-636d3bda2323@stbuehler.de> References: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> <76604306-d93a-5156-2350-636d3bda2323@stbuehler.de> Comments: In-reply-to: =?UTF-8?Q?Stefan_B=c3=bchler?= message dated "Thu, 11 May 2017 15:15:31 +0200." From: "Mark D. Baushke" Date: Thu, 11 May 2017 07:39:11 -0700 Message-ID: <47874.1494513551@eng-mail01.juniper.net> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12;IPV:NLI;CTRY:US;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(39410400002)(39850400002)(39400400002)(39860400002)(39840400002)(39450400003)(2980300002)(199003)(189002)(9170700003)(54906002)(6392003)(7846003)(8936002)(356003)(2950100002)(6916009)(2906002)(55016002)(38730400002)(189998001)(478600001)(53936002)(305945005)(6266002)(2810700001)(6246003)(7126002)(50466002)(110136004)(47776003)(48376002)(8676002)(86362001)(229853002)(54356999)(5660300001)(81166006)(106466001)(76506005)(105596002)(77096006)(117636001)(7696004)(53416004)(4326008)(5003940100001)(50986999)(76176999)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BLUPR05MB259;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;MLV:sfv;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BY2NAM05FT034;1:P4f9gpv4p7xtAAiTWGlOumrMKp65F9Iv6BOqfPvY38Yh9HKNyCDA0KklHoxKnBYh1/xeqc0fq0E+6bC8/DM40epPWdlqjSIYQjMQoDaWp7MfuN71wPjq/5EvFpbzoUIiz3BZOR72bWP7MtFY4rzglWB30twukC/YKJTFZYVOAu0jBYZsA3izde64L+BxSWc3Bx4+6RQnlVQtHCy2EhihEunDK6YkW7Kg/Z3KW8GUqUhW3S3zGpEp0XQKzPBGf+cmC8eGvfLkPo3fTrRuZIxv/5xrTxdyJNDVXCYmIqGQw+XXcDZP7igfQvjLho0zGXJ+b3Kn07VtLbF4UpicTDaqMyBv6PeCAYTOvGEMI/gQgabVvLa78EPnt2ah2MA6NJZu/i2O8NJ43xLt676kC8os6wY1K2H3zzQ9lGSmFnquO8cduTsnhjc1mnZpzcdl9KpHM0EN5Uh1GR24L1Q8qElmKkn3Z+fwUtK3nug/bLpV9iKMpXRBlNPhUjVW52e10PSZO2KQrjTuTLnyIOflz+8Ep9cFweAOa41iDDtQVb4mAGy7ULJOjPlGRBZL42ZRjqH16ZpqPGMzjYZYBAr8Uu+YVu6LS7FuIxs+M+ItEWm9aD0= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 54dced12-f4e8-40dc-626f-08d4987b8219 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(201703131423075)(201703031133081);SRVR:BLUPR05MB259; X-Microsoft-Exchange-Diagnostics: 1;BLUPR05MB259;3:OttlBNbKMGaSwohwJjSSMrSwQdPykTpLSf2Ypd2oXUa/cfRKMeS7hRuWN5TWQ8Ud/xqqcU++uIm9wcdNGeTY+gWhg3JJQgHlt9YjHtca1EBFrDXcXyoO5PZXdwdKZN+A/fjS9A/+ZohCpQchFuB3qw9vPtyBbfbokwoSU3T7GQhcuX47pSbrybDzQ2LzzMd3/HQTUpyUMyoPbXnFdoXsgcMk13so3HRXr7rEaB49zwtd6omHACyjE3v5ya15UBTZ5UFPX+42p45O2LWUnmM2IfUonScwiHJpgeUYvJwcoF7vdrxr4Oah0uGIosy14tmzQGhiCNSVcMMdZzMtkFBIMKZqxIa7K2LrqtRiWAZ8t4MAMppyEaI1IqDHZUMjAVcPvyKvPEZ/FHaob0VZg6odvdewLSJoN0jG3pDpPwtgkF8LUHXtrKeUH/ElvFCqGcoLl3H5k7Ga7HDl+mSAiF6BSA== X-Microsoft-Exchange-Diagnostics: 1;BLUPR05MB259;25:TLXOtK6Pg/CIZ6ckJFsvFVwmyow2uh+P/TE86IATCynm4Id40FLhkNWGCwR5+a0mYXIje63wV2RJ1w3qVFSoFbKMolTLTq+hnPCle7llFg/D3zOm7zkNdPU8bPWqal14xXJsQs7k2Gp1SMaK1qC/1mZHmcP7VxqFHRcAgxv44KSEqUah9hcEcbd3Ait3Rpeb7rP6NOnbp4m5m7awaQxozpqxeiA2CbZ8JTuNmOoEBH7E3clULAhbVC9kH2flOwTbu70gxmnowQ+Lso2zUADeqy0m82m1/FArKJIsOsnYTytglsIS/RpedwwZHstjHc5WyLG18mwPlayq3S+sQIpvxvqegNc2Tf6vQCj5c2Dy2Ffv0Sneh6LcNpp7AtfkIAIgg3IQhBq4pV72lprlFsq1YeY/Arv/bZHqEz+1fc8X77wFmaHa2U6ZF1l3r5IZ4vZeuwHc72kZkx3Fdy7nGhrEA1rchplw836zSFds0bTuljY=;31:t+XFEUaLzNdEVxIDRlVQRXc621FKeNmzazddAM9cMwmuafj2CqGuwi4voI0HW6r0CXSajjPV7z2tB3PCBBXghzqsj9QvqH/kltT6fE1f9TRxuOthzp2C2nLEd/9ZRG69342fMCHZeo6qQypb2kLxs9kzOKnV2q7L8I7B/4AujYLv175j42J3EcbqRxvzS4ojfB1e/yWFDxUH7YiKTtZcPlrBUai6zYcU4wLdvVtSxdK8fnC2cdK78J7k7d8hfa9B X-Microsoft-Exchange-Diagnostics: 1;BLUPR05MB259;20:TYqb/r+9EX7ISkqc5dI3AiF8ML3KTyCO3EaDPXopRZe7RikKsd5ayislizW0aBxUxFbbmULppEpVXPDm56xDYFWJWYB+5uVXg8+u/WI2oxDsWwROfhbIE+Cca4MbAaG1maIWhNjQlu1lQsHV40FydlAYGeiL0bqgDYTGugJiNA4qC/cphm9rS/XWcZ1kALu4IIsaeNnXjnS/jRTilxEF+IVrne5ipdSA2KLbVHE/5Lj7JTWPLSJ00ka24ZgxSAeeG269eg+bh/tEuNEuc/q6PeMPwYmU9U0QdLXqfRrNot/VczirBcxjZcZNmYBrtQvZtc8tnVbP3wF7Nr1tfW2Y/y3ZuVL0Zf8qqogkSNnsTsVsa7flqpCpmhJXz2qMxKNjoRGFcta5vKlhi7ndn6A+9J5BDEeFEBZrOyxGGidvmJMPLaRW1DVWtm9XF5IfzLSLta86wfJoXTiOqPu2stR/s7wnPb+M68f/GvbMbt3FMrF+PqWtr8J2Y01gqzlyBT65 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040450)(601004)(2401047)(13018025)(5005006)(8121501046)(13015025)(13017025)(13024025)(13023025)(10201501046)(93006095)(93003095)(3002001)(6055026)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123564025)(20161123558100)(6072148);SRVR:BLUPR05MB259;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB259; X-Microsoft-Exchange-Diagnostics: 1;BLUPR05MB259;4:WBBjfVlul+MCBZK4RmaGCtw2IQnjtxP/gz4nlG09WqSsxyD3HgEeZfs0Qo0d32ura2Oi+FYJKxTmI7Km0ib5Gq/soqVvsdZTkFItinn1oUKc0FC5xXOHyrMdb+ivWhKlUsAaQFbJRJdyVtnUY4uLKb5AZr//5XTyyj1dcaHFPNQkA1+gBocHzd180EE1goevLWG3Mo3c4rhiKbaajbB2lE5rM1Pw7eeyBaYz/KTr/DO/w0DYmTAXNLSRL2tGq2TIsv7rQnfMzVIPnJqQnasA7sZ0PTe8pJtp9ZowP/LgIBO1qgRjbFW22SzvVVT9JQ83nF7nNU3rS5Y7VrnHfPaHB1jdJlXzmeLoN/s+wME8u3lQAL0Y+qNjAPZFTC2ZGP2KA2mdIVQk6A4fatPGMl5l0xXpSJ1AlX/DqYqkdF4raDT7pioE4zzf6r0XziFnwMQ6OlO+i0gKZfBLMUCkdHcCaYu6EAgfGazQ5HtshCyCT2MUSlRdDz5eNEchF3FSk4aZncCG6c0+u8SokY+TC5XLb0Vzo1UwDdCAV1DaW4CT0jbbk5wmvaqtepsDZzMWSJv5Xqi8TM+P3DSLoKE5lgvDidFRTgLp9i75x7eg+xB+j3LCk5m9k6WyMMPeqlOpwbRlUHWHmdERL1ka5XTTbmPfI0ZSy8v1IYO/py8/Q8eWE4of7MAk0ncEngw8nMQg37GCBFqKY+WWNbZVZFSaaaZ3xQ7TCSCsSFpLpMjCAM7Hhuhg7HyYGyeUBWfVuWg1HEh+QsDKcb8nY8B1J0XZRwTB+USvyoolKNor4K+Nq3ygXhZMR8v4w3ULuz3dnGX09hsCbQFaD3WeuRY04SRywimZcyL7vhnqOmtR8u5G8NURC04RNBA5w9y4DSy0btx710hNMye0qY8iI4WEHBLwmCq3/g== X-Forefront-PRVS: 0304E36CA3 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BLUPR05MB259;23:e2lvJJLYRm9tC1qr8H53Xvs4GtDzVTVivyDIisBw3e?= =?us-ascii?Q?+9+JXkPk//9s+j9qr8gmKE7INUXKDCk15eKrmGK+Y8JLJwP/k3xCa7elHMd7?= =?us-ascii?Q?7jeMzbw/N/UY677GFTWT4/7Tum/yUKwVnlpwmJK7XGQ1mnX9TOlplESOAclp?= =?us-ascii?Q?geEoAoF4rBvJMRZ8mra94q4OjeesMFY5azg7G6W0R1Tr4UxUOM0cmOKgQdNS?= =?us-ascii?Q?0kDGiTBNDQBpPEQFY0plzn5Y89RUJmN/46hnVby/yOGV2INBpwB2gNI31pi8?= =?us-ascii?Q?AbuQQM03hRejPNtM67AeRlYYerCSgtNgSbzXsf+ruEXWiP//QklL21gMW7ZK?= =?us-ascii?Q?n5pIiFt1yS+M/wcUo6GZ61Lk6tWMWBfvDZz+QYo9pMVaR9UgsNizFAyW/4yw?= =?us-ascii?Q?tk8tdyrhJNZM/aFsHLEay+Dy5LAUUsVHSohu43YIeGs+nL61NZsVpPOMTEiH?= =?us-ascii?Q?qbRDYgvH7ccnIQWEfpT5swk7RQFkieagbMsjJ6JOuJq42zhot5mwzBj8JUzw?= =?us-ascii?Q?HYpnhqSHkVxq/0D4iVYjAwt83BrWNHD39YKOnSlo8D0DX5dFLn3PbPbYPXm4?= =?us-ascii?Q?8cBXVs6jtjDyQ8T0dxO1hPapFSsPpVI0iXJBpbCr6GlcEPBeqFCOqkuKHz2d?= =?us-ascii?Q?kjoJTqfZC48P+W92NaLN4SkklPhu+zImRlIE1FR7srVra6J5aVsP8hvvkfuc?= =?us-ascii?Q?uFjdrIK8mKCEBXX5+rHZifP1VmLSqftga9LBCWcOSBVHHI4TS4G/Z/CTHXV9?= =?us-ascii?Q?GcLh70L1QuwIdqeqONedaY3Q59queAcse+rmmZK/T6KWngsq6lD6MoQg9VbK?= =?us-ascii?Q?T0naJURddM4BZCcWzlkrI0Qw8IQpfS8lXte2zzQ2+yYs5i4neaoAIVg8Oh+k?= =?us-ascii?Q?KW2zyiLjUn4m148yzpcXQOOsksi3foyWxqt7QMEp7BNSdxvGSJMzeBS4ZSvt?= =?us-ascii?Q?3AWok5yWKHW8QWoaBw52mD0gYvqvbyoCrvkEff1XLyJhglEZRe7JVb7qOA7I?= =?us-ascii?Q?iTarG6KjAO6/3dkNr4ww2mps1wnH+Xn5+3J6bU1E8l3W/6bkEoC6aWyYITIn?= =?us-ascii?Q?cUu5500BqxvMFMuua8KhtOguc3LOzlKIiX286C1rVJpJNWl4a+USBG5FcTQi?= =?us-ascii?Q?E9ADIIUmxHeoTtDmOuyIXzq9kLefrq27ot9ksMQO8RvmuGwM90kzQ0H+vXF4?= =?us-ascii?Q?1XDeQnnWbQPMxLzSxR4ceUdLyxY7pV8OQrdR5yPVXIQmElyd2gZBjy43CVkk?= =?us-ascii?Q?sogO5UzCmZAJeYXdo=3D?= X-Microsoft-Exchange-Diagnostics: 1;BLUPR05MB259;6:t6sIl6RJxA3p0xqmRsrtbpdqhtXcLoCbgTjgsaVjO3g4lJCUMonK8MTXwJmlrmg0m6/clSmx0e8VFyZ+92Jkrr5daUFwlTfgncj6oqqXVW/rMswaWH9X4nWZ+DYTX69GNiH+IU3XAAx+y4Zudv++KJ9FarE8rvpp9TUyhTGfPVWYUG5BGnCm/DURcXMTtSFcodXx4FOQS650C9u+C+8VDRbuSrjA8oRrEybh5q+7Hg4C98FGVvJcNzZemh36om3FfdfuvjgXtLUm7jz+cDz2h5Hz2TNkuZ+c5uG1Q9/qoNxeorT4OwVu3NBtkNzpOZzjYfbVTpXf9hqO/y+ZpI0ETSn3TLlrraKLLZGz84uXRJ0JZUXg+pO4KETpNb2ma1LybT1CYJtzYLMHd46hGg3c51WUHuq0H8KxFVpzeiWATObRPHsjWJ5S6LmX0Tdhraoq5KTKnFS2dbdddR76g8KT8z/WONKmKE8UHEz7GRuKLYuknMdV8Hu9MJh6QdKkEwPwm+cqS0pc9L+8cQZESZ6tLkn5c40YNOWdNIh9WsaRqJc=;5:uqT6rM5uXT+RdiTX2TIFzocovFurSFn/cLOgiIGCbU+HgEZO0R3HDu3mawXsTH08UqNIWaWsH7J/CpEJx39olyez98VHZXS1w9+/0CcsIxXFGlNp6bEBL1xfib3WEFeusoj+lr6OSuCEcoA55HI5lw==;24:1Qgz7qOg43nuUrJRuzMFO4qVflagGp4HQjBE5qj+6y6fHovqVPb8/wQMmyh17dIL9/4tNZgze233fyO8tZ67ddKfXLchaEZXB7h+OPTZsvY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;BLUPR05MB259;7:prX8bieCj0JgPMJdHOYFmsU3te3Gf1IdgYYcpc1G06AFFKYhbkR3aCnSLpujQA4EYtXaz+cr2rO3yns2M7IRDaEgd7RLQqhUan3OuMqDiIZ6icTzORU78zKgQxRJUCRUED5BOiSTOfSzRFdufZInzgxDhrY1ddMAKlHgjBXT4ef5AAV/nKdCy75HMPdKuTI6uJmWRtVPXsvVpCYd7Lm+IODRkz6EJMrm2qzjLgoFCMoT3TTaF1SYPJOgsIhEt761zNMRPfZfzu8nYAitUoq85DTcpC1OguGQtkWjOqRCbma6uNEUUz18hu90Grl8AAnrDY/wA7Y7fnqFKj/HG5GUfQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 May 2017 14:39:19.4941 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.12];Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB259 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list List-Unsubscribe: Hi Setphan, I think I will use this text... To clarify a corner-case in this conversion, when X is encoded as an mpint K, in order to calculate the exchange hash, it may vary as follows: Trim all leading zero-bytes of X. If X is all zero-bytes, then the key exchange must fail. If the high bit of X is set, the mpint format requires a zero byte to be prepended. The length of the encoded K may not be the same as the original length of X due to trimming or prepending a zero-byte as needed for "mpint" format. I will also add your suggested pseudo code. Thank you, -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu May 11 08:56:54 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0566131491 for ; Thu, 11 May 2017 08:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KFRtd82yPqp for ; Thu, 11 May 2017 08:56:52 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A03A61314A4 for ; Thu, 11 May 2017 08:50:31 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 5B5908557D; Thu, 11 May 2017 15:50:30 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 5786085576 for ; Thu, 11 May 2017 15:50:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.netbsd.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id C7LFXKq9YF05 for ; Thu, 11 May 2017 15:50:26 +0000 (UTC) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 97D2C84CE1 for ; Thu, 11 May 2017 15:50:26 +0000 (UTC) X-AuditID: c618062d-481ff70000000cf0-1e-591482dd3f80 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 1C.D3.03312.DD284195; Thu, 11 May 2017 17:27:28 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0319.002; Thu, 11 May 2017 10:05:16 -0400 From: Daniel Migault To: "Mark D. Baushke" , Eric Rescorla , "Ron Frederick" , Brian Smith , "denis bider" , Simon Tatham CC: "ietf-ssh@NetBSD.org" , "curdle@ietf.org" Subject: RE: ssh-ed25519 implementations Thread-Topic: ssh-ed25519 implementations Thread-Index: AQHSylsYe0kaNRFXjUKb2lX66nDkWqHvIbRQ Date: Thu, 11 May 2017 14:05:15 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118BDA5B0@eusaamb107.ericsson.se> References: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> <36528.1494509552@eng-mail01.juniper.net> In-Reply-To: <36528.1494509552@eng-mail01.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUyuXRPiO6DJpFIg2mt1hY/mlazW1yZeojZ YuvCWcwWx8/NZbZY8focu8WHe4/ZLLruXGezWLX5H7sDh8e+hsOsHjtn3WX3WLLkJ5PH9aar 7B4LH/Ywely8pOwx+XEbs8ftdxeZAjiiuGxSUnMyy1KL9O0SuDJm3pvCWHCLr+L7rQ2sDYyP ubsYOTkkBEwk7l3cx9rFyMUhJHCUUWJz0zsmCGc5o8ScrrmsIFVsAkYSbYf62UFsEYH7jBKN XyO7GDk4mAXCJJr36IKEhQU0Je59fcEMEhYR0JKYe8ARohqos/cOWCeLgKrE1IXTWEBsXgFf ie0H9rFDrNrIKPHl2y42kASngJlE74HDYGsZBcQkvp9awwRiMwuIS9x6Mp8J4mgBiSV7zjND 2KISLx//Y4WwFSX29U9nh6jXkViw+xMbhK0tsWzha2aIxYISJ2c+YZnAKDoLydhZSFpmIWmZ haRlASPLKkaO0uKCnNx0I4NNjMAYPCbBpruD8f50z0OMAhyMSjy8D2SEI4VYE8uKK3MPMUpw MCuJ8GplikQK8aYkVlalFuXHF5XmpBYfYpTmYFES551w/kKEkEB6YklqdmpqQWoRTJaJg1Oq gdFDJy1+7td1R5yPvJmw9MOED0zyYmubtD9FNwrtD5t/a6lWTnjJ0sOXVkzKtrsg1nPv2h/n jE1MoglHdVZ/kLv675eS4f4n3MePiN4UrjOV5zmWt+GcukO/7emH14zMNUo6eKpC7KrKLLd+ zWv21I3cJH3kg65K8/Lz9md/fvh7YsL1qN6pf4qUWIozEg21mIuKEwGB1baKvQIAAA== Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list List-Unsubscribe: I believe it is nicer to have Curve25519 and Curve448 should be coherent. = The text is clarifying. -----Original Message----- From: ietf-ssh-owner@NetBSD.org [mailto:ietf-ssh-owner@NetBSD.org] On Behal= f Of Mark D. Baushke Sent: Thursday, May 11, 2017 9:33 AM To: Eric Rescorla ; Ron Frederick ; Brian= Smith ; denis bider ; Sim= on Tatham Cc: ietf-ssh@NetBSD.org; curdle@ietf.org Subject: Re: ssh-ed25519 implementations=20 Hi Eric & Ron & Brian & Simon, Given input from folks so far, I think it would be better if both Curve25519 and Curve448 continued to use the "mpint" format for K when gene= rating a hash even though this is not what RFC7748 suggests. Would it make sense to include the following text to the end of section 2.1 of https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04 ? When performing the X25519 or X448 operations, the integer values there will be encoded into byte strings by doing a fix-length unsigned litle-endian conversion, per [RFC7748]. It is only later when these byte strings are then passed to the ECDH code in SSH that the bytes are re-interpreted as a fixed-length unsigned big-endian integer value K, and then later that K value is encoded as a variable-length signed "mpint" before being fed to the hash algorithm used for key generation. to help clarify the differences between RFC7748 and what is happening in SS= H? Much of this text is borrowed from what Ron Frederick has written to me, an= y remaining confusion is my fault. I think that the above text should help clear up the confusion that Eric no= ted in this section of code. If there are no problems with this text, I will release the -05 draft with = it. Thank you, -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu May 11 23:38:03 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7691294C4 for ; Thu, 11 May 2017 23:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.29 X-Spam-Level: X-Spam-Status: No, score=-3.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=stbuehler.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ptADv_cLDOX for ; Thu, 11 May 2017 23:38:02 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBEBA12EAB8 for ; Thu, 11 May 2017 23:33:36 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id B0F8185595; Fri, 12 May 2017 06:33:35 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 66E5C85589; Fri, 12 May 2017 06:33:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 74CFD84CF0 for ; Thu, 11 May 2017 13:15:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=stbuehler.de Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id 2qflE7Nueu7I for ; Thu, 11 May 2017 13:15:42 +0000 (UTC) Received: from mail.stbuehler.de (stbuehler.de [IPv6:2a01:4f8:a0:2276::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 7482484CEE for ; Thu, 11 May 2017 13:15:42 +0000 (UTC) Received: from [IPv6:2001:7c0:2049:1d4:14b7:34a8:44f4:149e] (unknown [IPv6:2001:7c0:2049:1d4:14b7:34a8:44f4:149e]) by mail.stbuehler.de (Postfix) with ESMTPSA id 24CBDB80135; Thu, 11 May 2017 13:15:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=stbuehler.de; s=stbuehler1; t=1494508532; bh=pV8vDy1x/7V/upmia59nR6e2khWUxXG9C5wAmE7kQLw=; h=Subject:References:From:To:Cc:Date:In-Reply-To:From; b=eFBnPchq59deaL06NLrDr35TjvbzKxjTxULaiQjZggxWDgPvS3VlOEON6T4Ar3UuY xf12X1vQGlgtcuuIsNkId/uLxoumwuxWwRr2Du+uQjoP+M8lvPiW5dv8QpZmt9kiIO bcLJxk5oU/nomgTob9Se5y81PCgPBc/+m4navYDE= Subject: Re: [Curdle] ssh-ed25519 implementations References: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> From: =?UTF-8?Q?Stefan_B=c3=bchler?= To: "curdle@ietf.org" Cc: "ietf-ssh@NetBSD.org" Message-ID: <76604306-d93a-5156-2350-636d3bda2323@stbuehler.de> Date: Thu, 11 May 2017 15:15:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list List-Unsubscribe: Hi, On 05/10/2017 06:18 PM, Mark Baushke wrote: > Hi, > > Eric Rescorla has brought to my attention that in > https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04 it is > currently specifying the SSH encoding of secrets on the wire using the > mpint process as described in section 5 of [RFC4251] while RFC 7748 > describes using a little-endian format: > > GF(2^448 - 2^224 - 1) and are encoded as an array of bytes, u, > in little-endian order such that u[0] + 256*u[1] + 256^2*u[2] + ... + > > This seems to be what is being implemeneted for > curve25519-sha256@libssh.org, so I should make > an explicit note of this in the draft. While we are on the topic of converting the shared secret bytes X generated by Curve* to an mpint, I'd like to point out that the draft-ietf-curdle-ssh-curves-04 is not clear regarding leading zeroes: > If X has leading zero bytes, the mpint format requires such bytes > to be skipped. In this case, the length of the encoded K will be > smaller. If X has one leading zero byte, and the highest bit of the second byte is set, K will be exactly X, not shorter. Maybe it would be better to describe an algorithm for the conversion, like: - trim all leading zero bytes - at least one byte must remain ("Clients and servers MUST fail the key exchange if [...], or if the derived shared secret only consists of zero bits.") - if the highest bit of the first byte of the remaining string is set, prepend one zero byte Or as pseudo code: k := x; while (k.length() > 0 && k[0] == 0) k = k[1:]; assert(k.length() > 0); if 0 != (k[0] & 0x80) k = '\0' .. k; cheers, Stefan From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu May 11 23:39:02 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 630D7129C06 for ; Thu, 11 May 2017 23:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=timeheart.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sbi9gca5kIqd for ; Thu, 11 May 2017 23:38:58 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B943B12EB1E for ; Thu, 11 May 2017 23:34:26 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 417998559E; Fri, 12 May 2017 06:34:26 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id D61F88559D; Fri, 12 May 2017 06:34:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 5C09484D9A for ; Fri, 12 May 2017 02:27:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=timeheart.net Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.netbsd.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id zzOGLpc4UpnN for ; Fri, 12 May 2017 02:27:34 +0000 (UTC) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id A30BB84DD0 for ; Fri, 12 May 2017 02:27:33 +0000 (UTC) Received: by mail-pf0-x22e.google.com with SMTP id n23so17721575pfb.2 for ; Thu, 11 May 2017 19:27:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timeheart.net; s=mail; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ptbK9m7gtynEgdKDlQy+PclvKEzbeRRAQ42uJINpoTU=; b=LBhnnzFTaOw9dVA8R9z0TxkEwhk4gEZAO5/HE7wPY5yYfQz0R0XafBg2JZpoYHiBjG 7MjWFFUfXLfdoQDry4qprgvAwZyYb0A9220SWlNpGQWudgehnhnbKoI2Z9JjQyJpPQH3 uxKKgx4Rr3MyQojvbm1EhO/JsdJUHnVbznKXU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ptbK9m7gtynEgdKDlQy+PclvKEzbeRRAQ42uJINpoTU=; b=UUv7/JuThFojMUfL1AZRRlbWjx454DA7mhknb55qXjHti/wcliVbpR3G/1HyAjGF8s XjexeZ4wzGJPq97fB7aKNlFuRoSIiDl8tWQjwRroVLyxo/FWmSlEWkQKQskK6IhxJddh rR6F2DvDw6C3f7WJRM1r1IvE2LAvMviCECG0X3NWx6pumtbj83MkZoIFP/46wepP4f9z aBbaD+ClytmxU2/u4al0OshKyjkYxZUhg7NUQPhLhi46s9j5ny+TJqBCEcEeDceSuxpS zKj8hwyLKnfEQkjZXQR2tbxfP1//MHOKU6MAHvDKdGE0V+PqJglMbE5cmtldBA+XJQCn 9LEA== X-Gm-Message-State: AODbwcCr8/HzerLiF8hXGokZ793YP039tpJgiLYENGjnvIuTk+g/Gb+w +B5+z8OtYP/8zWA2pA780A== X-Received: by 10.99.178.11 with SMTP id x11mr1863019pge.68.1494556053230; Thu, 11 May 2017 19:27:33 -0700 (PDT) Received: from ?IPv6:2601:647:4282:2200:cfa:5497:d692:7eeb? ([2601:647:4282:2200:cfa:5497:d692:7eeb]) by smtp.gmail.com with ESMTPSA id w23sm2155910pfl.133.2017.05.11.19.27.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 May 2017 19:27:32 -0700 (PDT) From: Ron Frederick Message-Id: <6047C877-67DE-404F-8FBD-5B2C19D16EA6@timeheart.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_0C05DEBB-4A4A-4E87-B290-B93427D3E747" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: ssh-ed25519 implementations Date: Thu, 11 May 2017 19:27:30 -0700 In-Reply-To: <36528.1494509552@eng-mail01.juniper.net> Cc: Eric Rescorla , Brian Smith , denis bider , Simon Tatham , "ietf-ssh@NetBSD.org" , "curdle@ietf.org" To: "Mark D. Baushke" References: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> <36528.1494509552@eng-mail01.juniper.net> X-Mailer: Apple Mail (2.3273) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list List-Unsubscribe: --Apple-Mail=_0C05DEBB-4A4A-4E87-B290-B93427D3E747 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Mark, On May 11, 2017, at 6:32 AM, Mark D. Baushke wrote: > Hi Eric & Ron & Brian & Simon, >=20 > Given input from folks so far, I think it would be better if both > Curve25519 and Curve448 continued to use the "mpint" format for K when > generating a hash even though this is not what RFC7748 suggests. >=20 > Would it make sense to include the following text to the end of = section > 2.1 of https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04 ? >=20 > When performing the X25519 or X448 operations, the integer values > there will be encoded into byte strings by doing a fix-length > unsigned litle-endian conversion, per [RFC7748]. It is only later > when these byte strings are then passed to the ECDH code in SSH = that > the bytes are re-interpreted as a fixed-length unsigned big-endian > integer value K, and then later that K value is encoded as a > variable-length signed "mpint" before being fed to the hash > algorithm used for key generation. >=20 > to help clarify the differences between RFC7748 and what is happening = in > SSH? >=20 > Much of this text is borrowed from what Ron Frederick has written to = me, > any remaining confusion is my fault. >=20 > I think that the above text should help clear up the confusion that = Eric > noted in this section of code. >=20 > If there are no problems with this text, I will release the -05 draft > with it. I just took a look at the updated draft. Here=E2=80=99s a copy of the = text in section 2.1 and some inline suggestions: 2.1 = .= Shared Secret Encoding The following step differs from [RFC5656 = ], which uses a different conversion. This is not intended to modify that text generally, but only to be applicable to the scope of the mechanism described in this document. The shared secret, K, is defined in [RFC4253 = ] as a multiple precision integer (mpint). Curve25519/448 outputs a binary string X, which is [Ron] RFC 4253 actually says that K is =E2=80=9Cencoded as an mpint=E2=80=9D= . I=E2=80=99d suggest saying =E2=80=9CThe shared secret, K, is defined = in [RFC4253] as an integer." the 32 or 56 byte point obtained by scalar multiplication of the other side's public key and the local private key scalar. The 32 or 56 bytes of X are converted into K by interpreting the bytes as an unsigned fixed-length integer encoded in network byte order. This conversion follows the normal "mpint" process as described in section = 5 of [RFC4251] . [Ron] There are actually two conversions here, from the byte string X to = the integer K, and then from K back to a byte string to be fed to the = hash used for key generation. This text makes it sound like the = conversion from X to K should follow the =E2=80=9Cmpint=E2=80=9D = conversion, but that=E2=80=99s not the case. The sentence about how to = convert X into the integer K looks good, but I would drop the last = sentence here and begin a new paragraph which discusses the second = conversion from the integer K back to a byte string for insertion into = the hash, such as: The integer K is then fed along with other data to the key exchange = method=E2=80=99s hash function to generate encryption keys. During this = process, [RFC4253] specifies that K should be encoded as an =E2=80=9Cmpint= =E2=80=9D as described in section 5 of [RFC4251]. This conversion may = result in a value which varies from the fixed-length byte string X as = follows: This new paragraph can replace the next paragraph below. To clarify a corner-case in this conversion, when X is encoded as an mpint K, in order to calculate the exchange hash, it may vary as follows: o Trim all leading zero-bytes of X. If X is all zero-bytes, then the key exchange MUST fail. [Ron] Are you sure this is necessary? I don=E2=80=99t see any mention of = this restriction in RFC 4253. If the integer value of K is 0, it can = still be encoded as a valid mpInt. o If the high bit of X is set, the mpint format requires a zero byte to be prepended. o The length of the encoded K may not be the same as the original length of X due to trimming or prepending zero-bytes as needed for "mpint" format. [Ron] Actually, after doing all of this, the mpint conversion also = requires the that resulting byte string be preceded by a 4-byte = big-endian length value. So, even if the X value has no bytes removed or = prepended, it will be 4 bytes longer than it was originally. There=E2=80=99= s no mention of this length here. Or, as pseudo code: k :=3D x; while (k.length() > 0 && k[0] =3D=3D 0) k =3D k[1:]; assert(k.length() > 0); if 0 !=3D (k[0] & 0x80) k =3D '\0' .. k; Figure 1 When performing the X25519 or X448 operations, the integer values there will be encoded into byte strings by doing a fix-length unsigned litle-endian conversion, per [RFC7748 = ]. It is only later when these byte strings are then passed to the ECDH code in SSH that the bytes are re-interpreted as a fixed-length unsigned big-endian integer value K, and then later that K value is encoded as a variable-length signed "mpint" before being fed to the hash algorithm used for key generation. [Ron] With the changes I have proposed above, I=E2=80=99m not sure this = last paragraph is needed. Alternately, I=E2=80=99d think about working = some of this text into the two paragraphs above that discuss the = conversion from X to K and then from K to an mpint. Also, = =E2=80=9Cfix-length=E2=80=9D here should be =E2=80=9Cfixed-length=E2=80=9D= . I think it is better to cover this point before diving into the = details of how the =E2=80=9Cmpint=E2=80=9D conversion is different from = the original X byte string. --=20 Ron Frederick ronf@timeheart.net --Apple-Mail=_0C05DEBB-4A4A-4E87-B290-B93427D3E747 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Mark,

On= May 11, 2017, at 6:32 AM, Mark D. Baushke <mdb@juniper.net> = wrote:
Hi Eric & Ron & Brian & Simon,

Given input from folks so far, I think it would be better if = both
Curve25519 and Curve448 continued to use the "mpint" = format for K when
generating a hash even though this is = not what RFC7748 suggests.

Would it make = sense to include the following text to the end of section
2.1 of https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04= ?

   When performing the = X25519 or X448 operations, the integer values
=    there will be encoded into byte strings by doing a = fix-length
   unsigned litle-endian = conversion, per [RFC7748]. It is only later
=    when these byte strings are then passed to the ECDH = code in SSH that
   the bytes are = re-interpreted as a fixed-length unsigned big-endian
=    integer value K, and then later that K value is = encoded as a
   variable-length signed = "mpint" before being fed to the hash
=    algorithm used for key generation.

to help clarify the differences between RFC7748 and what is = happening in
SSH?

Much of = this text is borrowed from what Ron Frederick has written to me,
any remaining confusion is my fault.

I think that the above text should help clear up the = confusion that Eric
noted in this section of code.

If there are no problems with this text, I = will release the -05 draft
with it.

I just took a look at the updated draft. Here=E2=80=99s = a copy of the text in section 2.1 and some inline suggestions:

2.1.  Shared =
Secret Encoding


   The following step differs from [RFC5656], which uses a different
   conversion.  This is not intended to modify that text generally, but
   only to be applicable to the scope of the mechanism described in this
   document.

   The shared secret, K, is defined in [RFC4253] as a =
multiple precision
   integer (mpint).  Curve25519/448 outputs a binary string X, which is

[Ron] RFC =
4253 actually says that K is =E2=80=9Cencoded as an mpint=E2=80=9D=
. I=E2=80=99d suggest saying =E2=80=9CThe shared secret, K, is =
defined in [RFC4253] as an integer."

   the 32 or 56 byte point =
obtained by scalar multiplication of the
   other side's public key and the local private key scalar.  The 32 or
   56 bytes of X are converted into K by interpreting the bytes as an
   unsigned fixed-length integer encoded in network byte order.  This
   conversion follows the normal "mpint" process as described in section
   5 =
of [RFC4251].

[Ron] There =
are actually two conversions here, from the byte string X to the integer =
K, and then from K back to a byte string to be fed to the hash used =
for key generation. This text makes it sound like the conversion =
from X to K should follow the =E2=80=9Cmpint=E2=80=9D conversion, =
but that=E2=80=99s not the case. The sentence about how to convert X =
into the integer K looks good, but I would drop the last sentence here =
and begin a new paragraph which discusses the second conversion from =
the integer K back to a byte string for insertion into the hash, =
such as:

The integer K is then fed along with other data to the key =
exchange method=E2=80=99s hash function to generate encryption keys. =
During this process, [RFC4253] specifies that K should be encoded as =
an =E2=80=9Cmpint=E2=80=9D as described in section 5 of [RFC4251]. =
This conversion may result in a value which =
varies from the fixed-length byte string X as =
follows:

This new =
paragraph can replace the next paragraph =
below.

   To =
clarify a corner-case in this conversion, when X is encoded as =
an
   mpint K, in order to calculate the exchange =
hash, it may vary as
   follows:


   o  Trim all leading zero-bytes of X.  If X is =
all zero-bytes, then
      the key exchange MUST fail.

[Ron] Are you =
sure this is necessary? I don=E2=80=99t see any mention of this =
restriction in RFC 4253. If the integer value of K is 0, it can =
still be encoded as a valid mpInt.

   o  If the high bit of X is set, the mpint format requires a zero byte
      to be prepended.

   o  The length of the encoded K may not be the same as the original
      length of X due to trimming or prepending zero-bytes as needed for
      "mpint" format.

[Ron] =
Actually, after doing all of this, the mpint conversion also requires =
the that resulting byte string be preceded by a 4-byte big-endian =
length value. So, even if the X value has no bytes removed or prepended, =
it will be 4 bytes longer than it was originally. There=E2=80=99s no =
mention of this length here.

   Or, as pseudo =
code:
                 k :=3D x;
                 while (k.length() > 0 && k[0] =3D=3D 0) k =3D =
k[1:];
                 assert(k.length() > 0);
                 if 0 !=3D (k[0] & 0x80) k =3D '\0' .. k;

                                 Figure 1

   When performing the X25519 or X448 operations, the integer values
   there will be encoded into byte strings by doing a fix-length
   unsigned litle-endian conversion, per [RFC7748].  It is only later
   when these byte strings are then passed to the ECDH code in SSH that
   the bytes are re-interpreted as a fixed-length unsigned big-endian
   integer value K, and then later that K value is encoded as a
   variable-length signed "mpint" before being fed to the hash algorithm
   used for key generation.

[Ron] With the changes I have proposed above, I=E2=80=99m not = sure this last paragraph is needed. Alternately, I=E2=80=99d think about = working some of this text into the two paragraphs above that discuss the = conversion from X to K and then from K to an mpint. Also, = =E2=80=9Cfix-length=E2=80=9D here should be =E2=80=9Cfixed-length=E2=80=9D= . I think it is better to cover this point before diving into the = details of how the =E2=80=9Cmpint=E2=80=9D conversion is different from = the original X byte string.
-- 
Ron Frederick
ronf@timeheart.net



= --Apple-Mail=_0C05DEBB-4A4A-4E87-B290-B93427D3E747-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu May 11 23:39:26 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958C8128B37 for ; Thu, 11 May 2017 23:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqkVL8wsZWyY for ; Thu, 11 May 2017 23:39:23 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 717A4129ADC for ; Thu, 11 May 2017 23:34:45 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id DCBC28559D; Fri, 12 May 2017 06:34:44 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 45B2E85599; Fri, 12 May 2017 06:34:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 8A2E785582 for ; Fri, 12 May 2017 05:22:02 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id o1gAdyOdfk7O for ; Fri, 12 May 2017 05:22:01 +0000 (UTC) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on070f.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe49::70f]) by mail.netbsd.org (Postfix) with ESMTP id 3A83084CEA for ; Fri, 12 May 2017 05:21:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4Zd9k3TB7C7WvaXcK/faS1/NRdHk3tVXzINyY/n+zYM=; b=ituqSBQNsTQ+trCRgHYq3qlg6RLaXs/cxj4OpiBUuOuQeG/mXK6GWwe5nwE6IGwA27bxkkUYabqWqma1IhGdB0uzeqq2bNedhP744OPh9HoFgqPbmJJgTWEJJ/UfRmw2wWFJMVh+U808ZcOv3MODlfYJayv8U97jhAb0xPgHclo= Received: from BY2PR05CA033.namprd05.prod.outlook.com (10.141.250.23) by BN1PR05MB261.namprd05.prod.outlook.com (10.141.65.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Fri, 12 May 2017 05:21:55 +0000 Received: from BY2NAM05FT043.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::206) by BY2PR05CA033.outlook.office365.com (2a01:111:e400:2c5f::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7 via Frontend Transport; Fri, 12 May 2017 05:21:54 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by BY2NAM05FT043.mail.protection.outlook.com (10.152.100.180) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1075.12 via Frontend Transport; Fri, 12 May 2017 05:21:54 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 11 May 2017 22:21:53 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v4C5LqKj019830; Thu, 11 May 2017 22:21:52 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 5FFD611446; Thu, 11 May 2017 22:21:52 -0700 (PDT) To: Ron Frederick CC: Eric Rescorla , Brian Smith , "denis bider" , Simon Tatham , "ietf-ssh@NetBSD.org" , "curdle@ietf.org" Subject: Re: ssh-ed25519 implementations In-Reply-To: <6047C877-67DE-404F-8FBD-5B2C19D16EA6@timeheart.net> References: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> <36528.1494509552@eng-mail01.juniper.net> <6047C877-67DE-404F-8FBD-5B2C19D16EA6@timeheart.net> Comments: In-reply-to: Ron Frederick message dated "Thu, 11 May 2017 19:27:30 -0700." From: "Mark D. Baushke" MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 May 2017 22:21:52 -0700 Message-ID: <1139.1494566512@eng-mail01.juniper.net> X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12;IPV:NLI;CTRY:US;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(39850400002)(39450400003)(39410400002)(39840400002)(39860400002)(39400400002)(2980300002)(199003)(377424004)(189002)(24454002)(377454003)(9170700003)(50986999)(54356999)(2906002)(76176999)(8656002)(76506005)(53416004)(7696004)(2950100002)(6916009)(2810700001)(23676002)(229853002)(7846003)(6392003)(55016002)(478600001)(7126002)(6306002)(54906002)(93886004)(6246003)(6266002)(117636001)(53936002)(5660300001)(106466001)(305945005)(105596002)(4326008)(39060400002)(189998001)(47776003)(38730400002)(356003)(77096006)(110136004)(50466002)(86362001)(8936002)(81166006)(8746002)(8676002)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BN1PR05MB261;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;MLV:ovrnspm;A:1;MX:1;PTR:InfoDomainNonexistent;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BY2NAM05FT043;1:KNsIhHSwKUiMDOxcZ+8ZBolPUrmxSQPq/wpdCIQtbk71p5fV3jcGzFfRds+NoTo6jwMDtx/jSpxpOOIkZbqE4t1tViduXqUTKz29GEq4VljdlSbDlqjP5qKU3QUiA9X0Ynuv/mTivVo+YBpP25IxDArf5Y2+ISLR7TUH7SeQx34aMsPE/jCzrqJkNjOH/ydnMenLWzsaOdOMDBgdV9qAizb54hDKL0bJ8/jUMCOHNI95L8lsYnQQJHqvk/QZ1YD7ZK/rT7Pb9dKFFNvodQ6e83YyIQYcqbvRXN2usDc+0GpohDGu1/BubBms9PjnL+UXdQV4DUfOvaDXGv922OwkGqZFHr6IRS/cq10ruLQDy60TVME+9rdCJiFJo5YUgOCwogvjn3l8AWvW0XbXCfQ3qFoVEf/CSFwqLrBoZoyjn/MwsF/wcFeyCvyBa5oz1nQ90KSNtqRwfAt3Br2BPo+EsdEIXxG0nKCoAU8/QN+EQ8wPNVWrkrE4QhR7PCDbXgl/5o6jX7d6vKZHP3eFS5M9Kd/Zfzakz4O+lcdIahpqkzp2Ujm5xLlvdTMpVy7suaNpDePKlcmUVzi9ZHMLXNCiPNmKD+uimo3rptfAZxNWDNiBUWWawOxIQcEq2S4Y8Fbi X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8ff02e0a-9786-4eb8-eb0a-08d498f6cd85 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075);SRVR:BN1PR05MB261; X-Microsoft-Exchange-Diagnostics: 1;BN1PR05MB261;3:trmMcwRI2Y4YfvZ0h5gqWPHE2Oj2rT1l/khXk2lDpy8khhYwHpGngzXDyrEwXO7BLwLvsxRDOL9aJ7t8Rrc2NMSTym/Y0r+HoWUvu6SENeV26euiyz9rEbkUvtYHcuuciEm8/2uYtPKZSNz1QdCvr0aKfMEm7WaOv9jHmbZaQsC4bqd7vmG7kwNmfr7LqsftSfzSVLyE5W6YDTxMVKVIHdF9qEYCER8W12Y+8IKbqqjVxbdsWr8E3dGOxQ7z1ILzdES5vV8qbWmTJMfeO9KovFsrf/Qd1naGA6FhDWegPJ05zPfg6ySEghc8go2GdnK0/kYdJR7UVInbxS3MDcZNmRjcbcybPV+Ngu7cWJvGAEn4UKHzNYVwRINzC86Jn7a2FKQNGw+xpZ3XKul6oqMlLZsg68MNNjppLkXdUvmZVipGrdyfB4tlGmqw6dgqq5iFRhFjcHSqc6PBl7DDprjv0d0g15nLYkZVVUujz2q05XayS6MskgcPRbWXpj716bKP X-Microsoft-Exchange-Diagnostics: 1;BN1PR05MB261;25:tUAKRghI84m1xhFeiApbcgwWrogI0g1hi0AO4P2ou+RnW5un1HMMg6Tmm/0c+sxEfKHz3pPwe5lAh6Oa3UyoQstXNGsWmautg1SnJIE1M/wtcMk6mZbo6V9HPmjMMJPsfleDl5YZkTTbna7wfkv2QszjNArZtLbmnYkHw4j03YrPP9kiDWMny6/zMPggBwVJIP8JS22jvOlp6E5EqhDU06wrgJher0CgVKsMOrddurzoZHel5/t2vDW2Tv5pOY86AmBWOBCZkXNrCnoY9ki340QtNwJX6vl0n3Q3B/vJ5Rh1GydGqCE8q8+jHXxbxeCRSzzU4zEr1QL63Tr8DEKKgC5Nlf59nJmiN6OmaINIZvaXhmN1ll+zE+lbyYUlwcHJ0sEbI3QYQlONr9j1F+xCs0rKIAKc8Kovcxb+KKqCloq8QfzOQj72lXxA0uMUmwBAg9bCoJxaDs8PxD6V85se4Cg2LqivYqUQ5dn30VrfxP4=;31:0VPEs0kfAtbNcPZ6+mGVyUoidIebGvgj2BOChq6tKfxprjzajIiRi5WHCW380pQr4YqTeQsg48Dk3YrRuHfUJPlHiPON/j4Cdado3skSX7Dbt1YJe3IjX4sZGgJhcXgwRACvVvJKlVhGYZH1wzfrlGSlmd8BEYgSRncU8eFYO4SBUZpSVlNJtSpRf6QQqlQLrLhmAIpijqo74ccYaCUAHV1OjCBat0b64Qwb3a1l3DrA3rbnIZrUS7+qo1FWIzBDPK0J0iQ2Qtu3Xdpveullkg== X-Microsoft-Exchange-Diagnostics: 1;BN1PR05MB261;20:eBrenFTY+5t0m4dJQjM8vy8qVpKo8Tpr3jFaEgxRSwyZWnyaBP3Vh059FhoXZ5f6z/C9xtvW0h+rGChQ+V9nAbkT4cCl3H768RGuBo+DmT7ABySPOYQZNcGwMM/4WDWzZgLsdmHXFhFTQdBO1ta/53AuZQ2ENR16pG5SvyJZF/HEDwQIsAyGDlyAMRwiSeoTUrKKu4by36dgCAvC90OEQIuApHdEpvXjVaUD9YE7PHNSu5qS/7WYZbRMbwsHuoM1kYunMoQfU6PsK3Fom3i0Q9i3JQ7DWe5p0P2u52M1XxC+gfl9jc/wixaq/PJ3nLtJ4zloeDbeisipPrWKv6vEc5UMJRUAqB1vDQX69CrRkqdqj9gdJrV8J2lJB5Mu393wLD7GARot7m0XdqYc1CEX8WtbL/CbfZWa6dykqvIX06BCmXhsxWlMw2zOtuzPSPxN9T02vqMfknWZqLnxDl31MdFzqEW+R174kbXpfEZCv/vG2YKrHmf0EPjelRubSD9q X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(788757137089); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040450)(601004)(2401047)(13024025)(8121501046)(13023025)(13018025)(5005006)(13017025)(13015025)(3002001)(93006095)(93003095)(10201501046)(6055026)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123564025)(20161123562025)(6072148);SRVR:BN1PR05MB261;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB261; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjFQUjA1TUIyNjE7NDovbGVreTVsV3JpZ0lacWtXSHV3WWJaMUFENkQr?= =?utf-8?B?QUxkdmIxOUFMcUpZQjFtSjlBS1hkQVdpd0pjbHkvSkNiOUd1WkdhdllSTzBq?= =?utf-8?B?N3ArUFByVWhPZEhuOGp5YW9uTHZYbERTSFdTZ2U2RUdPWkVSR0JENjg2b2h2?= =?utf-8?B?a2hIaHJXalFHOWRERFk2TE1EeS9EV2xOd244bkhuTWl2NzJkM3VzdE5PM1NS?= =?utf-8?B?L2Q5ekQwcnNIOFhjNVA4WkltOHpJWHowNmRYWVpXSldFV1JVb29WMkx4ZEta?= =?utf-8?B?d3p4c3FYWlkzSVZBa1NCbFMybHlLbWNsOFovbVA2d0pjaVVBSGExVDNreVlX?= =?utf-8?B?aXRWT3pwMWlIcDdLQ09renBjS0NWQytieFZrYzN0OU5CWUtsR0VRV2JVdWVP?= =?utf-8?B?NExyMXdaSThYbjNuRGYzeitXM3Z3U29LVlE0MXEvbjhoVFVNSFFzam5kK3BG?= =?utf-8?B?MXhTTXhiMWlxMEtqR2M3ZXhtMEl5UVNqWVJyblhsQkdhRmVMbk5SZ2J2Y08z?= =?utf-8?B?UDFtc1R5ODhDUFhCNFo2dSs1LzdvVlpsNUVOcTRGU0Q3STlsYUxmS1dXaTlR?= =?utf-8?B?aWdYc3lpVUc0UTlwWmY4YUlQdm1GRFlvSldqekxwTzVMa3NXZFZRQ1pMMFQ5?= =?utf-8?B?T2FuSWFHRE9jZ2lFcnhrN3Jldmh3SDFRMllUNVJScjc4OHpYVFlyM3NSWFl5?= =?utf-8?B?ZVN4NWEzYVVoaWtFdGVMSzk5ZkZ5cFNIMk5Pb3g5STRwbUF4SWxPWlYrbm1U?= =?utf-8?B?TkFZbmV0Umh6TzBaYU8wWlRMR1VDWVdvNDNVRkVQclhNeW5TNktZWCt4bkZy?= =?utf-8?B?WU5PRWhZVUw2bnhSdjdCVGphOGJOUmU1VUUxZ01aVnZWSjg5VHFQTzVIQVJx?= =?utf-8?B?UjFaOU0yOWdvNkdhUFF1SldBZXlSZUY4N3JqeWtRYkxvY2h2aVJ5SjBmVTRz?= =?utf-8?B?c2pnbTdHWXBOWjlnTkladFN0WVc1MmU0SkxXWW1xN01aNjhyY0JFbEdQc0Zn?= =?utf-8?B?NXV6aFAwU0x5TmI4R2pQUVM4eHN1VTFJY1RDZDl0M25uM2VSTHdaZVErWU56?= =?utf-8?B?OXhuUWp2eWdUU3YwMkFJUkJra3Zqb3JOYktERkx5Z3NGM3liTkorOE84Ymgw?= =?utf-8?B?eW9uMWNFU0sva1FPcXFBNTFHeitSVTZkZnBmZ2NtVDV1azI2ZU0xMUdzMTAr?= =?utf-8?B?aTlobTNXd1R0aDZqdUxCdW52TWZQZkpheUtqWWdQQnZBS25WckZSMkh6YnFk?= =?utf-8?B?MHNDT0VqeEhxeS9HTVdrZkFMcS9vK21MVFRVZWk5YVJsaVVyck5DdStwZ2tl?= =?utf-8?B?c0VIZzFSeFF3PT0=?= X-Forefront-PRVS: 0305463112 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjFQUjA1TUIyNjE7MjM6bkNpMW00L2J6NEVTaldKZEVTR3ljYzI5RnJj?= =?utf-8?B?QXlEbXQyS3dONWZ0MmZIVFZ1aG5IMS9ZeUUyVUxLVnc5QlVCeFRKcVlSLy96?= =?utf-8?B?VTVyckRWenBrOHAva2N6YzJnV0ZLM2JjZWFSQkdyTm1sdkhxZ2NSaVNTMlBS?= =?utf-8?B?UmgzNmNFYjFUeVB0cGNPZmxKNXBib3B4amNHRTVqYVQ2Z3pBQm90emJNZm9E?= =?utf-8?B?djlaMFhod0VjMHo1QmdOdHhwamh5VnFPekc1TzFTS3VjdUIxeTRpMW1PbWhZ?= =?utf-8?B?YTZVMmxvQURoNVduTEQ2MGRVeTdGTEhuUk5SdDM1emtvVkRCLzJrZm5KQmdN?= =?utf-8?B?ZXpKclNLUy82cGVmdGlpMVliZ3ppdHhvTVNFQkU0ZmFGdDdzR1lVWkJuYmd5?= =?utf-8?B?bndQSGt6RFZHNkI4YnA3MFFNTi9oRHA0MFhHdlhuaVREcE8wZE91ZEthbUNN?= =?utf-8?B?eEl1ZHdWd2ltNGtWeUl0YVhFWEhYeGh3YVdHUzI1b1laRUROc0YxQlR1bXN0?= =?utf-8?B?S1l3aFNMUjdYcEtvMEZaYWk4Ry9wSTltaGNTd2Nwb3dUcklUUExCK05wdW0w?= =?utf-8?B?bWNJdXJkSHozSnh4bXBEdkhlTVFlWVpEa0dxSXpOUGNXYnFQeGpSMVpNbUFy?= =?utf-8?B?akkzSkEwNmhsTUszKzVpNHV2c0VwNzdYMU5tWU45LzQ1R3FhRkgyR0Q2SERP?= =?utf-8?B?UmpVd1p5NThCTjJUTHdtd2hZQkNGbllIZkZHNXpmZS8vYUZFUU8xQS91ZnJL?= =?utf-8?B?eXhjc0tnOVlJRCtmVkR6dmlwVVRxRVlQVnJJck1Wb0VkWHVINVhRUGZ3cjF3?= =?utf-8?B?N3pUa0p6NHlFc1RMazNLZlhUWUxiTlBrY2p2cGw1N1JMSEFUYkdGRm93SXVS?= =?utf-8?B?KzdDRWk0ZjNwSFJaWklwRHdseGh2Nzc2Sk1peXp0Yi9SZHhMUnErYUdMNUsv?= =?utf-8?B?WXg1VUhVNnRLYWpvcmdmWVhtNGJkdUpCUzRiZXVoUkJBY2xxZUVrVXBtQTdW?= =?utf-8?B?RUU3MnJkRHhkb0dnYzlaYUtFdW5kZmY5Y1gzU1pydzY3VkxkdnhZalNzSEdS?= =?utf-8?B?RGh1bDgycklCYVZyWU1weG9MclcrdkFGZkczQXEralpEb3pCY1U4dGZrREVK?= =?utf-8?B?MW5SOTZadU5aUHM1WDR4SHZxem1EeEIzU21jTUQ4aXE0MG5oek5BTTZDOEpn?= =?utf-8?B?QXhYYXVDU1MwN3FIMlcrM1JtNXlCWUF6bVdoR1JjUEp4RnY5Z1hnZVl2c2xU?= =?utf-8?B?TFlqN3NTcU5adGtsZkMrUWdFR3YzVHhIY1lqR0dTbnBKVjNnZHdzZ1l4SnZj?= =?utf-8?B?Vk1PM2lKY3hNVzBUajRUQ0xEZDNwdVdnRE5SejNwOG83eHpwSUZpZWNWTjc3?= =?utf-8?B?SS9iRUEyWGdtME04ZFczRllRdkdJSmNsZk1NOElGMVVpcm55VDRFai9vK1pm?= =?utf-8?B?SUkrQy8xR1VQVWNtYUt5RFpQQytVejViZ1lsdGRsczNRZG9VSlJKeEloaTZm?= =?utf-8?B?dEFxTUtTaktnaFFYd0pNQUhwVzJBNzRYODVXK2hYZ1RlaDlLdDNqbmlaNGNR?= =?utf-8?B?amowR2o0ZWxUSUl0T21qeXZXYUtkUmlwL1lkVHlHdU01OWZWUWZvVDUxajMy?= =?utf-8?B?WXBCNUtQcmx2cG5sNVpYUGovOGdwcEhLd1FOZHlRQTN6VWtNTlg3akZYMGd1?= =?utf-8?B?SHdDOEJWVkwwcVg1Q2hIRnVIN2RWL2NaMCtMdGMxSExJOFBaN09HYTlWVXNG?= =?utf-8?B?ckUrR0NZaUtBSTZYK0Fha0xFUXhYZXBleVE4WC85Qy9tUEhROE9PMXMrNzNo?= =?utf-8?B?MDNKWnBSRk9NK3ZuTDBlcE80YzF2bFgrOVl1TXJvbys3UVVDa0NJYU9rL3h5?= =?utf-8?Q?8tmFgsZqZZwuAZvsFrY2KhK9RisdSw9?= X-Microsoft-Exchange-Diagnostics: 1;BN1PR05MB261;6:Q/zZowRN4lwhPfU/7kAL/5TlFYmvJS/UobE29BEFnJSvzvB6SI1ZMeMvddGFq9VD1OcuhRk2DOB9hSLRLTzxKADUFqkepqYH5BVzaTpwMQyoyxd0byvk1uVq+js3C88AeO6dTax2TVXBqiRIhrYpEMx8akR9Xj5qiBSfwci+rVV3BJ+OCoQdXqNUoIWxqtoFlu2zAzqSXlwfKxoJgV1aMVF01Yhz1aBTtc6tYedFJaNMbE2akkyXX8u3v8DaYPXY/XkXftX/o80K7IGC13+KG7Lgcx27qMM+vbBBLdxHDu/II1ykS5XdkURXc81Ulci/1H2odpG7Rk+aCKC60l05ShcwtdVgSpAqVXtx7/AomBLsP0YB8U1DQf+/blFPFKJ5tJgV+a9KmhuxEENFp9hCA7mUPyaq8DT9MUzp04sPBky14tLsxwpOvZVUJunV4H5OoLy4p01MUc5kjyn/wxPpwFjeRHOL8+W6X9BsgrcSmliecnLGN7zuTuyGi155uJnzdkFdAhrpualyRrAZAr9QaFmK4uC/U06y56GkmHv6Ghg=;5:RbdNLjPLFPPpqrXP5yqWSYii+VgsOZroFglcWfJMB7BWAZecO1o/Y2byLkonsnI+1CTo9GRfs8iyfHa5jpnPPzLaDhDo7o0Yg+igdlgsqtgnOeiVBxWlS/LsRiGVtvPtRPkKPHopOIJ7eg5i7cE4+w==;24:H1niofDoP8YRVAxK9t136KPGQhPlK+pP7IEQaaZW4KpG9OxB9Pzp1k2pnlV4XldHh7uu9fDcYRaZyrdO4goK3KGh55C43n9SdOko0tR+KlM= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;BN1PR05MB261;7:TapZbingXwEE4fnH1TvlgVj8YutQXJgdbZUjMuUJDC6V5a093BC2krun6/TUtNtLWC0dtr/N2BpLq0hASFz4LuOyAe+c0uTEZPNMyNFy2WV3OBhx6F6ZeTvQOyt1TjOoeFlx1LldASqs5rR2JRB7A9uE5XYr8D2SfRhEjkGZX9/J695bk8TgcTL2SIBradimTZIXujUZlj3qlhsPaUB2x+70rpz9pGhEJNcHLzPBWVzqA/qm020N/N8WSU6sMvraeK0WK03Bv5epapoOASgFsP/yUqg6TnC2TrJGMOvtU569AkEZQIkCZW9Hv0nuT97N2f60zwwYheLq0eJNmWr1FA== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 May 2017 05:21:54.1143 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.12];Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB261 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list List-Unsubscribe: Hi Ron, Ron Frederick writes: > Hi Mark, >=20 > On May 11, 2017, at 6:32 AM, Mark D. Baushke wrote: >=20 > I just took a look at the updated draft. Here=E2=80=99s a copy of the tex= t in > section 2.1 and some inline suggestions: I am always interested in making the text better. > 2.1 Shared Secret Encoding >=20 > The following step differs from [RFC5656], which uses a different > conversion. This is not intended to modify that text generally, but > only to be applicable to the scope of the mechanism described in this > document. >=20 > The shared secret, K, is defined in [RFC4253] as a multiple precision > integer (mpint). Curve25519/448 outputs a binary string X, which is >=20 > [Ron] RFC 4253 actually says that K is =E2=80=9Cencoded as an mpint=E2=80= =9D. I=E2=80=99d > suggest saying =E2=80=9CThe shared secret, K, is defined in [RFC4253] as = an > integer." Section 8 of RFC 5253 actually says "It computes K =3D e^y mod p" which means that K is a multiple precision integer. As an aside, it really should end up be larger than a simple integer. Not stated, but the math works best if it is on the order of at least half the number of bits of q such that g^(xy) is greater than p which lets the mod operation do something useful. > the 32 or 56 byte point obtained by scalar multiplication of the > other side's public key and the local private key scalar. The 32 or > 56 bytes of X are converted into K by interpreting the bytes as an > unsigned fixed-length integer encoded in network byte order. This > conversion follows the normal "mpint" process as described in section > 5 of [RFC4251]. >=20 > [Ron] There are actually two conversions here, from the byte string X > to the integer K, and then from K back to a byte string to be fed to > the hash used for key generation. This text makes it sound like the > conversion from X to K should follow the =E2=80=9Cmpint=E2=80=9D conversi= on, but > that=E2=80=99s not the case.=20 True, that is confusing and should be fixed. > The sentence about how to convert X into the integer K looks good, but > I would drop the last sentence here and begin a new paragraph which > discusses the second conversion from the integer K back to a byte > string for insertion into the hash, such as: >=20 > The integer K is then fed along with other data to the key exchange > method=E2=80=99s hash function to generate encryption keys. During this > process, [RFC4253] specifies that K should be encoded as an =E2=80=9Cmp= int=E2=80=9D > as described in section 5 of [RFC4251]. This conversion may result > in a value which varies from the fixed-length byte string X as > follows: > This new paragraph can replace the next paragraph below. >=20 > To clarify a corner-case in this conversion, when X is encoded as an > mpint K, in order to calculate the exchange hash, it may vary as > follows: >=20 > o Trim all leading zero-bytes of X. If X is all zero-bytes, then > the key exchange MUST fail. >=20 > [Ron] Are you sure this is necessary?=20 Yes. > I don=E2=80=99t see any mention of this restriction in RFC 4253. If the > integer value of K is 0, it can still be encoded as a valid mpInt. It is not in RFC4253, it is in RFC4251 where it says: mpint Represents multiple precision integers in two's complement format, stored as a string, 8 bits per byte, MSB first. Negative numbers have the value 1 as the most significant bit of the first byte of the data partition. If the most significant bit would be set for a positive number, the number MUST be preceded by a zero byte. Unnecessary leading bytes with the value 0 or 255 MUST NOT be included. The value zero MUST be stored as a string with zero bytes of data. The check for X is all zero-bytes needs to be done per RFC7748: Both now share K =3D X25519(a, X25519(b, 9)) =3D X25519(b, X25519(a, 9)) as a shared secret. Both MAY check, without leaking extra information about the value of K, whether K is the all-zero value and abort if so (see below). ...elided... The check for the all-zero value results from the fact that the X25519 function produces that value if it operates on an input corresponding to a point with small order, where the order divides the cofactor of the curve (see Section 7). The check may be performed by ORing all the bytes together and checking whether the result is zero, as this eliminates standard side-channels in software implementations. I suppose that could be done first in linear time by oring all of the bytes without leaking side channel information... k :=3D x zbcheck :=3D 0 for byte in k: zbcheck |=3D k[byte]; assert(zbcheck > 0); while (k.length() > 0 && k[0] =3D=3D 0) k :=3D k[1:]; if 0 !=3D (k[0] & 0x80) k :=3D '\0' .. k;=20=20=20=20 which is kind of ugly... > o If the high bit of X is set, the mpint format requires a zero byte > to be prepended. >=20 > o The length of the encoded K may not be the same as the original > length of X due to trimming or prepending zero-bytes as needed for > "mpint" format. >=20 > [Ron] Actually, after doing all of this, the mpint conversion also > requires the that resulting byte string be preceded by a 4-byte > big-endian length value. So, even if the X value has no bytes removed > or prepended, it will be 4 bytes longer than it was originally. > There=E2=80=99s no mention of this length here. True, because the prepended length is not a part of the hash to the best of my recollection. Am I mistaken? > Or, as pseudo code: >=20 > k :=3D x; > while (k.length() > 0 && k[0] =3D=3D 0) k =3D k[1:]; > assert(k.length() > 0); > if 0 !=3D (k[0] & 0x80) k =3D '\0' .. k; Hmmm... should the above use :=3D for assignments everywhere like this? k :=3D x; while (k.length() > 0 && k[0] =3D=3D 0) k :=3D k[1:]; assert(k.length() > 0); if 0 !=3D (k[0] & 0x80) k :=3D '\0' .. k; >=20 > Figure 1 >=20 > When performing the X25519 or X448 operations, the integer values > there will be encoded into byte strings by doing a fix-length > unsigned litle-endian conversion, per [RFC7748 ]. It is only later > when these byte strings are then passed to the ECDH code in SSH that > the bytes are re-interpreted as a fixed-length unsigned big-endian > integer value K, and then later that K value is encoded as a > variable-length signed "mpint" before being fed to the hash algorithm > used for key generation. >=20 > [Ron] With the changes I have proposed above, I=E2=80=99m not sure this l= ast > paragraph is needed. Alternately, I=E2=80=99d think about working some of= this > text into the two paragraphs above that discuss the conversion from X > to K and then from K to an mpint.=20 I am also not sure, but I have left it in for now. Please see my 'diff' below for the changes to see if it looks better or worse to you. > Also, =E2=80=9Cfix-length=E2=80=9D here should be =E2=80=9Cfixed-length= =E2=80=9D. Sure, I can make that change. > I think it is better to cover this point before diving into the > details of how the =E2=80=9Cmpint=E2=80=9D conversion is different from t= he original X > byte string. Hmmm.... here is how I have updated the text: --- draft-ietf-curdle-ssh-curves-05.xml 2017-05-11 11:58:15.000000000 -0700 +++ draft-ietf-curdle-ssh-curves-06.xml 2017-05-11 22:18:37.000000000 -0700 @@ -169,8 +169,15 @@ key and the local private key scalar. The 32 or 56 bytes of X are converted into K by interpreting the bytes as an unsigned fixed-length integer encoded in network byte order. + + + + The integer K is then fed along with other data to the key + exchange method's hash function to generate encryption keys. This conversion follows the normal "mpint" process as - described in section 5 of . + described in section 5 of which + requires that unnecessary leading bytes with the value 0 + MUST NOT be included. =20 @@ -181,32 +188,36 @@ =20 - Trim all leading zero-bytes of X. If X is all - zero-bytes, then the key exchange MUST fail. + Trim all leading zero-bytes of X, as required in section + 5 of . If X is all + zero-bytes, then the key exchange MUST fail as required + in section 6 of . =20 - If the high bit of X is set, the mpint format requires a - zero byte to be prepended. + Given X is a positive, if the MSB of X is set, then + the "mpint" format requires a zero-byte to be prepended. =20 - The length of the encoded K may not be the same as the - original length of X due to trimming or prepending - zero-bytes as needed for "mpint" format. + The length of the "mpint" form of K may not be the same + as the original length of X due to trimming or + prepending zero-byte values as needed for "mpint" + format. =20 =20
- Or, as pseudo code: + Or, as pseudo code (without dealing with side-channel + issues): k :=3D x; - while (k.length() > 0 && k[0] =3D=3D 0) k =3D k[1:]; + while (k.length() > 0 && k[0] =3D=3D 0) k :=3D k[1:]; assert(k.length() > 0); - if 0 !=3D (k[0] & 0x80) k =3D '\0' .. k; + if 0 !=3D (k[0] & 0x80) k :=3D '\0' .. k;
@@ -214,7 +225,7 @@ When performing the X25519 or X448 operations, the integer values there will be encoded into byte strings by doing a - fix-length unsigned litle-endian conversion, per . It is only later when these byte strings are then passed to the ECDH code in SSH that the bytes are re-interpreted as a fixed-length unsigned big-endian integer From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri May 12 22:32:44 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80627129B77 for ; Fri, 12 May 2017 22:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=timeheart.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wscAcHUFVHVI for ; Fri, 12 May 2017 22:32:42 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 131BF129B34 for ; Fri, 12 May 2017 22:30:24 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id E694C84DF5; Sat, 13 May 2017 05:30:22 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 8C17884DCF; Sat, 13 May 2017 05:30:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 403DB84DCF for ; Sat, 13 May 2017 05:24:15 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=timeheart.net Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.netbsd.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id pwXFHDm7Pxra for ; Sat, 13 May 2017 05:24:14 +0000 (UTC) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 3062584CD8 for ; Sat, 13 May 2017 05:24:13 +0000 (UTC) Received: by mail-pf0-x230.google.com with SMTP id m17so39103145pfg.3 for ; Fri, 12 May 2017 22:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timeheart.net; s=mail; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cKN9oSPunz8b3EgvhWMDmgSWwDGv9uUxTewKPMi0DGg=; b=Ht5C//D6babAF7UPo9OkVU8JxmO8pKofZ8oeLhkwisw8DwP/ycKg1+9HrmJ/0+eMVp p4lO3y17fcM/UkNn33QxqqAQfcCOKr3jF/muZU/9ToTy74BIXiA+I1lf+pqGIfde5Zuj IwbpLb+H1XZsf8g0o8UzuvGnpQ1sZFfIOwKN0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cKN9oSPunz8b3EgvhWMDmgSWwDGv9uUxTewKPMi0DGg=; b=ODLnqGnUStDmJ1PUpZ+jijLPfiTlb6OYMsMSvFwCUoAvVERQzNNG4Ia1PEm1pQ+C2v No9Sg82ukMR4CeWegeXaEB74Y3OUIB06uxQMxmj+D9IG4pOGlR4DX6fxc9wX4WgAsd3j 8sJE15pmMdlpfLkGveiVI1Aql+G+Ip2MZ+/iZ1mIs1Yx92kN+pASt2o5Fl661uwFrV6r 7pBLYMOJTmwQz5c2gffDakAlLOmNeCRuyNynVFanl3qtKv0oUAmIm5La8iKeWN6aaSrn QKFGAlMu5IOOAUE9Dkd02eQDtD8a9ZUeqGcQo3cJ9028BiUqFRRL/eZ0Mj3pdmmrtp21 h0PQ== X-Gm-Message-State: AODbwcCgJOZiS5AuK4z4czd/jPyoQdZbIjrpsy6htro9fkfs4LJfH/f3 GtYvQDiVec8kZQ== X-Received: by 10.84.142.129 with SMTP id 1mr9474087plx.3.1494653052856; Fri, 12 May 2017 22:24:12 -0700 (PDT) Received: from ?IPv6:2601:647:4282:2200:cfa:5497:d692:7eeb? ([2601:647:4282:2200:cfa:5497:d692:7eeb]) by smtp.gmail.com with ESMTPSA id y63sm8909487pfa.107.2017.05.12.22.24.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 May 2017 22:24:11 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: ssh-ed25519 implementations From: Ron Frederick In-Reply-To: <1139.1494566512@eng-mail01.juniper.net> Date: Fri, 12 May 2017 22:24:09 -0700 Cc: Eric Rescorla , Brian Smith , denis bider , Simon Tatham , "ietf-ssh@NetBSD.org" , "curdle@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <336063E0-135F-4A75-94E4-71540669E21A@timeheart.net> References: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> <36528.1494509552@eng-mail01.juniper.net> <6047C877-67DE-404F-8FBD-5B2C19D16EA6@timeheart.net> <1139.1494566512@eng-mail01.juniper.net> To: "Mark D. Baushke" X-Mailer: Apple Mail (2.3273) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list List-Unsubscribe: Hi Mark, On May 11, 2017, at 10:21 PM, Mark D. Baushke wrote: > Ron Frederick writes: >> 2.1 Shared Secret Encoding >>=20 >> The following step differs from [RFC5656], which uses a different >> conversion. This is not intended to modify that text generally, = but >> only to be applicable to the scope of the mechanism described in = this >> document. >>=20 >> The shared secret, K, is defined in [RFC4253] as a multiple = precision >> integer (mpint). Curve25519/448 outputs a binary string X, which = is >>=20 >> [Ron] RFC 4253 actually says that K is =E2=80=9Cencoded as an = mpint=E2=80=9D. I=E2=80=99d >> suggest saying =E2=80=9CThe shared secret, K, is defined in [RFC4253] = as an >> integer." >=20 > Section 8 of RFC 5253 actually says "It computes K =3D e^y mod p" = which > means that K is a multiple precision integer. Section 8 is specific to the original Diffie Hellman key exchange. The = computation is different for ECDH (described in section 4 of RFC 5656), = but that states "The SSH framework requires that the shared key be an = integer.=E2=80=9D and then goes on to describe how to do the conversion = from an EC field element. For X25519, I think it makes sense to state = something similar. > As an aside, it really should end up be larger than a simple integer. > Not stated, but the math works best if it is on the order of at least > half the number of bits of q such that g^(xy) is greater than p which > lets the mod operation do something useful. I agree that in all of these cases the integer K is likely to be very = large (much larger than something which would fit in a traditional = integer value in a language like C). However, =E2=80=9Cmpint=E2=80=9D = here really is just an encoding. In Python, for example, K can be = represented as a plain Python =E2=80=9Cint=E2=80=9D type, since that = natively supports arbitrarily large integers (limited only by available = memory, I think). The =E2=80=9Cmpint=E2=80=9D conversion here actually = changes the type from an =E2=80=9Cint=E2=80=9D to a byte array, which is = needed to be able to feed the bytes to the hash function. Even in other = languages where large integers are represented as some form of an array = already, it=E2=80=99s important that the exact representation of this = integer as a byte array is specified, so that all parties compute the = hash in a consistent manner. >> o Trim all leading zero-bytes of X. If X is all zero-bytes, then >> the key exchange MUST fail. >>=20 >> [Ron] Are you sure this is necessary?=20 >=20 > Yes. >=20 >> I don=E2=80=99t see any mention of this restriction in RFC 4253. If = the >> integer value of K is 0, it can still be encoded as a valid mpInt. >=20 > It is not in RFC4253, it is in RFC4251 where it says: >=20 > mpint >=20 > Represents multiple precision integers in two's complement = format, > stored as a string, 8 bits per byte, MSB first. Negative numbers > have the value 1 as the most significant bit of the first byte of > the data partition. If the most significant bit would be set for > a positive number, the number MUST be preceded by a zero byte. > Unnecessary leading bytes with the value 0 or 255 MUST NOT be > included. The value zero MUST be stored as a string with zero > bytes of data. That does not say that 0 is an invalid value. It simply says that when = converting to an =E2=80=9Cmpint" byte array, 0 is represented by a = zero-byte array. > The check for X is all zero-bytes needs to be done per RFC7748: >=20 > Both now share K =3D X25519(a, X25519(b, 9)) =3D X25519(b, X25519(a, = 9)) > as a shared secret. Both MAY check, without leaking extra > information about the value of K, whether K is the all-zero value = and > abort if so (see below). > ...elided... > The check for the all-zero value results from the fact that the > X25519 function produces that value if it operates on an input > corresponding to a point with small order, where the order divides > the cofactor of the curve (see Section 7). The check may be > performed by ORing all the bytes together and checking whether the > result is zero, as this eliminates standard side-channels in = software > implementations. Ok. I still have some doubts about whether this belongs in this = specification, though, as it seems like the abort operation should be = performed by the code implementing the X25519 multiplication. Before = returning the byte array X, I would expect that code to check for an = all-zeroes result and return an error, so the code handling this value = in SSH would never even see the case where the converted value K ends up = being 0. As one data point, I checked the libsodium implementation, and it was = changed back in November of 2015 (release 1.0.7) to perform this check = and return an error if the result of the scalar multiplication ends up = being all-zeroes. I don=E2=80=99t see a specific test vector which I can = use to actually confirm that this works, though =E2=80=94 does anyone = happen to have one? >> [Ron] Actually, after doing all of this, the mpint conversion also >> requires the that resulting byte string be preceded by a 4-byte >> big-endian length value. So, even if the X value has no bytes removed >> or prepended, it will be 4 bytes longer than it was originally. >> There=E2=80=99s no mention of this length here. >=20 > True, because the prepended length is not a part of the hash to the = best > of my recollection. Am I mistaken? Yes - the fixed-size 4-byte length is always included as part of the = bytes fed to the hash. >> [Ron] With the changes I have proposed above, I=E2=80=99m not sure = this last >> paragraph is needed. Alternately, I=E2=80=99d think about working = some of this >> text into the two paragraphs above that discuss the conversion from X >> to K and then from K to an mpint.=20 >=20 > I am also not sure, but I have left it in for now. Please see my = 'diff' > below for the changes to see if it looks better or worse to you. This definitely looks better. It still needs additional text to cover = the insertion of the fixed length bytes in front of the encoded = =E2=80=9Cmpint=E2=80=9D value, though. --=20 Ron Frederick ronf@timeheart.net From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat May 13 07:53:25 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9511129AE9 for ; Sat, 13 May 2017 07:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQbs7Csd1c3G for ; Sat, 13 May 2017 07:53:19 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E7BE129B98 for ; Sat, 13 May 2017 07:51:21 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id B8A70855BD; Sat, 13 May 2017 14:51:18 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 1B5C084DE2 for ; Sat, 13 May 2017 14:51:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id T29s9i8mTRAX for ; Sat, 13 May 2017 14:51:12 +0000 (UTC) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe40::706]) by mail.netbsd.org (Postfix) with ESMTP id 15DC084CFB for ; Sat, 13 May 2017 14:51:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9Nt4s5OKzzwQ71fR8G+9+q2tRSH9P0ZPmcF3bBDgeAg=; b=I27Yhj5XxadSpJPzTBLY+ARRpsc+PvocwK4JvtCEgEIt7I5ayLdSI+urhiYfRLEKd9h3kH/9xmblRgtFJj5a39Fq/uKZ+1mCapY0pPzQxY9iG6J1yQDIsIqhJOZDu86flrG3Oa1hvpBcRQG/GOubJioUQcMpIPdmW8Wbaz1Y/4s= Received: from CO2PR05CA026.namprd05.prod.outlook.com (10.141.241.154) by BY1PR0501MB1303.namprd05.prod.outlook.com (10.160.200.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Sat, 13 May 2017 14:51:07 +0000 Received: from DM3NAM05FT063.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::201) by CO2PR05CA026.outlook.office365.com (2a01:111:e400:1429::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.5 via Frontend Transport; Sat, 13 May 2017 14:51:06 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by DM3NAM05FT063.mail.protection.outlook.com (10.152.98.182) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1075.12 via Frontend Transport; Sat, 13 May 2017 14:51:06 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 13 May 2017 07:51:05 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v4DEp3rP013222; Sat, 13 May 2017 07:51:03 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id CFEA51145A; Sat, 13 May 2017 07:51:02 -0700 (PDT) To: Ron Frederick CC: Eric Rescorla , Brian Smith , "denis bider" , Simon Tatham , "ietf-ssh@NetBSD.org" , "curdle@ietf.org" Subject: Re: ssh-ed25519 implementations In-Reply-To: <336063E0-135F-4A75-94E4-71540669E21A@timeheart.net> References: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> <36528.1494509552@eng-mail01.juniper.net> <6047C877-67DE-404F-8FBD-5B2C19D16EA6@timeheart.net> <1139.1494566512@eng-mail01.juniper.net> <336063E0-135F-4A75-94E4-71540669E21A@timeheart.net> Comments: In-reply-to: Ron Frederick message dated "Fri, 12 May 2017 22:24:09 -0700." From: "Mark D. Baushke" Date: Sat, 13 May 2017 07:51:02 -0700 Message-ID: <74670.1494687062@eng-mail01.juniper.net> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12;IPV:NLI;CTRY:US;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(39410400002)(39860400002)(39450400003)(39850400002)(39400400002)(39840400002)(2980300002)(377424004)(189002)(199003)(9170700003)(54906002)(86362001)(48376002)(39060400002)(8676002)(6266002)(5003940100001)(305945005)(106466001)(55016002)(76176999)(356003)(189998001)(7126002)(5660300001)(8656002)(81166006)(50466002)(76506005)(2810700001)(7846003)(50986999)(6392003)(53416004)(105596002)(4326008)(93886004)(2950100002)(6246003)(117636001)(54356999)(47776003)(77096006)(478600001)(6916009)(97736004)(110136004)(7696004)(2906002)(53936002)(38730400002)(229853002)(8936002)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BY1PR0501MB1303;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;MLV:ovrnspm;MX:1;A:1;PTR:InfoDomainNonexistent;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;DM3NAM05FT063;1:kK19z7hpP2CdR7cyrLI/gaS/Fqq1IBoedKLbbQJdgdu5VYSFMigv439MaKfuY8WL6HCVoN1FM7qXYoU9lTS5trwcXvrX8c3uqT21qoJC6a0NH7gGSsxtL2Xrx2lQDG5JDDy26k4syPpGdICEHzTDBfhMds7fnzyKiOsFx9pogR9KwbKFCfXLn+SyS6FIuO5/TeQdTrqwxmJLhCBmrxEOAqmO8euYgpXERSL24iiV01YZzNAGQgZx4bCyCkT8ukLkjUG8qdZvK6DvImx/V9C7Bs96ZFDPcTZtC9bJP1yLCzjl5qfECJFOi6yJCHCXA6WzkdIJwJB/1F/t1KF0CsBEs8Z1A/vfe/fZOWSw5TO3gC1KYCBcL3REbG06083N1Zppx5J7VpeXWOqcbUp974wQXWs1B+QJWpMAAUod0t8/z68bK3cyRTYwlj28bJVT/lO1FlyTN6QQ3V4UbPvXGAG2oxWNB7iNF/1JETJHIkAWoHbxQRs+oVibq/0OG988g7CJe1E0psF3Mg6QsBgNTrSrLBZRbOQFOf2VOt6wqZuNsS1F8RKOPrDUNeMEDH7H+hA7p1esW5DRVA9BZwoolc7uFIQCTLrjPah2v+hQ14S4E8uuh38in2pUW7yJqfj7yCOH X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 0d5f404b-5b89-41b1-84c3-08d49a0f7c45 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(201703131423075)(201703031133081);SRVR:BY1PR0501MB1303; X-Microsoft-Exchange-Diagnostics: 1;BY1PR0501MB1303;3:JlhY8ih6LLGTxXxEZOF6jyKr/1/SuzS5LltERA/MqfRkeCV9IB1s1ztzOtTS9k3EvwYH5Bn46Un1y3k9HB4pV4UbIcEru0ZrRXlvF3iIaMfxynvpjuU4pTdNHUPV5Sn3rVIYsHQSYGQ8WFzMVHS7VSBGsgPQ8kkwqYYFVQeIijqvBGvJrv2rDDmyeDzfumb/ba1q5Z2bngZtUZCzOyK668KbEolKN/q2e8qYhh8DxXrANR0+WmzgoUwx9746/tdEYUYNKmfdi/QZ0SI0KaqnodHJI+RTEP3n0vw1dAIZ2pDl6abxaZA0cP+Zs/KDvAXafPEhPlw3JVR6/gQXxmgBd+P1eSsKv9lP0ZS3fLWK23GPFLVFXdpM88H6OrFQKPJH4kuYLqZ2OcpITw5U5Imc8EsZZPDUjPh/4mek2CHyJvDp7GZgG8/U9XyvAXI2OePaDS3yJv4SxhzfNMOEEy0fGw== X-Microsoft-Exchange-Diagnostics: 1;BY1PR0501MB1303;25:76oreod78rHMAlhf2PiS6rS6/PLHgNnE2B2l8utDbostEfCWiBIeGGOg0JqW2yZYaSwmJ/+8FvHn0YBGzcWZ0+TpI4xul4cd5n7AMp/m6sLMx4FfZGmrk1v/upFjwfwBQ0V2JPkTjDkAvUAQqXlZTgcB9ZFfdcEex6zabawDhnm3YCsCJkl1F4A7flee5DqS/U3/MuQgVmXXpMO9VbhBa40Ev+h4DRFt736tgVglWXaNrWhAA48ts3HvsbcUNnEie2p2JIMhiBMall5povMHKnaIokvCDSHRrTSVWls0XiZB1PxugRUIggPrTH2l2xr07/rWsNotBmLVPZOVppayiazKG7kUPxkNGAUnhrHr/+ve5ePNFu44LLFsLixrD4pVE29dC+JuQZPdddCQ+fAwtiNkob/msmz6wD8fdTibeoBpl2utJ0qAQPjYQVhNmw4E6nWnI0O7uD88LN2P0JZa16eor7aOQTiHu5cnLea0ys0=;31:vkQrD+PZH9T08+YcUDm4ZytlcruhV5gxt+RT8hk+3WoOSe81xePzkKFVQUNQ2M6VUq76rLrB64obuiNXi1ceF1yD9bbkhUz6S4m+MaCKSuZ3R+JujlvpWZ2LfEduoNvwsfpmIhMdMwHM51QQqaEqaipwgEypK9mTiuliJyqYi+xwwEUhC95kkP1jsOlrwg7jFt9B0zSYmBwPgLklm3uFWnW/dhbn9klluIkFoquXuhCwKlJJGqLNabkdqQqnN9X7zsZt2tnJi/Ky+Z5Te+DW0Q== X-Microsoft-Exchange-Diagnostics: 1;BY1PR0501MB1303;20:eL8ls26IRlrJCMtS1dGdNZZU+bmw8/4eD012PMq8Q9rLUVDWNXIsEBgciClsvr6aihPHrPsNoiq8NVWzY5YnByOIkxqDrqnzr6zRHryYM9btWfc50ckPEgqH7YxryRdTky83yVKgRE1xDUFyFAIa+hEgTMIDdWDzZasW7J/Hxf02qufA7wKtdEaYymc99ESVt2S1ERRwo0M2DUIz/SEe4jE9LPhoQpPqkQCfC9D9vR7WB0/U1YpTtFrJYz3mYmqWQH9ox9Z5sKrQXBKJUFpp2TgOP/up0694zlvaPHyUG1BM5myGWBrf3ar6rIBaCg/TGyrnIpykcj6qEMq4S4uuzJknuT5HaGg3nVIrznyqCPnwUI9Wg+hh9x8nS6b2B02qD5Swozkyd4hDplgzVnkiw+3ekgn0JAt0OE4RlU2wF9tvWHtJt7+9T7CzGMpQnz9K29IMiE1mCDMMCJKJ/owcMjmUSisI6WxKjUk5fmCh3Aiq2Z2pmA5Ht5qTY1ovlR3x X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(100000700036)(100105000095)(100000701036)(100105300095)(100000702036)(100105100095)(6040450)(601004)(2401047)(13023025)(13024025)(13018025)(5005006)(13017025)(8121501046)(13015025)(10201501046)(100000703036)(100105400095)(93006095)(93003095)(3002001)(6055026)(6041248)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123562025)(6072148)(100000704036)(100105200095)(100000705036)(100105500095);SRVR:BY1PR0501MB1303;BCL:0;PCL:0;RULEID:(100000800036)(100110000095)(100000801036)(100110300095)(100000802036)(100110100095)(100000803036)(100110400095)(100000804036)(100110200095)(100000805036)(100110500095);SRVR:BY1PR0501MB1303; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BY1PR0501MB1303;4:I1gJWjc0uGm8iDtG6ehfxB82QmJ1wpU4vaJRKV7u?= =?us-ascii?Q?4WFbUZHvyDoFB/ha4JlUZ9FA7m4qNm/NdrqLkhmliMuyadonhXRwVIO3HE5J?= =?us-ascii?Q?JmWNZQY10NbwuqHGf7+Wio9dJy/g9m5eBX7sOnOZ8qVKl2BrfteuKYU+VpzE?= =?us-ascii?Q?f4aNga+DmcCKeZRxOc7F1Vk2PR4FS6HN235zbfPTpwWQYKAYtO4wawlI9zNv?= =?us-ascii?Q?z54gEpLXeSGSgVsHuSxLtwCyA4ZjO8yMxynF6bEA6pBEQJP1gmb1jTnxgw3C?= =?us-ascii?Q?tBHWBq2ZfNJCwpWf8vORyOwSpMscGiLnw0sgJQrYICdjUUzcORDyrCmCxdMB?= =?us-ascii?Q?vSYv0k940Ofwn4l1E57QIILgY4hoU8lDdbYPclBoVe2AHtTMSpbHPucmbVnX?= =?us-ascii?Q?UX7NslpZhSz1r+wnbqeOFTcJIhdzV716FpdFiPGf7r+5De6if5JMb8IF4X2n?= =?us-ascii?Q?5C0PCGpzBvjSCpHEQOd9OKtNeN6l4BcuTbjBDTiBZnmVp5M5xp/BQK+wM9Nl?= =?us-ascii?Q?sth9YysjApRt1luJ9AeIwyX4qxkNtS3W1pds1hCinQTJmQFOoNg8C/n8/2DB?= =?us-ascii?Q?axKLYFzPWLAQNMk9zxDzN2ybjB84bfCO1gBfDw9nRsVcj6mpYDttabVmLWFH?= =?us-ascii?Q?ArAGh98CDZyKpYjM6vO7nGLvAldaFXZXBIujvNNu3u55qYuHTPlXHLd78beo?= =?us-ascii?Q?Wf+6CFoa5QhD6NSQwcVp6whpPZNKneR8cCmoeaRWzcgA/3tOfydVfBzerDvG?= =?us-ascii?Q?wTGaPwOZkxqBEN480DO8moZAMp5oVc6yCm9abG6T3zM8c5lEplxWjJIxftw0?= =?us-ascii?Q?2KOiRCRjhKn9wHPs9SxCdKv12l8Rd9MpB9vSajyPIe3gN9+PzL6Uant3dEhU?= =?us-ascii?Q?ONVhChz4M6HqjSUwHDQn95deqX81Noa6wSZyFWIukM13meE0AfrFVp1rvIVz?= =?us-ascii?Q?NNxuv8cUP34kjiR2PfDrSES895UDoaPDZOA/mXhHlAOMs47V+B2f/NlspDit?= =?us-ascii?Q?fSjOAgUpyP+jy6LhdOimF7V7jIPG4lwh0DYJkFPtwlMzPILt0s7DOIUFto5p?= =?us-ascii?Q?ysFPOPGprn5YhQwtHHJllGIiDvi+KRlAY/R/xlaHPD53nJdJKSNhvGiCbW4G?= =?us-ascii?Q?r9WAKNLhS0CWjPfXBcdhOCTSso3yj8E9xWvVwGHvabJm8j7qloL97fKLl2OA?= =?us-ascii?Q?5z4pCDKp0usoKgJxFzNKRTJx+RZFR1r39B/0kb3/jcVb6LzYBSkwQ+rrDICn?= =?us-ascii?Q?aE0fUd+Oejo02tUXkWg=3D?= X-Forefront-PRVS: 0306EE2ED4 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BY1PR0501MB1303;23:rxPzcEyyZX08EgfqHgbpyOXHAhmN1pJV9KeTyCz?= =?us-ascii?Q?p9ANKMTgFzgx13+NPO5HMFzkyTQAg11+COS13qvtYKjalzs9VcBMP1LTsflo?= =?us-ascii?Q?LQ+a8VtfjPxDErND8sCUgUnZoIZP48MtK0iy9UcSItDAQIzyvXu8P443cGY2?= =?us-ascii?Q?uPAU8K1Zpy4HvxCpEJMN7VMtKh40stFtymH+7C8nAalNDGh749KMHtlhEeoe?= =?us-ascii?Q?x33zO+FlR/QbUTr4C6IKFFvt6QT36B0flWigrlfyGYcoNvwmHH7vheXXTNEU?= =?us-ascii?Q?5B7CXXKf+LEyFo0+I4+To6pbenm2+pe95ywpVeHnRNBBSLtP7JQNFQ0bWM+C?= =?us-ascii?Q?E/sMQ22wP5cmoxOY8z8HGkG/6cna1ePliXXhCVryoa4Z2VfMTL4PmOtJbcFz?= =?us-ascii?Q?Frs+PHnX5NJZkA1q0l7gxpaUif/wkF2zjWAk7exEV0BqVfWh9ZI7oHaouTik?= =?us-ascii?Q?VkdUTqZVy1NoB3XOuFYq93VqxrF55hJcrR2IqxhcOVc5FOUAsVS37/MijTI1?= =?us-ascii?Q?/If/3Dg7uQnlev7WRG55WOoy7mUvNqwiizv+RMaLhWM6Z4QQTzGXic1FpWc8?= =?us-ascii?Q?f53SRmbsME9+1P80kdefKq+XX28B/HWd+wvLar0jZdPQ8a2TdGEMRZi3Xhbo?= =?us-ascii?Q?6+hJhczcHwnLSCZqrxm+lhx3qLOycpqcBhgJteeAVTA6G7i1zHyi77tra2Cq?= =?us-ascii?Q?dJY4bwHCmounmXA/s0weRqO25CFIixqNAnDI2p2XgS6n6eQ5jc3e7AomuyIe?= =?us-ascii?Q?a2OfveOTsMlTtvi0L55eMrKU8hvKdljCQ9in/G4ZpCyeGvN+solV20XUm6r7?= =?us-ascii?Q?3kySfqdslpx8LmaxGVt9270Rcehi5Oj/Efz4aMsxKFKn4f13TFqgrhip2v7D?= =?us-ascii?Q?PeH/uHJRMtQqJEH6lMsObAJ0yF0RMOvxogTo6V3YbE3Woi8zhr5BXNUy7sGx?= =?us-ascii?Q?bf17YvsE0rZ1uvHIgk/jo95F64nRb4qBOxcdNyoR0CeTa2HTQbnkF97TOl2D?= =?us-ascii?Q?nLkkEeO1beegOfhXJSjRfbKwP0uQ2UKWE5AkOk+o7QgTSN8tZoTq4vt4Fp8/?= =?us-ascii?Q?8B0DcwEvEYfKx9TizQeb1Ki1/wmVyU023PGOlYaWJ+qq9jMHoixKpMaEFHhd?= =?us-ascii?Q?kvKKHQVk+PvBWUvh7c8D+pgglr/CMaWFqJ2CHowMdfUQM15wr3itTP4pFgBt?= =?us-ascii?Q?cBmzIUmrQ/zxX5hhd6tH4Cdhb/cxko8jqri3zybMA17PUXjQ4/+bnxDNEWpA?= =?us-ascii?Q?2XwGJfXvnRK3XfNakl5cOv0ASk220Swx6EmeUsK4CD5yjJfx6kxqxkpHUT71?= =?us-ascii?Q?W7ygMKdp9meaoYVNImOPUIvP8q67gbtU6B8DLMkcqu4t2nCcvBskIEsJwq7E?= =?us-ascii?Q?p4Cg6TAXe6RsBsP3toU7aL4CZJYU=3D?= X-Microsoft-Exchange-Diagnostics: 1;BY1PR0501MB1303;6:qDDTJzn5O7GYbcpRMdqFtIFeRqDSwrngdBlq/dG0oRhnZC9Ls+9JJuBdnDds50z4bbPCP+CfgtPIwdfZEjlpJJxZef2OeVEae1kNLeeoWM/9kupUqwfKdxW85V+Ywh6HFbDCoy8KV5mcTYltHImAN2HCPwrtQNDM5J6IqYSBVHw7XaWMxdODTMwPl/I/jyhupgqoKJB4j8XhDSpL8xQfsD+a4dkPDPUxu6ODa6JGQjxAtZOWcOIGQFPM9VkK77UmIf3WZzWrovf/hJfVLI8NEwookHMHzeGepgbm7c0F5pCNeMzWF6EFtVSeYVh3Rg9+2YcOxWBmid8GDqKJseOxswDid+k1xwD7+EcFP4g+OKzbLKiXMwEtO4Bhwm1tUx2iTdO+JgxKQgSI2OKCUbnvd2Cc2Al9AnZ10v2dXn5T3m3PlJB23iFXl27oEpRPMnC2zjiyTs+CrJt7ShgkXfwaebxFtO1+SgtUJYydhqskmyoziDJeL4IgHkFJBLC5rcj/wU0ZngGjdA9g6SrvolJaqWOxlUNfwDv5FlKGGKyEoeE= X-Microsoft-Exchange-Diagnostics: 1;BY1PR0501MB1303;5:6ssisPHO4++mnalbJMwj/gcIHk7lrzdV6EKdffPVQYNs1OaTVabJLwK+8MMGMJ5yWsRKdzgFRRB00fEn1Oe9j6e63o2IkeFkzrX4uyJDB2ka/8FFMhBAq9DbYHyWnFkEAJqU3BJ8w4I5vjIYyra7wr+eu1WWya15ujNmhuESLmD0FiECSeJRWbP7wFnCCLqPwvgNCQIaLFnjYwATXVX5oGTEhGIp3TDdV7CAyRifoqIhXdpBPCuHJodcatS3sjLZCQlqf33Eh87FRqciozctpscbp2TCjxMQKPdqZh/HRzJTKSfyKJzUL0kPqgPw8w/h/X+04+4MXLzd/k9gwiE1NFcJQSsZ/yWrxTsY75CZ32k8M74jk89SMNCBF2E9ZRdaQUeRZUVR6dMPxqRD6h8ehBoTvt0ucb6/D9Wtf5T8/beUUD2lwyy5gt/e4uBqr0xvYhJgS4/9jJ+NlIHR0wlmzmR3I36V+iEAghTRBmETM0PhGMb0mBHRFKy4J3OZuTPc;24:rcjb7i8ZX2aAbFR9fyW+ndD0OpCjv6RY3Xp+InR21U1slec7X12q+pAM0hAhZeEBbu1RKIpc1hvv4dtbmh6dG4CCTOI/Ibzs5IRTGOGN2bM= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;BY1PR0501MB1303;7:QG43vi8ArBJ/xZsSzCLDs7OjtsgboqMi78RBvfTlTslGWZZCs1NuzhDA47EsvhQ8FzaU2/I+Hm3kF0Wn71IwG9IsAD3WpFT8waOBx76UrBH4TPp6kgq4JAuAJB7qycosY4ARAHdY6Q1wwwZMHteemeJ/x67jMxUWrYniwy6qG4hx7Q96CKmHGRiNZXNX7e52j/g3+bkFGYKcMz3RS81ZiYfO5P+bRuy8VKogtbcPqmRNzI7p57NK0S0VgNHCfzvWx8Kb49Uzk7kYEDoMk75si+kFRK9ZamWrYKjvdis8DsM1+z4gbTZxkXD2Q/RXF3Oum3Pnajpg4u4RWa2lNMkAyg== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 May 2017 14:51:06.2757 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.12];Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1303 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list List-Unsubscribe: Hi Ron, I have made some adjustments. Here is a unified diff of the relevant changes to the .txt form of the draft. If the pseudo-code looks bad, let me know if I should just remove it or not. --- draft-ietf-curdle-ssh-curves-05.txt 2017-05-11 11:58:23.000000000 -0700 +++ draft-ietf-curdle-ssh-curves-06.txt 2017-05-13 07:46:54.000000000 -0700 @@ -140,47 +140,64 @@ only to be applicable to the scope of the mechanism described in this document. - The shared secret, K, is defined in [RFC4253] as a multiple precision - integer (mpint). Curve25519/448 outputs a binary string X, which is - the 32 or 56 byte point obtained by scalar multiplication of the - other side's public key and the local private key scalar. The 32 or - 56 bytes of X are converted into K by interpreting the bytes as an - unsigned fixed-length integer encoded in network byte order. This - conversion follows the normal "mpint" process as described in section - 5 of [RFC4251]. + The shared secret, K, is defined in [RFC4253] and [RFC5656] as an + integer encoded as a multiple precision integer (mpint). + Curve25519/448 outputs a binary string X, which is the 32 or 56 byte + point obtained by scalar multiplication of the other side's public + key and the local private key scalar. The 32 or 56 bytes of X are + converted into K by interpreting the octets as an unsigned fixed- + length integer encoded in network byte order. + + The fixed-length integer is then minimized into the minimum number of + octets to represent a positve mpint. This conversion follows the + normal "mpint" process as described in section 5 of [RFC4251] which + requires that unnecessary leading bytes with the value 0 MUST NOT be + included. The length of the integer is then prepended with a 4 octet + big-endian integer which is the length in octets of the minimized K. + + The mpint K is then fed along with other data to the key exchange + method's hash function to generate encryption keys. To clarify a corner-case in this conversion, when X is encoded as an mpint K, in order to calculate the exchange hash, it may vary as follows: - o Trim all leading zero-bytes of X. If X is all zero-bytes, then - the key exchange MUST fail. - - o If the high bit of X is set, the mpint format requires a zero byte - to be prepended. - - o The length of the encoded K may not be the same as the original - length of X due to trimming or prepending zero-bytes as needed for - "mpint" format. - Or, as pseudo code: + o Trim all leading zero-bytes of X, as required in section 5 of + [RFC4251]. If X is all zero-bytes, then the key exchange MUST + fail as required in section 6 of [RFC7748]. + + o Given X is a positive, if the MSB of X is set, then the "mpint" + format requires a zero-byte to be prepended. + + o The length of the "mpint" form of K may not be the same as the + original length of X due to trimming or prepending zero-byte + values as needed for "mpint" format. prepend K with the big-endian + number of octets for the length of K. + + Or, as pseudo code (without dealing with side-channel issues): k := x; - while (k.length() > 0 && k[0] == 0) k = k[1:]; + while (k.length() > 0 && k[0] == 0) k := k[1:]; assert(k.length() > 0); - if 0 != (k[0] & 0x80) k = '\0' .. k; + if 0 != (k[0] & 0x80) k := '\0' .. k; + l[0] := k.lengh() >> 24; + l[1] := (k.lengh() >> 16) & 0xff; + l[2] := (k.lengh() >> 8) & 0xff; + l[3] := k.lengh() & 0xff; + k := l .. k; Figure 1 When performing the X25519 or X448 operations, the integer values - there will be encoded into byte strings by doing a fix-length + there will be encoded into byte strings by doing a fixed-length unsigned litle-endian conversion, per [RFC7748]. It is only later when these byte strings are then passed to the ECDH code in SSH that the bytes are re-interpreted as a fixed-length unsigned big-endian From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon May 15 01:47:20 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46675129C1E for ; Mon, 15 May 2017 01:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=timeheart.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mA0DZeu8GX8B for ; Mon, 15 May 2017 01:47:17 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF038126BF7 for ; Mon, 15 May 2017 01:43:42 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 818AF85691; Mon, 15 May 2017 08:43:40 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 1DFB884DED; Mon, 15 May 2017 08:43:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id B5ACF84DC2 for ; Sun, 14 May 2017 15:27:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=timeheart.net Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.netbsd.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id KcqHdIhZnXLv for ; Sun, 14 May 2017 15:27:19 +0000 (UTC) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 35C9984CFB for ; Sun, 14 May 2017 15:27:17 +0000 (UTC) Received: by mail-pg0-x235.google.com with SMTP id q125so29656448pgq.2 for ; Sun, 14 May 2017 08:27:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timeheart.net; s=mail; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=m6rRm15QzwLidRjMCvmY4pK8hiF+yBPYStqSQfgQDK8=; b=Ckmi3gmcXWEaWzpGiH8cKr0BvqR9plR2unjwtoEX07pXx0HgSsoo2UWin3A6M+lHw3 CXXHpwWaB8SukeqdDn4RiLJsRfT5lSprLEEJ1QPRqnn+Wu4/9C1I6qGm4mdkOnugO5Lo L1bDfQgafPJkEDdxM/YL6CSxkJjB576P/9o7U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=m6rRm15QzwLidRjMCvmY4pK8hiF+yBPYStqSQfgQDK8=; b=T0IhbNjNphPp9Hb9JzfKf3ZlByls963WT2k5VWYwuhmcBYAxBe2fex+17z4gAfJKOz fZ/GYY5jShyQqGWrAH7smggYpCDQAP2nfxgHkruS6nzUN7FN4DTt76/5s6h58wmj8BLr sBjNgcTLX6MSFVO4xcnuTpjE+lYG/5+ilcURr75yp4b7eUkn6qo8OwPmqgmoxjSKNSQ8 4NGJsd9lO98sm6VnbExb2l3M+P+0SG7Bktk2sxkg0j8CPDQSPVOg21UTx+7xPYK1RNnQ ltWdGJu0nU+AFJ/3ly5B+UJKFMezqoauWZTumGEM7vx4E5qhmFYChC37/vkr+ARu6H0t FAIQ== X-Gm-Message-State: AODbwcBdkTYvEUEgLe6TIZdCvjAdsUv2HZf4BABytaRehHRPFX2qFWiu vciXEEwhbhFwOw== X-Received: by 10.98.245.155 with SMTP id b27mr1807355pfm.181.1494775637137; Sun, 14 May 2017 08:27:17 -0700 (PDT) Received: from ?IPv6:2601:647:4282:2200:cfa:5497:d692:7eeb? ([2601:647:4282:2200:cfa:5497:d692:7eeb]) by smtp.gmail.com with ESMTPSA id i68sm14236597pfi.72.2017.05.14.08.27.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 May 2017 08:27:16 -0700 (PDT) From: Ron Frederick Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C0F4140A-D4BE-4544-A79C-AAB8E8EEC1A8" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: ssh-ed25519 implementations Date: Sun, 14 May 2017 08:27:14 -0700 In-Reply-To: <74670.1494687062@eng-mail01.juniper.net> Cc: Eric Rescorla , Brian Smith , denis bider , Simon Tatham , "ietf-ssh@NetBSD.org" , "curdle@ietf.org" To: "Mark D. Baushke" References: <76FD0F39-1F3D-4476-A3D8-D4C942C2EFD1@juniper.net> <36528.1494509552@eng-mail01.juniper.net> <6047C877-67DE-404F-8FBD-5B2C19D16EA6@timeheart.net> <1139.1494566512@eng-mail01.juniper.net> <336063E0-135F-4A75-94E4-71540669E21A@timeheart.net> <74670.1494687062@eng-mail01.juniper.net> X-Mailer: Apple Mail (2.3273) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list List-Unsubscribe: --Apple-Mail=_C0F4140A-D4BE-4544-A79C-AAB8E8EEC1A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Mark, On May 13, 2017, at 7:51 AM, Mark D. Baushke wrote: > I have made some adjustments. Here is a unified diff of the relevant > changes to the .txt form of the draft. If the pseudo-code looks bad, > let me know if I should just remove it or not. I would lean toward removing the pseudo-code, and just letting RFC 4251 = and the examples provided in section 5 there speak for themselves. If = you do that, you probably don=E2=80=99t even need to describe the = details of how to encode the length. All I was really looking for here = is a mention that the length is present after the conversion, since you = had so much detail about the conversion of the integer itself. However, = if you just reference this encoding mechanism you may be fine without = it. You could replace the second and third paragraphs below with: The integer K is then encoded as an mpint using the process described in = section 5 of [RFC451] and the resulting bytes are fed as described in = [RFC4253] to the key exchange method=E2=80=99s hash function to generate = encryption keys. > --- draft-ietf-curdle-ssh-curves-05.txt 2017-05-11 = 11:58:23.000000000 -0700 > +++ draft-ietf-curdle-ssh-curves-06.txt 2017-05-13 = 07:46:54.000000000 -0700 > @@ -140,47 +140,64 @@ > only to be applicable to the scope of the mechanism described in = this > document. >=20 > - The shared secret, K, is defined in [RFC4253] as a multiple = precision > - integer (mpint). Curve25519/448 outputs a binary string X, which = is > - the 32 or 56 byte point obtained by scalar multiplication of the > - other side's public key and the local private key scalar. The 32 = or > - 56 bytes of X are converted into K by interpreting the bytes as an > - unsigned fixed-length integer encoded in network byte order. This > - conversion follows the normal "mpint" process as described in = section > - 5 of [RFC4251]. > + The shared secret, K, is defined in [RFC4253] and [RFC5656] as an > + integer encoded as a multiple precision integer (mpint). > + Curve25519/448 outputs a binary string X, which is the 32 or 56 = byte > + point obtained by scalar multiplication of the other side's public > + key and the local private key scalar. The 32 or 56 bytes of X are > + converted into K by interpreting the octets as an unsigned fixed- > + length integer encoded in network byte order. > + > + The fixed-length integer is then minimized into the minimum number = of > + octets to represent a positve mpint. This conversion follows the > + normal "mpint" process as described in section 5 of [RFC4251] = which > + requires that unnecessary leading bytes with the value 0 MUST NOT = be > + included. The length of the integer is then prepended with a 4 = octet > + big-endian integer which is the length in octets of the minimized = K. > + > + The mpint K is then fed along with other data to the key exchange > + method's hash function to generate encryption keys. >=20 > To clarify a corner-case in this conversion, when X is encoded as = an > mpint K, in order to calculate the exchange hash, it may vary as > follows: >=20 > - o Trim all leading zero-bytes of X. If X is all zero-bytes, then > - the key exchange MUST fail. > - > - o If the high bit of X is set, the mpint format requires a zero = byte > - to be prepended. > - > - o The length of the encoded K may not be the same as the original > - length of X due to trimming or prepending zero-bytes as needed = for > - "mpint" format. >=20 > - Or, as pseudo code: > + o Trim all leading zero-bytes of X, as required in section 5 of > + [RFC4251]. If X is all zero-bytes, then the key exchange MUST > + fail as required in section 6 of [RFC7748]. > + > + o Given X is a positive, if the MSB of X is set, then the "mpint" > + format requires a zero-byte to be prepended. > + > + o The length of the "mpint" form of K may not be the same as the > + original length of X due to trimming or prepending zero-byte > + values as needed for "mpint" format. prepend K with the = big-endian > + number of octets for the length of K. > + > + Or, as pseudo code (without dealing with side-channel issues): >=20 > k :=3D x; > - while (k.length() > 0 && k[0] =3D=3D 0) k =3D k[1:]; > + while (k.length() > 0 && k[0] =3D=3D 0) k :=3D = k[1:]; > assert(k.length() > 0); > - if 0 !=3D (k[0] & 0x80) k =3D '\0' .. k; > + if 0 !=3D (k[0] & 0x80) k :=3D '\0' .. k; > + l[0] :=3D k.lengh() >> 24; > + l[1] :=3D (k.lengh() >> 16) & 0xff; > + l[2] :=3D (k.lengh() >> 8) & 0xff; > + l[3] :=3D k.lengh() & 0xff; > + k :=3D l .. k; >=20 > Figure 1 >=20 > When performing the X25519 or X448 operations, the integer values > - there will be encoded into byte strings by doing a fix-length > + there will be encoded into byte strings by doing a fixed-length > unsigned litle-endian conversion, per [RFC7748]. It is only later > when these byte strings are then passed to the ECDH code in SSH = that > the bytes are re-interpreted as a fixed-length unsigned big-endian --=20 Ron Frederick ronf@timeheart.net --Apple-Mail=_C0F4140A-D4BE-4544-A79C-AAB8E8EEC1A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Mark,

On= May 13, 2017, at 7:51 AM, Mark D. Baushke <mdb@juniper.net> = wrote:
I have = made some adjustments. Here is a unified diff of the relevant
changes to the .txt form of = the draft. If the pseudo-code looks bad,
let me know if I = should just remove it or not.

I = would lean toward removing the pseudo-code, and just letting RFC 4251 = and the examples provided in section 5 there speak for themselves. If = you do that, you probably don=E2=80=99t even need to describe the = details of how to encode the length. All I was really looking for here = is a mention that the length is present after the conversion, since you = had so much detail about the conversion of the integer itself. However, = if you just reference this encoding mechanism you may be fine without = it. You could replace the second and third paragraphs below = with:

The integer K is then encoded as an mpint using the = process described in section 5 of [RFC451] and the resulting bytes are = fed as described in [RFC4253] to the key exchange method=E2=80=99s hash = function to generate encryption keys.


--- = draft-ietf-curdle-ssh-curves-05.txt 2017-05-11 11:58:23.000000000 = -0700
+++ draft-ietf-curdle-ssh-curves-06.txt = 2017-05-13 07:46:54.000000000 -0700
@@ -140,47 = +140,64 @@
   only to be applicable to the = scope of the mechanism described in this
=    document.

- =   The shared secret, K, is defined in [RFC4253] as a multiple = precision
-   integer (mpint). =  Curve25519/448 outputs a binary string X, which is
- =   the 32 or 56 byte point obtained by scalar multiplication of = the
-   other side's public key and the local = private key scalar.  The 32 or
-   56 bytes = of X are converted into K by interpreting the bytes as an
- =   unsigned fixed-length integer encoded in network byte order. =  This
-   conversion follows the normal = "mpint" process as described in section
-   5 of = [RFC4251].
+   The shared secret, K, is defined = in [RFC4253] and [RFC5656] as an
+   integer = encoded as a multiple precision integer (mpint).
+ =   Curve25519/448 outputs a binary string X, which is the 32 or = 56 byte
+   point obtained by scalar = multiplication of the other side's public
+ =   key and the local private key scalar.  The 32 or 56 = bytes of X are
+   converted into K by = interpreting the octets as an unsigned fixed-
+ =   length integer encoded in network byte order.
+
+   The fixed-length integer is = then minimized into the minimum number of
+ =   octets to represent a positve mpint.  This conversion = follows the
+   normal "mpint" process as = described in section 5 of [RFC4251] which
+ =   requires that unnecessary leading bytes with the value 0 = MUST NOT be
+   included.  The length of = the integer is then prepended with a 4 octet
+ =   big-endian integer which is the length in octets of the = minimized K.
+
+   The mpint K is = then fed along with other data to the key exchange
+ =   method's hash function to generate encryption keys.

   To clarify a corner-case in = this conversion, when X is encoded as an
=    mpint K, in order to calculate the exchange hash, it = may vary as
   follows:

-   o  Trim all leading zero-bytes of X. =  If X is all zero-bytes, then
- =      the key exchange MUST fail.
-
-   o  If the high bit of X is = set, the mpint format requires a zero byte
- =      to be prepended.
-
-   o  The length of the encoded K may not be = the same as the original
- =      length of X due to trimming or prepending = zero-bytes as needed for
- =      "mpint" format.

-   Or, as pseudo code:
+ =   o  Trim all leading zero-bytes of X, as required in = section 5 of
+      [RFC4251]. =  If X is all zero-bytes, then the key exchange MUST
+ =      fail as required in section 6 of = [RFC7748].
+
+   o  Given X = is a positive, if the MSB of X is set, then the "mpint"
+ =      format requires a zero-byte to be = prepended.
+
+   o  The = length of the "mpint" form of K may not be the same as the
+=      original length of X due to trimming or = prepending zero-byte
+ =      values as needed for "mpint" format. = prepend K with the big-endian
+ =      number of octets for the length of K.
+
+   Or, as pseudo code (without = dealing with side-channel issues):

=             &n= bsp;    k :=3D x;
- =             &n= bsp;   while (k.length() > 0 && k[0] =3D=3D 0) = k =3D k[1:];
+ =             &n= bsp;   while (k.length() > 0 && k[0] =3D=3D 0) = k :=3D k[1:];
=             &n= bsp;    assert(k.length() > 0);
- =             &n= bsp;   if 0 !=3D (k[0] & 0x80) k =3D '\0' .. k;
+ =             &n= bsp;   if 0 !=3D (k[0] & 0x80) k :=3D '\0' .. k;
+ =             &n= bsp;   l[0] :=3D k.lengh() >> 24;
+ =             &n= bsp;   l[1] :=3D (k.lengh() >> 16) & 0xff;
+ =             &n= bsp;   l[2] :=3D (k.lengh() >> 8) & 0xff;
+ =             &n= bsp;   l[3] :=3D k.lengh() & 0xff;
+ =             &n= bsp;   k :=3D l .. k;

=             &n= bsp;           &nbs= p;        Figure 1

   When performing the X25519 = or X448 operations, the integer values
-   there = will be encoded into byte strings by doing a fix-length
+ =   there will be encoded into byte strings by doing a = fixed-length
   unsigned litle-endian = conversion, per [RFC7748].  It is only later
=    when these byte strings are then passed to the ECDH = code in SSH that
   the bytes are = re-interpreted as a fixed-length unsigned = big-endian
-- 
Ron Frederick
ronf@timeheart.net



= --Apple-Mail=_C0F4140A-D4BE-4544-A79C-AAB8E8EEC1A8-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon May 15 22:08:39 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420CD129B3A for ; Mon, 15 May 2017 22:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.39 X-Spam-Level: X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=denisbider.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wowhKjCuuGnb for ; Mon, 15 May 2017 22:08:37 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45E7512EAAF for ; Mon, 15 May 2017 22:06:01 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 4C46F8557F; Tue, 16 May 2017 05:05:59 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id F162F84D75; Tue, 16 May 2017 05:05:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id EDC9E85692 for ; Mon, 15 May 2017 11:34:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.com Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.netbsd.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 8wyDr5NO0GhQ for ; Mon, 15 May 2017 11:34:57 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 486AE84CFB for ; Mon, 15 May 2017 11:34:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:mime-version:content-type; bh=BoelfvKNtpzwmdRSkvk1zg9SJUANHYlpbetbAToscOg=; b=h3XzAoaFjFnu+2Up2is9Y/s7gMDnXYQENtKqDefhPDYCuR0rkoL7lawJcg6YDtDHv3IBPemQsJxSd EwhlUo2u3+nS4aXZVeaIZjlOsvJB3Alo3ZqqjgMha1vEB09iSebsHaEJ1OHhAbuIhkq4Tpr7XY9mgc PW3E4AJWXPJIzuRx/AEJn1axfCA39bwoaB4RWTojmhoBCZXRaCREAWUVCDmPUquyFisPb/VrdsAqNt xJqPsEkVYXCJUCdg7ao4JTbqdL/VUDXlyH1Od6w1vusL+byCeDYUQEmva+Uj1ausLo8WAfhH9sKuM0 WhYgvbMgZptysB49EZ6njWsV2i34Rtg== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com with ESMTPSA (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) for ietf-ssh@netbsd.org; Mon, 15 May 2017 12:34:51 +0100 Message-ID: <37769EE919F4477A8CF86F6CF05F7128@Khan> From: "denis bider \(Bitvise\)" To: Subject: RomSShell 5.40 client - any experience with key exchange issue? Date: Mon, 15 May 2017 05:34:03 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007C_01D2CD3C.DD0D64A0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_007C_01D2CD3C.DD0D64A0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey everyone! I=E2=80=99ve reached out to AllegroSoft, the developers of RomSShell, to = see if they can help with this issue, but I can=E2=80=99t expect they = will help. Sometimes people do, sometimes not. So I=E2=80=99m wondering if any other SSH server developer has = experienced this issue with the RomSShell client. This is an SSH implementation that runs on resource constrained = hardware, and to which I don=E2=80=99t have source code access. In our = case, a user has provided us with information that suggests the = following is happening: - The RomSShell client connects to our server. SSH version strings are = exchanged. - KEXINIT packets are exchanged and diffie-hellman-group1-sha1 is = negotiated. (That=E2=80=99s the only key exchange algorithm the client = sends. Not sure if this version supports anything else. Perhaps not.) - diffie-hellman-group1-sha1 key exchange occurs, and from the = server=E2=80=99s perspective, is completed successfully. The server = sends SSH_MSG_NEWKEYS and waits for the client. - The client takes a good 25 seconds to think about what the server just = sent. Then it replies with SSH_MSG_DISCONNECT, stating reason code = SSH_DISCONNECT_PROTOCOL_ERROR, and description: =E2=80=9CNot expecting = new keys message=E2=80=9D. For comparison =E2=80=93 the client is able to connect to other SSH = servers, such as OpenSSH; in which case it neither incurs a 25 second = delay (the SSH handshake completes promptly) nor sends this protocol = error message. At this point, my first instinct is to try delaying SSH_MSG_NEWKEYS by a = second or more, in case the client is not ready to receive NEWKEYS at = the same time it=E2=80=99s processing the last DH key exchange message. = However, I=E2=80=99m not sure how that would cause a 25 second delay = before it sends DISCONNECT. Does anyone else have experience with this client, and has resolved this = issue? denis ------=_NextPart_000_007C_01D2CD3C.DD0D64A0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey everyone!
 
I=E2=80=99ve reached out to AllegroSoft, the developers of = RomSShell, to see if=20 they can help with this issue, but I can=E2=80=99t expect they will = help. Sometimes=20 people do, sometimes not.
 
So I=E2=80=99m wondering if any other SSH server developer has = experienced this=20 issue with the RomSShell client.
 
This is an SSH implementation that runs on resource constrained = hardware,=20 and to which I don=E2=80=99t have source code access. In our case, a = user has provided=20 us with information that suggests the following is happening:
 
- The RomSShell client connects to our server. SSH version strings = are=20 exchanged.
 
- KEXINIT packets are exchanged and diffie-hellman-group1-sha1 is=20 negotiated. (That=E2=80=99s the only key exchange algorithm the client = sends. Not sure=20 if this version supports anything else. Perhaps not.)
 
- diffie-hellman-group1-sha1 key exchange occurs, and from the = server=E2=80=99s=20 perspective, is completed successfully. The server sends SSH_MSG_NEWKEYS = and=20 waits for the client.
 
- The client takes a good 25 seconds to think about what the server = just=20 sent. Then it replies with SSH_MSG_DISCONNECT, stating reason code=20 SSH_DISCONNECT_PROTOCOL_ERROR, and description: =E2=80=9CNot expecting = new keys=20 message=E2=80=9D.
 
For comparison =E2=80=93 the client is able to connect to other SSH = servers, such=20 as OpenSSH; in which case it neither incurs a 25 second delay (the SSH = handshake=20 completes promptly) nor sends this protocol error message.
 
At this point, my first instinct is to try delaying SSH_MSG_NEWKEYS = by a=20 second or more, in case the client is not ready to receive NEWKEYS at = the same=20 time it=E2=80=99s processing the last DH key exchange message. However, = I=E2=80=99m not sure how=20 that would cause a 25 second delay before it sends DISCONNECT.
 
Does anyone else have experience with this client, and has resolved = this=20 issue?
 
denis
 
 
------=_NextPart_000_007C_01D2CD3C.DD0D64A0--