Re: [Cfrg] Fwd: I-D Action: draft-yonezawa-pairing-friendly-curves-01.txt

[John Mattsson <[e-mail]>]

Very well-written draft for only being in version -01

A few comments.

- ”MAY use BN256.”

I don’t know how practical/unpractical the exTNFS algorithm is in terms of memory etc. but as you write below “100 bits of security is no longer secure” (which I assume refers to curves like BN256) it seems like the recommendation should at least be SHOULD NOT. 

- “For security, we introduce 100 bits, 128 bits and 256 bits of
security.  We note that 100 bits of security is no longer secure and
recommend 128 bits and 256 bits of security for secure applications.
We follow TLS 1.3 [34] which specifies the cipher suites with 128
bits and 256 bits of security as mandatory-to-implement for the
choice of the security level.”

My understanding and experience is that a 192-bit security level is more common for asymmetric crypto than a 256-bit level. As an example, the US CNSA suite for protection of up to TOP SECRET information, uses P-384 for ECDHE and ECDSA. I don’t think anybody needs more than that in practice. Many TLS libraries did not even support P-521 until recently. For AES-192 and AES-256 the performance penalty is small, but for asymmetric crypto the performance difference between 192 and 256 bit security is often quite large. I would recommend that the draft follows TLS 1.3 and specifies curves with 128, 192, and 256 bits of security. If I had to choose two, 128 and 192 would be the most important.

“Hence, we consider BLS48 for 256 bits of security.”

I think it is better if you just wrote the estimated security level… ( ≈ 581 / 2 / 1.33 = 218 ? )

Cheers,
John