Var är 384-bit och 512-bit SSL?

Det enkla svaret är att SHA-256 är nästan lika säkert. Och med nästan lika säkert så menar jag att det handlar om en teoretisk skillnad som har väldigt liten praktisk betydelse. Det har ingen större praktisk betydelse om det tar tre miljarder år eller sex miljarder år att knäcka något.

Exakt hur det skulle påverka bandbreddsanvändning och annan resursanvändning kan jag faktiskt inte uttala mig då jag har dålig koll på implementationen av TSL (som är "det nya" SSL) så det överlåter jag till någon annan. Men en gissning är att dubbel mängd data innebär ungefärligt dubbelt så mycket resursanvändning.

Här har vi en snabb genomgång av SHA vilket kan vara till nytta (notera att det är en översikt av hash-funktioner):
https://www.youtube.com/watch?v=DMtFhACPnTY

Utan att vara någon expert så gissar jag att anledningen är att ja, det skulle bli för ansträngande för både server och klient.

Jag tippar på att både klienter och servrar numera nästan uteslutande använder sig av hårdvaruaccelererad kryptering (AES-NI på AMD/Intel och liknande implementationer på andra plattformar). AES är specat för nyckellängder upp till 256 bitar. NIST får hitta på en ny algoritm eller uppdatera sina specar innan det blir aktuellt med längre nycklar. Sedan måste förstås ny hårdvara utvecklas och bli vanlig på marknaden också.

En testkörning mot SSL Labs visar att nästan alla typer av moderna klienter kommer att välja någon form av AES-kryptering med 128-bitars nyckel och hashning/signering med SHA-256.

TLS 1.3 är den nyaste versionen av TLS, SSL används inte mycket numera eftersom det är osäkert. Det lär dröja innan 1.3 blir vanligt i praktiken. TLS 1.3 specar inga kryptoalgoritmer med längre nominell nyckel än 256 bitar, så ett nytt protokoll är också en förutsättning, men det är nog en mindre viktig faktor än frånvarån av brett stöd för hårdvaruaccelerering av krypton med längre nycklar.

Ovanstående gäller förstås den symmetriska krypteringen av trafik i sessioner. För att ta fram en sessionsnyckel används redan idag (assymetriska) krypton med längre nycklar, men det är inget problem eftersom det bara görs när sessionen ska starta.

@Xerbee: Ah, jo, jag hade redan sett sambandet med 128 + 256 men tycker jag bara inte sett det. Men å andra sidan har jag väl inte tänkt så mycket på att leta heller Men alright, då förstår jag!

SSL ska inte användas sedan juni 2015 (https://tools.ietf.org/html/rfc7568). Man har tryckt pensioneringen av TLS 1.0 och 1.1 framför sig i flera år nu, men nu verkar det äntligen som att de är på väg bort under nästa år (PCI DSS-standarden för kreditkortshantering förbjöd användning av TLS 1.0 i somras och rekommenderar minst TLS 1.2 sedan dess). TLS1.3 har funnits i ett år nu och bör börja tas i bruk på servrar som vill hålla sig i framkant.

Bitantalet du frågar efter bestäms av chiffersviten som används ”ovanpå” TLS-protokollet. Det normala förfarandet är att man använder ett starkt och beräkningsmässigt dyrt chiffer för att komma överens om parametrarna för kommunikationen som sedan sker med ett chiffer som är billigare att beräkna.

Aktuell information och rekommendationer hittar du exempelvis på https://ssllabs.com och https://wiki.mozilla.org/Security/Server_Side_TLS. Har du inte läst den redan är den engelska Wikipediaartikeln om TLS också hyfsat uttömmande.

Det ser väl ganska normalt ut? (Jämför med Mozilla-länken jag postade ovan).

Men:
Tekniskt säger du till din server att den ska erbjuda en lista av chiffersviter, och så ber klienten (om den uppför sig korrekt) om den bästa av dem som den är kapabel att använda. I förlängningen betyder det att en annan användare kan komma att använda ett helt annat (och betydligt mindre säkert) chiffer än vad du själv använder. Ska du göra en meningsfull kontroll av en sites säkerhet behöver du med andra ord fråga servern om alla chiffer den erbjuder och utvärdera dem individuellt.