Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#786 - Please, add support to ecdsa key type #7984

Closed
openwrt-bot opened this issue May 15, 2017 · 23 comments
Closed

FS#786 - Please, add support to ecdsa key type #7984

openwrt-bot opened this issue May 15, 2017 · 23 comments
Labels

Comments

@openwrt-bot
Copy link

Uqbar:

At the moment dropbear tool is compiled without the ecdsa key type support.
ECDSA (https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) is considere better than RSA as it requires fewer key bits to gain same security.

@openwrt-bot
Copy link
Author

bjonglez:

You can compile dropbear with the ''DROPBEAR_ECC'' option in menuconfig if you want ECDSA support.

However, it adds 23 KB to the dropbear binary on MIPS, so this may be too much to enable it by default.

From ''package/network/services/dropbear/Config.in'':

config DROPBEAR_ECC bool "Elliptic curve cryptography (ECC)" default n help Enables elliptic curve cryptography (ECC) support in key exchange and public key authentication.
            Key exchange algorithms:
              ecdh-sha2-nistp256
              ecdh-sha2-nistp384
              ecdh-sha2-nistp521

            Public key algorithms:
              ecdsa-sha2-nistp256
              ecdsa-sha2-nistp384
              ecdsa-sha2-nistp521

            Does not generate ECC host keys by default (ECC key exchange will not be used,
            only ECC public key auth).

            Increases binary size by about 23 kB (MIPS).

@openwrt-bot
Copy link
Author

Uqbar:

I think that 23Kb is not overkilling for all devices with 8+MB flash.
We can discuss about the 4MB devices, but surely all other ones can accommodate those 48 disk blocks! For the sake of security.

@openwrt-bot
Copy link
Author

NeoRaider:

I agree that 23K are too much to enable by default.

One option out would be to create two dropbear package variants, so opkg can be used to install one or the other. Then we //might// also select the default variant for each image separately based on the flaash size, but I don't really like that idea, because it would be a deliberate inconsistency between images of the same target.

@openwrt-bot
Copy link
Author

Uqbar:

Well, the current default LuCi theme "bootstrap" is rather large (55kB) if compared to the original openwrt theme (20 kB).
The difference would be enough to accommodate the ECDSA support.

If I could vote, I would bright the "old theme" back in order to make room for better security by default.

This is just my opinion, but I am supporting it with some real numbers.

@openwrt-bot
Copy link
Author

spitfire:

It would be very useful for me - I'm trying to switch to [[https://github.com/ntrippar/sekey|sekey]] which would let me store my key in a more secure way, and it only supports ecdsa keys.

@openwrt-bot
Copy link
Author

metaquanta:

Uqbar's argument is quite strong. It's absurd that LuCi's new theme is more important than including the latest public key crypto. I switched to ed25519 a while ago, and have found it a little annoying keeping around a wrt-only RSA key.

However, it's recently come to my attention that ECC's strength lies only in key size and is actually weaker in a post quantum world than RSA. And we'll be living in a post quantum world sooner than any of us realize (possibly). I, personally, am switching back to RSA with largest supported key sizes.

I hope you've heard the rumors that certain entities have been keeping recordings of our handshakes for some time due to the potential utility of all that old data once anyone can run Shor's.

https://arxiv.org/abs/1706.06752

Even if Moore's law holds, that could still buy us an extra year.

matt

@openwrt-bot
Copy link
Author

jow-:

The size increase in dropbear after compression is ~12KB for x86. The size difference between luci-theme-bootstrap and luci-theme-openwrt after compression is ~1KB.

@openwrt-bot
Copy link
Author

Uqbar:

In my personal case (IPv4 only, mips_24kc), for example I could remove:

  • kmod-usb-ledtrig-usbport (~ 3KB)
  • ip6tables+kmod-ip6tables (~ 7KB)
  • odhcp6c (~23KB)
  • odhcpd-ipv6only (~28KB)
  • libip6tc (~18KB)

which don't really give me anything useful.
Maybe we'd need a bare-bones OpenWRT (ipv4+CLI only).

And I am not really sure on when the quantum world will be effective, though.

@nerdoc
Copy link

nerdoc commented May 12, 2022

IMHO size does not outweigh usability and purpose. You basically can't ssh into an OpenWRT router from a default Linux installation with a default key, which pretty everywhere is ECDSA, be it Debian, Ubuntu, Fedora/OpenSuse or Manjaro/Arch IMHO.

I frequently can't believe that a router does not cope with that as default.
And 23kb may be a problem for tiny routers with few space - it would be ok to disable it there. But on routers with plenty of space, like the Linksys WRT3200ACM, I have more thatn enough space available. So this is just a (still open) bug IMHO.

@ahasbini
Copy link

+1 to support ECDSA in dropbear

@wiseelf
Copy link

wiseelf commented Oct 28, 2022

please add ECDSA

@stevenengland
Copy link

+1 to support ECDSA in dropbear

@Djfe
Copy link
Contributor

Djfe commented Jan 5, 2023

+1 to support ECDSA in dropbear

it's already working

@stevenengland
Copy link

stevenengland commented Jan 7, 2023

Hi @Djfe , thanks for passing by. Can you elaborate a little bit more where I can find information on how to use ECDSA keys? I just tried it again, added a key via LUCI that is correctly piped to /etc/dropbear/authorized_keys But still, the logs say

Pubkey auth bad signature for 'root' with key SHA256:xyz from xyz

A quick try to generate a key brings:

root@openwrt:~# dropbearkey -t ecdsa -f "/root/test_ecdsa"
Unknown key type 'ecdsa'
Usage: dropbearkey -t <type> -f <filename> [-s bits]
-t type Type of key to generate. One of:
                rsa
                ed25519
-f filename    Use filename for the secret key.
               ~/.ssh/id_dropbear is recommended for client keys.
-s bits Key size in bits, should be a multiple of 8 (optional)
           Ed25519 has a fixed size of 256 bits
-y              Just print the publickey and fingerprint for the
                private key in <filename>.

Seems that Ed25519 is supported though...

@LittleNewton
Copy link

It looks like openwrt 22.03.3 still doesn't support ecdsa algorithm.

All my debian 11 server can work well with my pubkey/privatekey pair but openwrt cannot work.

OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2
debug1: Reading configuration data D:\\Users\\newton/.ssh/config
debug2: resolve_canonicalize: hostname 10.1.1.10 is address
debug2: ssh_connect_direct
debug1: Connecting to 10.1.1.10 [10.1.1.10] port 21110.
debug1: Connection established.
debug1: identity file D:\\Users\\newton/.ssh/id_rsa type -1
debug1: identity file D:\\Users\\newton/.ssh/id_rsa-cert type -1
debug1: identity file D:\\Users\\newton/.ssh/id_dsa type -1
debug1: identity file D:\\Users\\newton/.ssh/id_dsa-cert type -1
debug1: identity file D:\\Users\\newton/.ssh/id_ecdsa type 2
debug1: identity file D:\\Users\\newton/.ssh/id_ecdsa-cert type -1
debug1: identity file D:\\Users\\newton/.ssh/id_ed25519 type -1
debug1: identity file D:\\Users\\newton/.ssh/id_ed25519-cert type -1
debug1: identity file D:\\Users\\newton/.ssh/id_xmss type -1
debug1: identity file D:\\Users\\newton/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_for_Windows_8.1
debug1: Remote protocol version 2.0, remote software version dropbear
debug1: no match: dropbear
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 10.1.1.10:21110 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ssh-ed25519-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,kexguess2@matt.ucc.asn.au
debug2: host key algorithms: ssh-ed25519,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes256-ctr
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes256-ctr
debug2: MACs ctos: hmac-sha1,hmac-sha2-256
debug2: MACs stoc: hmac-sha1,hmac-sha2-256
debug2: compression ctos: none
debug2: compression stoc: none
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-ed25519 SHA256:KE/rHohnCsbKrzq5dUTcPOv4E8IyhirlwIRPWe3sHBk
debug1: Host '[10.1.1.10]:21110' is known and matches the ED25519 host key.
debug1: Found key in D:\\Users\\newton/.ssh/known_hosts:2
debug2: set_newkeys: mode 1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey in after 134217728 blocks
debug1: pubkey_prepare: ssh_get_authentication_socket: No such file or directory
debug1: Will attempt key: D:\\Users\\newton/.ssh/id_rsa
debug1: Will attempt key: D:\\Users\\newton/.ssh/id_dsa
debug1: Will attempt key: D:\\Users\\newton/.ssh/id_ecdsa ECDSA SHA256:PwjBL6uVSQDjYyMbkD2ZCGepElYPwCYPzZ4nXYlULuI
debug1: Will attempt key: D:\\Users\\newton/.ssh/id_ed25519
debug1: Will attempt key: D:\\Users\\newton/.ssh/id_xmss
debug2: pubkey_prepare: done
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,rsa-sha2-256,ssh-rsa>
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: D:\\Users\\newton/.ssh/id_rsa
debug1: Trying private key: D:\\Users\\newton/.ssh/id_dsa
debug1: Offering public key: D:\\Users\\newton/.ssh/id_ecdsa ECDSA SHA256:PwjBL6uVSQDjYyMbkD2ZCGepElYPwCYPzZ4nXYlULuI
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: Trying private key: D:\\Users\\newton/.ssh/id_ed25519
debug1: Trying private key: D:\\Users\\newton/.ssh/id_xmss
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
root@10.1.1.10: Permission denied (publickey).

@Djfe
Copy link
Contributor

Djfe commented Jan 31, 2023

so sorry for getting anyone's hopes up
I kinda thought both were the same/ed25519 would be enough for everyone.

I agree on the front that non-"tiny" target's probably have enough free space for ecdsa, but then again: inconsistencies and I don't have any clue of the implications on the build system (if this is even possible unless you have two dropbear packages where one is larger)

Seems to me like the maintainers made a choice and we have to live with Ed25519-support
Which is fine by me. I personally don't care about a third algorithm.

@Djfe
Copy link
Contributor

Djfe commented Jan 31, 2023

If you require ecdsa, then compile your own image, I guess. According to the second post there is a way to enable it in menuconfig during the build.

@LittleNewton
Copy link

@Djfe

ed25519 - this is a new algorithm added in OpenSSH. Support for it in clients is not yet universal. Thus its use in general purpose applications may not yet be advisable.

Thank for your work. Just now I disabled dropbear and using openssh-server (PAM) instead. However, openssh-server is not the default choice of OpenWrt and there is no entry to edit its conf in luci. I hope someday ecdsa can be added to the source code and people can have the choice to enable/disable it. :)

@xrisk
Copy link

xrisk commented Feb 18, 2023

Can it be possible to at least add a warning in luci when one tries to add an unspecified key type?

@Djfe
Copy link
Contributor

Djfe commented Feb 18, 2023

maybe you can open an issue with this feature request
on https://github.com/openwrt/luci/issues/

@zhangyoufu
Copy link

I use (non-exportable) ecdsa keys bounded to secure enclave on MacBook. The only supported key algorithm is ecdsa.

It's unfortunate to see that dropbear on OpenWrt does not come with ecdsa support out-of-box.

@dmuiX
Copy link

dmuiX commented May 26, 2023

@LittleNewton
thanks for pointing out the option to use openssh server.
a bit configuration necessary but its working pretty well.
I was using this tutorial: https://nerdig.es/openwrt-openssh
its actually in german, but if you are familiar with the commands it should be easy/readable.

@RoganDawes
Copy link
Contributor

Sorry to beat a dead horse, but it is not possible to add a dropbear-full package, similar to dnsmasq-full, ip-full, vim-full, etc, that has the full suite of algorithms enabled? Then those of us that need it can install that package.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests