openssh bugs - Oct 2019 - [Bug 3082] New: Add support for deterministically derived keys

https://bugzilla.mindrot.org/show_bug.cgi?id=3082

            Bug ID: 3082
           Summary: Add support for deterministically derived keys
           Product: Portable OpenSSH
           Version: 8.1p1
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh-keygen
          Assignee: unassigned-bugs at mindrot.org
          Reporter: nils.rennebarth at googlemail.com

Created attachment 3335
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3335&action=edit
patch for 8.0p1 to support derived keys

In our project we connect a cluster of appliances to a central managing
system via ssh. When a new appliance is deployed, the administrator
provides it with an ip address and a "connection password". Later, the
manager connects to the configured ip address (over a supposedly
untrusted network), and the "connection password" is used as a shared
secret to build a mutual trust and exchange long lived public keys that
secure all future communication.

[Yes, this provisioning procedure is outdated and should be replaced,
e.g. by letting the appliance generate a key pair locally and just
transmitting the public key to the managing system, but for now we
can't change the established procedure]

Connecting to an untrusted machine via ssh with password authentication
will immediately reveal the shared secret to a man-in-the-middle, so
using the shared secret this way is out of the question.

What we came up with instead is to use the shared secret by
deterministically deriving an ssh key pair on both, the appliance and
the manager. Each side installs the public key in its authorized_keys
file, the manager contacts the appliance first, using the key for
pubkey authentication, and transmit its IP address and its (public)
host key. The appliance will respond in the same way and transmit its
(public) host key. As soon as both sides did receive a message from the
other one, they can trust each other and exchange the long lived keys.

To support this method of trust establishment, I wrote the attached
patch for ssh-keygen, to derive a key from a given secret
eterministically (by seeding the PRNG). The patch applies cleanly to
the original 8.0p1 sources.

Would you consider adding this feature to ssh-keygen? Another possible
use case might be human memorizable key pairs, so I think it is not too
tightly bound to our specific use case.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3082

--- Comment #1 from Nils Rennebarth <nils.rennebarth at googlemail.com>
---
Uhh, the patch only works for ed25519 type keys, as the other keys are
generated by openssl directly, which of course doesn't use the
arc4random random number generator.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3082

--- Comment #2 from Nils Rennebarth <nils.rennebarth at googlemail.com>
---
Created attachment 3336
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3336&action=edit
Improved and updated patch for deterministic keys

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3082

--- Comment #3 from Nils Rennebarth <nils.rennebarth at googlemail.com>
---
I uploaded a new patch, now against 8.1p1, that works for all key
types, i.e. for ed25519 as well as for openssl generated keys.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3082

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #4 from Damien Miller <djm at mindrot.org> ---
Created attachment 3393
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3393&action=edit
deterministic ed25519 key generator

I think this feature is a bit too niche to support in OpenSSH and too
much of a weapon for users to shoot themselves in the feet with.

If you need such an ability, then it's pretty easy to implement as a
standalone program (like the attached proof-of-concept).

We certainly do not want to implement this by adding hooks to the PRNG.
That sort of stuff has yielded compromise after compromise in other
programs.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3082

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3082

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #3393|text/x-go                   |text/plain
          mime type|                            |

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3082

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #5 from Damien Miller <djm at mindrot.org> ---
closing resolved bugs as of 8.6p1 release

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.