If the requirement for AES-256 is to handle the scenario "someone gets a
quantum computer", then in that scenario, there is no realistic DH group size
that is secure.
Hence, I personally see no point in allocating IANA numbers for the larger than
8k MODP groups. The only scenario I can think of where they might be useful
would be one where all of the following apply:
- We believe that there's an adversary that can perform significantly
more than circa 2**128 computations'
- We are not concerned with adversaries with a Quantum Computer
- For some reason, we don't want to use ECDH.
> -----Original Message-----
> From: IPsec <[email protected]> On Behalf Of Tero Kivinen
> Sent: Tuesday, July 17, 2018 11:16 AM
> To: [email protected]
> Subject: [IPsec] Modp-12288 and Modp-16384
>
> When we greated RFC3526 [1] in 2003 we included 1536, 2048, 3072, 4096,
> 6144, and 8192 bit modp groups. I did also create 12288 and
> 16384 bit modp groups [2], but we did not include those as we assumed they
> would be too slow for normal use.
>
> Now sometimes there is requirement to align all security parameters with
> AES-256 also (because AES-128 is not enough if someone gets quantum
> computers some day).
>
> SP800-57 part 1 rev 4 [3] has table 2 that says:
>
> Security Symmetric FCC IFC ECC
> Strength key (e.g. DSA, (e.g., (e.g.,
> algorithms D-H) RSA) ECDSA)
> <=80 2TDEA L=1024, N=160 k=1024 f=160-233
> 112 3TDEA L=2048, N=224 k=2048 f=224-255
> 128 AES-128 L=3072, N=256 k=3072 f=256-383
> 192 AES-192 L=7680, N=384 k=7680 f=384-511
> 256 AES-256 L=15360, N=512 k=15360 f=512+
>
> Meaning that we do not have any MODP groups with IANA numbers that
> would match AES-256. For vendor to add elliptic curve support to simply be
> able to mark that tick mark saying we do support AES-256 is bit much. Adding
> 16384 bit MODP group is much faster and easier, and nobody does not need
> to use it (I think the recommended group in NIST documents is still the 2048
> bit group).
>
> NIST SP 800-56A Rev 3 [4] aligns with this and says that MODP-8192 is for less
> than 200 bits of security, i.e., not enough for AES-256.
>
> In the SP 800-56B rev2 draft [5], there is formula in Appendix D, which allows
> you to calculate the strength for different bit lengths and if you plug in the
> 15360 you get 264 bits. To get 256 bits of maximum strength the nBits needs
> to be between 14446-14993. 15000 would already give you 264, i.e., the same
> than 15360 gives. 15360 is of course 1024*15 so it is nice round number in
> binary.
>
> If you plug in 12288 to that formula you get strength of 240 and 16384 gives
> you 272.
>
> Checking old performance numbers I can see that in 2008 the speed of
> 6144 group was same as 16384 is with current machines, which most likely
> matched what 2048 or 3072 bit group speed was in 2003 (i.e.
> about half a second per full Diffie-Hellman).
>
> So my question is do other people think it would be useful to allocate IANA
> numbers for the 12288 and 16384 bit MODP groups?
>
> You can of course use private numbers, but I myself think it would be good
> idea to have IANA numbers for those groups too, just in case someone
> wants interoperability with them at some point. Also we do not yet know
> how quantum computers are going to do for different algorithms, i.e.,
> whether P-521 is harder or easier than MODP 16384.
>
> [1] https://datatracker.ietf.org/doc/rfc3526/
> [2] https://kivinen.iki.fi/primes/
> [3] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-
> 57pt1r4.pdf
> [4] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-
> 56Ar3.pdf
> [5] https://csrc.nist.gov/CSRC/media/Publications/sp/800-56b/rev-
> 2/draft/documents/sp800-56Br2-draft.pdf
> --
> [email protected]
>
> _______________________________________________
> IPsec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
