Hi. Since my message got lost in the overtime, I’ll say it again here.
AFAIK there is very little usage of anything beyond 4096-bit groups. I don't sense a need for 16K. Engineering should be about creating what people need (or at least want). I haven’t heard anyone say they would like to use 16384-bit DH groups or RSA keys. If they want more “bits” then 2048, they usually go to ECDSA/ECDHE or the CFRG curves. I don’t feel strongly about this as in “oh my god, this is horrible for the Internet”, but I think this is something we should not do. Yoav > On 17 Jul 2018, at 18:15, Tero Kivinen <[email protected]> wrote: > > 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
