TL;DR: tenzij er dringende redenen zijn om het niet te doen: gebruik voortaan DH sleutels van (minimaal) 3072 bits op TLS servers, en genereer asymmetrische sleutels van 3072 bits voor gebruik in certificaten. Disclaimer: deze nieuwe "best current practice" biedt geen enkele zekerheid zodra quantum computers hun belofte waarmaken.

Cisco NGE
in http://blogs.cisco.com/security/cisco-next-generation-encryption-and-postquantum-cryptography las ik dat Cisco eerder deze maand haar "NGE" (Next Generation Encryption) pagina heeft bijgewerkt: http://www.cisco.com/web/about/security/intelligence/nextgen_crypto.html.

Post-Quantum Cryptografie
In de Cisco NGE pagina is ook te zien welke cryptografische algoritmes bestand zijn tegen toekomstige aanvallen met quantum-computers. Nb. op dit moment vormen quantum-computers, voor zover bekend, nog geen realistisch gevaar voor welk cryptografisch algoritme dan ook (zie bijv. deze reactie van Peter Gutmann: http://www.metzdowd.com/pipermail/cryptography/2015-September/026375.html).

Nu is het ook niet zo dat je hier in alle gevallen je schouders over moet ophalen: als het gaat om informatie die je nu versleutelt en/of digitaal ondertekent, en die over langere tijd (zeg 10 jaar of langer) nog steeds ontoegankelijk moet zijn voor mensen zonder sleutel en/of de digitale handtekening nog steeds betrouwbaar geauthenticeerd moet kunnen worden, is het verstandig om de risico's zo goed mogelijk in te schatten (daar zou een kristallen bol wel eens bij van pas kunnen komen). Het gaat daarbij niet alleen om de gevaren van sneller toegenomen (specifieke) rekenkracht dan verwacht, maar zeker ook om gebreken in algoritmes en onjuiste implementaties.

Minimale sleutellengtes
Opvallend in de Cisco NGE pagina vind ik Appendix A "Minimum Cryptography Recommendations" (http://www.cisco.com/web/about/security/intelligence/nextgen_crypto.html#16), waarin ik voor het eerst zie dat voor asymmetrische cryptografie (RSA, Diffie-Hellman) sleutellengtes van 3072 bits (i.p.v. de nu gangbare 2048 bits) worden aangeraden, zonder dat ik daar een onderbouwing voor kan vinden. Sterker, in "Table 1. Recommendations for Cryptographic Algorithms" wordt het gebruik van zowel 2048 als 3072 sleutels "acceptable" genoemd, en dat is in strijd met Appendix A.

Mogelijke onderbouwing voor 3072 ipv 2048
In de NGE pagina verwijst Cisco o.a. naar NIST SP 800-131. Echter, in de laatste draft van SP 800-131 A (http://csrc.nist.gov/publications/drafts/800-131A/sp800-131a_r1_draft.pdf) zie ik zo snel geen getallen groter dan 2048.

En dat is merkwaardig, want reeds in http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf van juli 2012 wordt de sterkte van een asymmetrische sleutel ("gewoon", d.w.z. niet ECC = Elliptic Curve Cryptografie) van 2048 bits gelijkgesteld met een symmetrische sleutel van 112 bits (zoals toegepast bij 3DES; o.a. omdat we symmetrische sleutels van minstens 128 bits willen zou 3DES niet meer moeten worden toegepast, maar wordt vaak nog wel ondersteund voor legacy toepassingen waaronder stokoude webbrowsers). En 3072 bits asymmetrisch (non-ECC) wordt gelijkgesteld aan 128 bits symmetrisch (bijv. AES-128).

Van het laatstgenoemde document (SP800-57 part 1) is in september 2015 een nieuwe draft verschenen (http://csrc.nist.gov/publications/drafts/800-57/sp800-57p1r4_draft.pdf). Zo te zien is er, sinds de vorige draft, niets gewijzigd in "Table 2: Comparable strengths" van symmetrische versus asymmetrische algoritmes (de laatste 3 jaar lijkt hier dus niets in te zijn veranderd, ook niet door een mogelijk toegenomen dreiging van quantum computing).

Conclusie
Ik vermoed dat Cisco in Appendix A van haar NGE uitgaat van een equivalente sterkte van minimaal 128 bits symmetrisch, en dus 3072 bits asymmetrisch (non-ECC). Ik ben het met Cisco eens dat het verstandig is om dit vanaf nu in de praktijk de standaard te maken.

Nb. het nut van een certificaat met een 3072 bits RSA sleutel is beperkt indien dat certificaat is ondertekend (door een CSP = Certificate Service Provider) met een kleinere sleutel. Daarentegen, grotere DH sleutels bieden wel meteen een onvoorwaardelijk betere bescherming. Aangezien authenticatie (certificaat - meestal met RSA sleutel), in het geval van https, alleen van belang is bij het opzetten van de verbinding, en DH de vertouwelijkheid vaak gedurende een lange periode moet kunnen beschermen (denk aan aanvallers die versleutelde sessies opslaan en na enkele jaren proberen te decrypten), is mijn advies te beginnen met 3072 bit DH sleutels (als je nog 2048 of kleiner gebruikt) en pas daarna te focussen op langere sleutels voor certificaten.