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

[Shoko YONEZAWA <[e-mail]>]

Dear John,

Thank you very much for your comments
and I'm sorry to be late for the response.

 > - ”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.

In our draft, we allow the curves with 100 bits of security (e.g. BN256)
only if an application does not require higher security level.
For new applications, we recommend they "SHOULD NOT use" such curves.

The main concern we are worrying about is the case where the curves like 
BN256 have been already deployed and difficult to keep interoperability 
if BN256 is not allowed.
For the next version of our draft, we will describe the use of BN256
like "implementers SHOULD NOT use BN256, but MAY use BN256 only if they 
need to keep interoperability with the old implementations".

 > 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.

Thank you for the reference.
We now understand the needs for 192 bits of security
and will add the curves for this level.

The reason we first omitted 192 bits of security
is that people may use aymmetric crypto with 256 bits of security
rather than 192 bits of security.
According to SSL Pulse Trends, site owners tend to choose
ECDH 521bit (5.29%) rather than ECDH 384bit (4.72%).

https://kjur.github.io/www/sslpulsetrend/index.html#kxecdh

Best regards,
Shoko

On 2019/03/31 6:32, John Mattsson wrote:
> 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
> 
> 
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
> 

-- 
Shoko YONEZAWA
Lepidum Co. Ltd.
[e-mail]
TEL: [phone]