Skip to content

Please document the rationale for choosing N = 16 #5

@starius

Description

@starius

Hi, I have a question about the choice of N = 16 in the SHRINCS parameters.

In the code this appears as N = 16, and in the spec it looks like the same parameter is written as n = 16 bytes, while R_SIZE = 32 bytes. The paper also seems to target a 128-bit security level and uses SHA-256 truncated to that size for many internal hash computations.

I am not saying this is wrong, but I would appreciate a clearer justification for this parameter choice in the spec or README.

In particular, could you clarify:

  • What exact security target is intended for N = 16 in the post-quantum setting?
  • Why was N = 16 preferred over something more conservative like N = 24 or N = 32?
  • Is there a reason PRF_msg / R stays at 32 bytes while the main internal hash output is 16 bytes?
  • Is there still a benefit of using exactly SHA-256 given its output is truncated? Could it just use a 16 bytes hash function then?

What prompted the question is that the generic motivation for hash-based signatures often says Grover is mitigated by doubling output lengths, but the concrete SHRINCS instantiation uses N = 16, which is a half of what Bitcoin is using now with SHA-256.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions