• Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Normal Normal
    • rhel-10.1
    • rhel-10.0
    • openssh
    • No
    • Low
    • 2
    • rhel-sst-security-crypto
    • ssg_security
    • 10
    • 0.5
    • False
    • Hide

      None

      Show
      None
    • No
    • Crypto25Q1, Crypto25Q2
    • Hide

      AC1: ssh connection using mlkem hybrid algo between upstream openssh package and our downstream package works
      AC2: manual check if connection between x86_64 and s390x platforms works

      Show
      AC1: ssh connection using mlkem hybrid algo between upstream openssh package and our downstream package works AC2: manual check if connection between x86_64 and s390x platforms works
    • Pass
    • Not Needed
    • New Test Coverage
    • Unspecified Release Note Type - Unknown
    • None

      OpenSSH 9.9+ (not in RHEL yet) will have its own implementation of MLKEM on board.

      We should implement a patch making it using OpenSSL implementation of MLKEM.

            [RHEL-58252] OpenSSH should not use its own implementation of MLKEM

            The Fedora work is separated to a different card

            Dmitry Belyavskiy added a comment - The Fedora work is separated to a different card

            Miluse Bezo Konecna added a comment - - edited

            Tested on Fedora Rawhide, works as expected

            Miluse Bezo Konecna added a comment - - edited Tested on Fedora Rawhide, works as expected

            I pushed a build to rawhide, so we can start testing

            Dmitry Belyavskiy added a comment - I pushed a build to rawhide, so we can start testing

            Dmitry Belyavskiy added a comment - https://github.com/beldmit/openssh-portable/tree/openssl_mlkem is an implementation

            How I propose to test this change (Fedora rawhide for now, RHEL later)

            We test the compatibility with upstream so we build upstream.

            (Until we have OpenSSL 3.5 with MLKEM on board)
            When oqsprovider is installed the mlkem768-based kex should work between our build and upstream build. We also should test (manually?) compatibility between x86_64 and s390x platforms in both directions.

            When oqsprovider is not installed the mlkem768-based kex should not work. When several KEX methods are configured and mlkem-based is preferred, it should NOT appear in the list on the side where oqsprovider is not installed

            Dmitry Belyavskiy added a comment - How I propose to test this change (Fedora rawhide for now, RHEL later) We test the compatibility with upstream so we build upstream. (Until we have OpenSSL 3.5 with MLKEM on board) When oqsprovider is installed the mlkem768-based kex should work between our build and upstream build. We also should test (manually?) compatibility between x86_64 and s390x platforms in both directions. When oqsprovider is not installed the mlkem768-based kex should not work. When several KEX methods are configured and mlkem-based is preferred, it should NOT appear in the list on the side where oqsprovider is not installed

            We implement it for rawhide, test it, and then backport to RHEL 10.smth

            Dmitry Belyavskiy added a comment - We implement it for rawhide, test it, and then backport to RHEL 10.smth

            Dmitry Belyavskiy added a comment - - edited

            https://gitlab.com/secsh/pkixssh/-/commits/hybrid_demo may be used as an example of the code No, it relies on the upstream code

            Dmitry Belyavskiy added a comment - - edited https://gitlab.com/secsh/pkixssh/-/commits/hybrid_demo may be used as an example of the code No, it relies on the upstream code

            Dmitry Belyavskiy added a comment - - edited

            cllang@redhat.com I remove it from the erratum, I'd say no chance for Q4, and realistic timeline is 10.0.z/10.1

            Dmitry Belyavskiy added a comment - - edited cllang@redhat.com I remove it from the erratum, I'd say no chance for Q4, and realistic timeline is 10.0.z/10.1

              dbelyavs@redhat.com Dmitry Belyavskiy
              dbelyavs@redhat.com Dmitry Belyavskiy
              Dmitry Belyavskiy Dmitry Belyavskiy
              Miluse Bezo Konecna Miluse Bezo Konecna
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated: