[Ovmsdev] wolfssh vs openssh 8.8p1

[Mark Webb-Johnson]

Unlike a certificate, I don’t think RSA keys are ‘signed’ in the file at all.

My guess is the Sha-1 signing happens dynamically at Key exchange time in the Wolf library. Perhaps there is an option to enable Sha-256 for that?

Regards, Mark

> On 24 Oct 2021, at 1:05 PM, Stephen Casner <casner at acm.org> wrote:
> 
> Craig,
> 
> The WolfSSH API includes the function to make an RSA key, but I don't
> see any alternatives.  The ciphers ecdsa and ed25519 are included in
> WolfSSL, but I don't know if manually supplying a host key generated
> with those algorithms would work since some of the metadata might
> still imply RSA.
> 
> If the problem is SHA-1, could an RSA host key be signed with SHA-256
> hash instead?  (But I don't see an option in the key generation to
> choose a differnt hash algorithm.)
> 
>                                                        -- Steve
> 
>> On Sat, 23 Oct 2021, Craig Leres wrote:
>> 
>> I recently upgraded many systems to openssh-portable 8.8p1 which disables
>> rsa/sha1 signatures by default. I believe my ovms modules are using ssh-rsa
>> for their host keys:
>> 
>>    ssh -vv ovms-z
>>    OpenSSH_8.8p1, OpenSSL 1.1.1l  24 Aug 2021
>>    [...]
>>    debug1: kex: algorithm: ecdh-sha2-nistp256
>>    debug1: kex: host key algorithm: (no match)
>>    Unable to negotiate with 172.16.1.88 port 22: no matching host key type
>> found. Their offer: ssh-rsa
>> 
>> The suggested workaround works but is it possible for me to generate a ecdsa
>> or ed25519 host key offline and install it in the module? Should we consider
>> changing the key type generated on first use?
>> 
>>        Craig
>> 
>> https://www.openssh.com/txt/release-8.8
>> 
>> Potentially-incompatible changes
>> ================================
>> 
>> This release disables RSA signatures using the SHA-1 hash algorithm
>> by default. This change has been made as the SHA-1 hash algorithm
>> is cryptographically broken, and it is possible to create chosen-prefix
>> hash collisions for <USD$50K [1]
>> 
>> For most users, this change should be invisible and there is no
>> need to replace ssh-rsa keys. OpenSSH has supported RFC8332
>> RSA/SHA-256/512 signatures since release 7.2 and existing ssh-rsa
>> keys will automatically use the stronger algorithm where possible.
>> 
>> Incompatibility is more likely when connecting to older SSH
>> implementations that have not been upgraded or have not closely
>> tracked improvements in the SSH protocol. For these cases, it may
>> be necessary to selectively re-enable RSA/SHA1 to allow connection
>> and/or user authentication via the HostkeyAlgorithms and
>> PubkeyAcceptedAlgorithms options. For example, the following stanza
>> in ~/.ssh/config will enable RSA/SHA1 for host and user authentication
>> for a single destination host:
>> 
>>    Host old-host
>>        HostkeyAlgorithms +ssh-rsa
>>        PubkeyAcceptedAlgorithms +ssh-rsa
>> 
>> We recommend enabling RSA/SHA1 only as a stopgap measure until
>> legacy implementations can be upgraded or reconfigured with another
>> key type (such as ECDSA or Ed25519).
>> 
>> [1] "SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1
>>    and Application to the PGP Web of Trust" Leurent, G and Peyrin,
>>    T (2020) https://eprint.iacr.org/2020/014.pdf
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev