Subject: Re: [lamps] Call for Presentations at the LAMPS Interim Meeting on 28

From: Tadahiko Ito <[email-masked]>
Date: Wed, 13 Jan 2021 19:57:11 +0900

Hi Russ

>> It seems you are talking about PQC signatures in CMS.  PDF signatures
employ an early version on CMS.  Would you be able to make a presentation
at the interim meeting?

Sure.
I would explain CMS part of the PDF signature also. They use CMS with only
one SignatureValue. It is just my opinion, but a separate signature seems
more suitable for PDF signing.

Hi Mike

>> I would support LAMPS looking at this, though it probably needs
involvement from other groups, especially on the security proof side.

Thank you very much.
Proof may not be that difficult for those people, but I believe we should
at least discuss that topic.

Hi Panos

>> For example, you could define a DilithiumIII identifier and a
DilithiumIIIph identifier. The latter can hardcode SHA2-512(M) as the
digest, or SHAKE256(M,64) similar to what RFC8032 does.

I totally agree, but I feel like we should have some consensus on which and
how to use digest function.
(It should be easier for the crypto library to process. I dislike the
situation where each company ends up using different use of hash
algorithms.)

Regards Tadahiko Ito

---

From: Tadahiko Ito <[email-masked]>
Date: Thu, 14 Jan 2021 16:56:01 +0900

Hi Quynh.

>>If we have pre-hash and non-prehash versions, then the asymmetric
operation must be domain-separated between the 2.

>>Otherwise, obtaining a signature from a pre-hash version is an attack on
the non-prehash version.

It is a very good point.

I am not sure about the difficulty of domain-separation, but apart from
that, there would be difficulty here.

>>hash(tr || M) would become hash(0|| tr || M) and hash(1|| tr || M) for
the pre-hash and non-prehash options, for example.

I believe that tr should be secret, so that fix will be inside of
asymmetric function (and inside of the HSM in my case).
I feel like I should not simply introduce a pre-hash.

It also seems it would increase implementation complexity. In addition,
necessity of choosing mode may be confusing.

Regards Tadahiko Ito