plan9port ssh-agent: incorrect signature type

[David Arroyo]

I'm using OpenSSH_8.4p1 as my SSH client and set up plan9port's
ssh-agent to pull keys from factotum. I was able to follow rsa(1)
for the most part, with a few exceptions:

For converting an existing key, openssh now uses its own format for
the private key that `asn12rsa` doesn't understand. You have to tell
openssh to use the old format, like so:

ssh_keygen -m PEM

To get a public key suitable for my use case (github) I had to pass the
`-2` flag to rsa2ssh. For example:

rsagen -t 'service=ssh-rsa' | tee -a factotum | rsa2ssh -2 > id_rsa.pub

This seems to go against the documentation, which states

> It decides whether to print in version 1 or version 2 format by
> inspecting the service attribute.

Finally, OpenSSH complains about the ssh-agent signature:

> agent key RSA SHA256:xxxxxxx returned incorrect signature type

SSH access still succeeds, however. I haven't debugged this yet, but I
believe what is happening is that the ssh client is passing a signature
flag to the ssh-agent asking for the stronger hash:

https://tools.ietf.org/id/draft-miller-ssh-agent-01.html#rfc.section.5.3

but the agent ignores it and uses a sha1 hash. Is there a sha256 routine
in plan9port? I looked, but could not find one. I was able to find one
in 9front. Is anyone working on updating libsec? I see issue #448:

https://github.com/9fans/plan9port/issues/448

If I have some spare cycles I can try to work on this, but I'd like some
feedback on the best way to do it. Ideally I would like to reduce the
diffs between plan9port and plan 9, but the various plan 9 flavors may
already be diverging.

David

[LM]

On Mon, Feb 1, 2021 at 11:20 AM David Arroyo <dr...@aqwari.net> wrote:
> but the agent ignores it and uses a sha1 hash. Is there a sha256 routine
> in plan9port? I looked, but could not find one. I was able to find one
> in 9front. Is anyone working on updating libsec? I see issue #448:

Don't know what's used in plan9port, but I use libtomcrypt for my
sha256 routines. I have sha1sum, sha256sum and other utilities I've
written myself and use the libtomcrypt to calculate the hashes.

[David Arroyo]

> Don't know what's used in plan9port, but I use libtomcrypt for my
> sha256 routines. I have sha1sum, sha256sum and other utilities I've
> written myself and use the libtomcrypt to calculate the hashes.

Thanks. I don't know how others feel about adding another dependency
to plan9port, though. On one hand, it's nice that p9p is fairly
self-contained, only relying minimally on x11 and pthreads. On the other
hand it saves some manpower to rely on an external dependency. It
looks like libtomcrypt is in the public domain, so vendoring would also
be an option.

David

[Fazlul Shahriar]

On Mon, Feb 1, 2021 at 11:20 AM David Arroyo <dr...@aqwari.net> wrote:

> [...]

> Is there a sha256 routine
> in plan9port? I looked, but could not find one. I was able to find one
> in 9front.

> [...]

You can copy sha256 from Plan 9 here:
http://9p.io/sources/plan9/sys/src/libsec/port/sha2_64.c
I think it was added to Plan 9 after libsec was ported to plan9port.

fhs

[Eric Grosse]

For refreshing the crypto, openssh's ecdsa_sk and ed25519_sk key types are an improvement over rsa.

I have not yet looked at what this would require changing in Plan 9 or plan9port.

--

---
You received this message because you are subscribed to the Google Groups "plan9port-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to plan9port-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/plan9port-dev/CAA2CNPbE_Bk%3DUm0_WnyOGeQawpqm%3DkWTDiETUA6w2P3PDJUyRw%40mail.gmail.com.

[David Arroyo]

On Mon, Feb 1, 2021, at 14:51, Eric Grosse wrote:
> For refreshing the crypto, openssh's ecdsa_sk and ed25519_sk key types are
> an improvement over rsa.

Yes, it would be nice to use ecdsa keys. For now though, my needs are met
by using large enough RSA keys.

On Mon, Feb 1, 2021 at 11:32 AM Fazlul Shahriar <fsha...@gmail.com> wrote:
> You can copy sha256 from Plan 9 here:
> http://9p.io/sources/plan9/sys/src/libsec/port/sha2_64.c
> I think it was added to Plan 9 after libsec was ported to plan9port.

Ah, thank you! This actually builds under plan9port with very minimal changes.
I will review the commit history for plan9port's libsec to see if any changes
since the split are still applicable. After that I'll make a pull request and look
into adding sha256 signatures to ssh-agent.c and factotum/rsa.c.

Thanks,
David

[David Arroyo]

Currently I've updated libsec and have it working in plan9port. After a
few small fixes it seems to work just fine. I also went through the
changes made to plan9port's version of libsec and re-applied the ones
that weren't upstreamed or obviated, and updated some of the manuals.

Now I'm trying to update ssh-agent and factotum to support sha256 and
sha512 signatures. I am very close but I'm having some trouble, because
I know very little about RSA.

Factotum looks for a `hash=xxx` field in the key to decide the hash
to use for signing. But I thought that you could use the same RSA key
to sign arbitrary blobs of data. Indeed, looking at factotum's source,
it looks like it only uses the hash to determine how many bytes to read
from the speaker.

I updated ssh-agent.c to check signature flags in the
SSH_AGENTC_SIGN_REQUEST message, but what I'm seeing is that my ssh client
makes multiple requests, some with the SSH_AGENT_RSA_SHA2_512 flag and
some with no flag (e.g. sha1). And because factotum expects hash=xxx
to be part of the key, I have to duplicate the same key multiple times,
with whatever hash=xxx I can expect the ssh client to set.

Duplicating does seem to work, but it seems unnecessary. I think there
should be a way for a client of factotum to request a signature for an
arbitrary payload, either by making the `hash` part of a key not affect
its lookup, or by having factotum simply read and sign whatever the
client sends, rather than try to read a fixed number of bytes.

I tried looking at what plan 9 and 9front do here but they seem to behave
the same way, expecting hash to be part of the key but only using it
to determine the size of the resulting ASN.1 structure. Am I missing
something here?

David