Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-72719

oqsprovider stores ML-KEM and ML-DSA private keys in non-standard format

Linking RHIVOS CVEs to...Migration: Automation ...Sync from "Extern...XMLWordPrintable

    • openssl-3.5.1-1.el10
    • No
    • Low
    • 3
    • rhel-security-crypto
    • ssg_security
    • 16
    • 26
    • 0.2
    • QE ack, Dev ack
    • False
    • False
    • Hide

      None

      Show
      None
    • Yes
    • Crypto25Q1, Crypto25Q2, Crypto25July
    • Hide

      For both ML-DSA and ML-KEM algorithms:
      1. OpenSSL is able to create and read files in the IETF standard format, with "seed", "expandedKey" and "both" variants of the private key format
      2. OpenSSL is able to read files created by the oqsprovider we shipped in RHEL-10.0 and convert them to the "expandedKey" format

      Show
      For both ML-DSA and ML-KEM algorithms: 1. OpenSSL is able to create and read files in the IETF standard format, with "seed", "expandedKey" and "both" variants of the private key format 2. OpenSSL is able to read files created by the oqsprovider we shipped in RHEL-10.0 and convert them to the "expandedKey" format
    • Pass
    • Not Needed
    • Automated
    • Known Issue
    • Hide
      .`oqsprovider` stores ML-KEM and ML-DSA private keys in a non-standard format

      The open quantum-safe provider for OpenSSL (`oqsprovider`) generates private keys in a format that does not conform with any of the file formats proposed by the IETF LAMPS work group. Consequently, the key files might be unreadable by other applications that follow the IETF standard and cannot be handled by applications that require providing the key in the seed format for import.

      Because there currently is no workaround, do not use the keys for storing long-term secrets.
      Show
      .`oqsprovider` stores ML-KEM and ML-DSA private keys in a non-standard format The open quantum-safe provider for OpenSSL (`oqsprovider`) generates private keys in a format that does not conform with any of the file formats proposed by the IETF LAMPS work group. Consequently, the key files might be unreadable by other applications that follow the IETF standard and cannot be handled by applications that require providing the key in the seed format for import. Because there currently is no workaround, do not use the keys for storing long-term secrets.
    • Proposed
    • None

      When oqsprovider-0.8.0 is used to generate ML-KEM private keys (to PKCS#8 files), the keys are stored as concatenation of the expanded private key and public key value, not as seed or just the expanded value.

      This is in conflict with https://datatracker.ietf.org/doc/html/draft-ietf-lamps-kyber-certificates-06 draft and all the other proposed formats.

              dbelyavs@redhat.com Dmitry Belyavskiy
              hkario@redhat.com Alicja Kario
              Dmitry Belyavskiy Dmitry Belyavskiy
              George Pantelakis George Pantelakis
              Mirek Jahoda Mirek Jahoda
              Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

                Created:
                Updated: