Hi, my concern is that these MODP groups will have public keys of 1.5-2 Kb in size, so it can make using them problematic in real world due to fragmentation issues...
Regards, Valery. > 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
