Version: 2025.88-1
Severity: important
X-Debbugs-Cc: mike.travis3@yahoo.com

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
I've juste installed dropbear v2025.88-1 coming with the new trixie version of Debian.
   * What exactly did you do (or not do) that was effective (or
     ineffective)?
WHen I try to uncrypt my disk remotly with putty , I got stuck with this error src/rsa.c : 398 : rsa_pad_em : Assertion 0 failed
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***

Control: reassign -1 dropbear-bin 2025.88-1
Control: title -1 dropbear: src/rsa.c : 398 : rsa_pad_em : Assertion 0 failed
Control: tag -1 + moreinfo

Is dropbear 2025.88-1 the SSH server or client (or both)?  Which
server/version are you using on the other end?  Is it a client-side
or server-side crash?

In case dropbear 2025.88-1 is the client (dbclient(1)), does it work
with OpenSSH's ssh(1)?

   - dropbear 2025.88-1 is the SSH server

   - the client trying to connect is a Debian 11 computer with putty. SSH version is OpenSSH_8.4p1
   - At the stage when the error occurs, Open SSH is not active as disks are still encrypted. Only Dropbear is running at this stage.


    Le jeudi 26 juin 2025 à 14:31:42 UTC+2, Guilhem Moulin <guilhem@debian.org> a écrit :

 Control: reassign -1 dropbear-bin 2025.88-1
Control: title -1 dropbear: src/rsa.c : 398 : rsa_pad_em : Assertion 0 failed
Control: tag -1 + moreinfo

Is dropbear 2025.88-1 the SSH server or client (or both)?  Which
server/version are you using on the other end?  Is it a client-side
or server-side crash?

In case dropbear 2025.88-1 is the client (dbclient(1)), does it work
with OpenSSH's ssh(1)?

If you're connecting from bullseye's putty then the client is putty
0.74-1+deb11u2.  Though I was also asking whether it works with OpenSSH
(openssh-client 8.4p1-5+deb11u5).

My question was whether it works with the OpenSSH *client* (and dropbear
2025.88-1 as server) and the same key material.

I am able to use ssh(1) from openssh-client 1:8.4p1-5+deb11u5 on a
bullseye system to connect to dropbear(8) from dropbear-bin 2025.88-1 on
a sid system, but I don't have a graphical bullseye system at hand to
try with putty.

Looking at the putty changelog [0] I see that 0.74 doesn't support
rsa-sha2-* (and that 0.75 through 0.81 have incorrect padding).

 * 0.75 (released 2021-05-08) Support for RSA key algorithms using SHA-2
   instead of SHA-1.
 * 0.82 (released 2024-11-27) Bug fix: SHA-2 based RSA signatures are
   now sent with correct zero padding.

Since 2025.87-1 dropbear is built without algorithms using SHA-1
following an upstream decision.  Quoting /usr/share/doc/dropbear-bin/changelog.Debian.gz

    dropbear (2025.87-1) unstable; urgency=low

      * New upstream release.  Highlights includes:
        […]
        + Due to vulnerabilities in the SHA-1 digest algorithm, dropbear(8) and
          dbclient(1) are now built without support for the ‘hmac-sha1’ integrity
          algorithm, ‘ssh-rsa’ key algorithm, and ‘diffie-hellman-group14-sha1’
          key exchange algorithm.  (The ‘diffie-hellman-group1-sha1’ key exchange
          algorithm, which also uses SHA-1, has been disabled at build time for
          dropbear(8) since 2018.76-1, but remains available to dbclient(1).)

          Note that OpenSSH has disabled support for these algorithms by default
          (runtime) since 8.8.  There is *no need* to rotate existing RSA host or
          user keys: OpenSSH has been supporting RFC8332 RSA/SHA-256/512
          signatures since 7.2, and dropbear since 2020.79.  However this change
          might break connection to legacy servers resp. from legacy clients.

It shouldn't yield at exception failure though.  Try booting with
'debug' in the kernel boot parameters (or alternatively by adding "-E"
to DROPBEAR_OPTIONS in /etc/dropbear/initramfs/dropbear.conf and
rebuilding the initramfs).  Do you see a "No matching algo hostkey"
error on the dropbear side before reaching the assertion failure?

 I upgraded my client to Debian 12 bookworm, therefore putty has automatically been upgraded to 0.78 (instead of 0.74 formerly ) and it works fine: I can uncrypt my disks using dropbear and the error does not appear.
Seems fine in this configuration.

    Le jeudi 26 juin 2025 à 15:40:10 UTC+2, Guilhem Moulin <guilhem@debian.org> a écrit :

 On Thu, 26 Jun 2025 at 12:43:12 +0000, mike travis wrote:

If you're connecting from bullseye's putty then the client is putty
0.74-1+deb11u2.  Though I was also asking whether it works with OpenSSH
(openssh-client 8.4p1-5+deb11u5).

My question was whether it works with the OpenSSH *client* (and dropbear
2025.88-1 as server) and the same key material.

I am able to use ssh(1) from openssh-client 1:8.4p1-5+deb11u5 on a
bullseye system to connect to dropbear(8) from dropbear-bin 2025.88-1 on
a sid system, but I don't have a graphical bullseye system at hand to
try with putty.

Looking at the putty changelog [0] I see that 0.74 doesn't support
rsa-sha2-* (and that 0.75 through 0.81 have incorrect padding).

 * 0.75 (released 2021-05-08) Support for RSA key algorithms using SHA-2
  instead of SHA-1.
 * 0.82 (released 2024-11-27) Bug fix: SHA-2 based RSA signatures are
  now sent with correct zero padding.

Since 2025.87-1 dropbear is built without algorithms using SHA-1
following an upstream decision.  Quoting /usr/share/doc/dropbear-bin/changelog.Debian.gz

    dropbear (2025.87-1) unstable; urgency=low

      * New upstream release.  Highlights includes:
        […]
        + Due to vulnerabilities in the SHA-1 digest algorithm, dropbear(8) and
          dbclient(1) are now built without support for the ‘hmac-sha1’ integrity
          algorithm, ‘ssh-rsa’ key algorithm, and ‘diffie-hellman-group14-sha1’
          key exchange algorithm.  (The ‘diffie-hellman-group1-sha1’ key exchange
          algorithm, which also uses SHA-1, has been disabled at build time for
          dropbear(8) since 2018.76-1, but remains available to dbclient(1).)

          Note that OpenSSH has disabled support for these algorithms by default
          (runtime) since 8.8.  There is *no need* to rotate existing RSA host or
          user keys: OpenSSH has been supporting RFC8332 RSA/SHA-256/512
          signatures since 7.2, and dropbear since 2020.79.  However this change
          might break connection to legacy servers resp. from legacy clients.

It shouldn't yield at exception failure though.  Try booting with
'debug' in the kernel boot parameters (or alternatively by adding "-E"
to DROPBEAR_OPTIONS in /etc/dropbear/initramfs/dropbear.conf and
rebuilding the initramfs).  Do you see a "No matching algo hostkey"
error on the dropbear side before reaching the assertion failure?

Control: severity -1 normal
Control: tag -1 - moreinfo

Alright thanks for confirming, then it's definitely due to some
algorithm incompatibility due to the SHA-1 removal.  Leaving the bug
open as it shouldn't reach an assertion failure, but lowering its
severity.  Perhaps the incompatibility mentioned in changelog.Debian
should be raised to the NEWS file, too.