lamps-wg / dilithium-certificates

I-D that describes the algorithm identifiers for NIST's PQC Dilithium algorithm for use in the Internet X.509 Public Key Infrastructure
Other
4 stars 0 forks source link

public key as octet string #4

Open csosto-pk opened 2 years ago

csosto-pk commented 2 years ago

Address discussion in https://mailarchive.ietf.org/arch/msg/spasm/pDD40rIFpdN7SijRp_2WgihRbxA/ about bit or octet string according to consensus

csosto-pk commented 2 years ago

By Simon G.

  • I also support the byte array encoding for the private key proposed by the algorithm designers. It is an already defined encoding, so I think it makes sense to take that one. Also the public key is encoded as an array (but as a BIT STRING instead, because of rfc 5912), so I think to be at least somewhat consistent the private and public key should be encoded as an OCTET STRING and BIT STRING respectively.
  • On that note I just wanted to add that I think it would make more sense that the public key is also encoded as an OCTET STRING, but I guess that can't happen because of backward-compatibility.
csosto-pk commented 2 years ago

By Markku,

I guess it can be a BIT STRING, but it clearly must be of a specific length. For verification purposes, the algorithm identifiers for Dilithium2, Dilithium3, and Dilithium5 should be explicit. Determining that from the public key length is a hack and could be a security issue. Just noting that for completeness; the current "id-dilithiumTBD" is clearly temporary. Anyway, a Dilithium-in-PKI I-D would need very clear verification rules related to this issue.

Whatever format the public key is wrapped in, the "raw concatenated sequence of bytes" (without any ASN.1 tags, as defined for algorithm designers for public keys) is actually used inside the signature process itself: the thing being signed is always prefixed by its hash: mu = H( H(pk) | m ). One obviously can't sign or verify in an interoperable fashion if one doesn't use that specific raw format for the hash prefix H(pk), also denoted "tr" in the spec. It is encoded into the secret key just to tie the public key with the secret key: Key import functions must check that the "tr" hash matches.

csosto-pk commented 1 year ago

Current language used is similar to RFC3279 says

The elliptic curve public key (an ECPoint which is an OCTET STRING) is mapped to a subjectPublicKey (a BIT STRING) as follows: the most significant bit of the OCTET STRING becomes the most significant bit of the BIT STRING, and the least significant bit of the OCTET STRING becomes the least significant bit of the BIT STRING.

csosto-pk commented 1 year ago

Suggestion by @baentsch

may I suggest to (re-)add reference to [SEC1] as well as a sample pub key in section 4 of your draft?

csosto-pk commented 1 year ago

From @baentsch

Should you be looking for a sample pub key, here we go: Dilithium2 with the next available NIST OID "2.16.840.1.101.3.4.3.17" as it's now generated by OpenSSL3+oqsprovider:

-----BEGIN PUBLIC KEY----- MIIFMjALBglghkgBZQMEAxEDggUhAGfo4APVpCWuTTvyoUpSRos6ku+jjqY5QeLz SSERjGF26euQOc4vzl0BtR3IC7cNvFp4oKkplCPWuvHTB3mkW+KOBE+tm4xdxAXG TwNrgCbUZVGfZpcVmNRQpliF1P5hC2s2jUtZvqOI1VMMOwy9S0i4XmgRIQo3MhOX GPeTtAzp1EiyH6LlCVgHZKBLoof5dka5yLMkUidEf7JmsQVsPCd8PpfVOmkMgr0D BY+iUx5xLM5IRw6eVCgZTgx62IRG0Qcu0FlpL0giV/tniV4R9y/4gIQT/ThRy1YU 8KggifXDngNPyxRVd+Z/U81VBxTiSD8syqmn/Jg5QEbhBnV1FERV1kRBstMRNUld pJ6u2j7ru03vnqlf0LhX57RP8gJmTqu2fsvuRCpCVQ/6WG89I3tBGjSrYshJIKLE OtxSQTmKoqyRm8A2T/OGDflyQ9KBJZbdzP7ILJUUBbsS69/3Fd57ke8LIsxkhpNX lXUSFxRQkz91WmE1yaVnawgb3H+pWxUWWlWj5Un95RYpLMeW1EATAXrAIGHHa2wX VHofEMsHiow7PsWFvW6TCOPGeEifJPRFCbcGkiay7PqFW/WPiCqt/jPhf/43/SqB 4Rm+5RdYdp+dRtWFgnw73WRA84eYwr9U692LwEu9J6QKcRXua7zCP/PDbIaDpVij wLW8/Xso9F135VJxR9GHPa/IS1lHBE1NrCxTSOvgqgVKzWYvxYkn/UkGCRzKlDW4 q2r22+4Y5c9j8Pil9tlt/6BMVAai+rpTgbAnU2w81TsFtQMiCHAiKDzz1xow6Aic dbX6+oLLuZrwsgKeXe7XtnhFQJuupgUbBRLTo6tVu/kwdpCwJBH4NtwkTwZUTDy8 NbPVFE7ljZ8J5lcsYCf780Bh4DRkg3Ld5RnrWif4yNGgzzSBKidgAiw1jJgsZaQa ktb4wgGyx4iXw+SqDTewaUO8cPCtgvn5IYJIVFRidNUflpTpETjgQES8z8/VwgQW gu3W639dygg+8D1QOytlI8gDrIOEa3+xQpoSIXAmzOT3y9ipSr57SuphFdHwvaw2 p5w+bMgAdSDk+CBEJPzjkdhp7iGk0i6JHxRbXns4kFJpdnNqZnh7T7fwgmpWaeuv esXOn94Jucda4wSFNHxV/VIth3QtizysyY5gjsOfHTOxI8u4jDGG/m1Ei5oduRfj NFQE+7VR/PisG/YM+rcBuE2uJITB68mRpiHG1lSpDOtOmDjAeIHvjSI7/eFyHU4M DYXQZFoc77CrF/lSRYZPwN5uJAXJB9SiJsYbLNwUAIXlkVDq+p+YEedElR/rnH3V +9Vha0zsLMmQFNrmJpkRedQ2LCSVUx8vuiFSB05a0sb2LmeOIGr4eoE9u6UvLNun U1e8rhX1NZafATIWhqedJQjzSfsGQjkHrQfWRjH1IWdPP9ZJiNP0jSHTsMgnOpnz YPe6ob9fwmCNTrtL79gUEDPe1s05+5JDzmyehMiEnYAm8xYXXFmEmi6dVzIKv5rf 6ENJT90dba3PQM2jyLsqt0ywYzpL9xyg/dwpjhQa9gMm8cdJiJ6JrfdL8h1D1Rzt c/2HHKoBkwssE3P/llbF3qD/j3dB7nM/2UXBZja2jLU6fOGxRnDdresWJK0qEPej ixCjNQfTTCpFNc1/+6LAG6GnvPIUMgrT/Bc2HCW6AY1qWArUOwq2E2PQR3KhJ6rc zXmCrNsf5s5Z2QoiGVuva6OiiVPFMB5TmXnuGU5pLO3FVyvxo9A= -----END PUBLIC KEY-----