On Tue, Aug 16, 2022 at 08:29:53AM -0700, [email protected] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the CBOR Object Signing and Encryption WG of the 
> IETF.
> 
>         Title           : JOSE and COSE Encoding for Post-Quantum Signatures
>         Authors         : Michael Prorock
>                           Orie Steele
>                           Rafael Misoczki
>                           Michael Osborne
>                           Christine Cloostermans
>   Filename        : draft-ietf-cose-post-quantum-signatures-00.txt
>   Pages           : 36
>   Date            : 2022-08-16
> 
> Abstract:
>    This document describes JSON and CBOR serializations for several post
>    quantum cryptography (PQC) based suites including CRYSTALS Dilithium,
>    Falcon, and SPHINCS+.
> 

Trying to review this:

- Dilithium (v3.1) keys are abstract signature keys. They are _not_ LWE
  keys. And if one wants dedicated key type for implementations to
  dispatch on, the name should refer to Dilithium, not to "LWE".

- I can't make heads or tails of the use of the "pset" parameter. "alg"
  already fully specifies the variant, there is nothing further to
  specify.

- The pset talks about alg "CRYDI", but the above table gives exhaustive
  list of valid algorithms that does not include "CRYDI".

- The COSE key type is listed as PQK. Either that should be something
  generic for abstract signature key, or something specific for
  Dilithium if implementers want to dispatch on that.

- The way message is hashed inside Dilithium resembles the way the
  RSA-PSS submission did message hashing. However, RSA-PSS changed the
  message hashing for the final version. If similar change happens in
  final version of Dilithium, that has extremely nasty effect on the
  way Dilithium is integrated into COSE and JOSE (basically meaning
  everything has to be redone).

- The Dilithium team does not recommend using Dilithium the way it is
  used in the draft (they recommend hybridization).

- I do not think Dilithium should be used at all at this point. Use
  either ECC and SPHINCS+ depending on how difficult updating to PQC
  later is.


- Falcon (v1.2) keys are abstract signature keys. They are _not_ NTRU
  keys. And if one wants dedicated kty for dispatch, that should refer
  to Falcon, not to "NTRU".

- Again, there is the "pset" parameter I can not make heads or tails
  about. After alg there is nothing further to specify.

- The pset talks about alg "FALCON", which is not in exhaustive table of
  algorithms.

- FALCON also uses hashing that resembles RSA-PSS submission. If that
  gets changed similarly to RSA-PSS in the final version, the
  consequences are similar as in Dilithium case.

- The COSE key type is also "NTRU", which differs from Dilithium. Either
  it should be generic type, or some type referencing FALCON.

- Even if there are no obvious recommendations from FALCON team about
  its use, I think using it unhybrized at this point is bad idea.

- The comment about should not use Dilithium also appiles to FALCON.
  (Basically, use ECC or SPHINCS+).

- The reason both Dilithium and FALCON were selected for standardization
  is that the smaller size of FALCON comes at very high cost: FALCON
  requires double-precision floating-point hardware to run decently,
  something many constrained systems lack. It is also much much harder
  to implement than Dilithium. Worse, any implementation errors likely
  lead to private key being leaked.


- SPHINCS+ keys are abstract signature keys. They are not any kind of
  "hash-based signature" keys. Any dedicated type should refer to
  SPHINCS+, not to "HASH".

- What hash function is used? SPHINCS+ specifies SHA-2, SHAKE and
  one other fly-by-night hash. The choices are all incompatible with
  one another.

- Again, there is the "pset" parameter I can not make heads or tails
  about. After alg there is nothing further to specify.

- Text talks about alg "HAS", but the above exhaustive table does not
  list that.

- The COSE key type is also "HASH", which differs from Dilithium. Either
  it should be generic type, or some type referencing SPHINCS+.



- What is KeyValidate?

- The security considerations mentions Dilithium, but does not even
  mention the extreme care required in implementing FALCON.

- What "nonces" is section 7.3 talking about? 




-Ilari

_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose

Reply via email to