Re: ssh-ed25519 implementations

Ron Frederick <> Thu, 11 May 2017 05:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 68A3C127444 for <>; Wed, 10 May 2017 22:22:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.09
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: (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MtRGDrlhBY29 for <>; Wed, 10 May 2017 22:22:03 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AE423126C2F for <>; Wed, 10 May 2017 22:22:00 -0700 (PDT)
Received: by (Postfix, from userid 605) id 6461B855AA; Thu, 11 May 2017 05:21:59 +0000 (UTC)
Received: by (Postfix, from userid 1347) id 0B726855A3; Thu, 11 May 2017 05:21:59 +0000 (UTC)
Received: from localhost (localhost []) by (Postfix) with ESMTP id E0BB884DAA for <>; Thu, 11 May 2017 02:49:33 +0000 (UTC)
X-Virus-Scanned: amavisd-new at
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id 3ggA1Ej36aU5 for <>; Thu, 11 May 2017 02:49:33 +0000 (UTC)
Received: from ( [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0829484CD8 for <>; Thu, 11 May 2017 02:49:32 +0000 (UTC)
Received: by 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;; 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;; 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 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 with ESMTPSA id z68sm416169pgz.14.2017. (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: <>
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: <>
Cc: "" <>, "" <>
To: Mark Baushke <>
References: <>
X-Mailer: Apple Mail (2.3273)
Precedence: list
List-Unsubscribe: <>

On May 10, 2017, at 9:18 AM, Mark Baushke <> wrote:
> Eric Rescorla <> has brought to my attention that in
> 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
>, 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 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 ‘string’ 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: <>

This refers to: <>

I have also implemented <> key exchange as documented at: <>

OpenSSH also implements this, and makes it available under both this name and more recently as just “curve25519-sha256”.

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 <>, 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’m not sure the “mpint" 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