Plug-in moet versleuteling in de browser vergemakkelijken

Ontwikkelaar Nadim Kobeissi zal deze maand een plug-in introduceren die het versleutelen en ontsleutelen van bestanden sterk zou vereenvoudigen. De tool, miniLock geheten, slaat geen sleutels op en vereist ook geen accounts.

MiniLock maakt gebruik van public key-encryptie waarbij de gebruiker een privésleutel heeft om data te versleutelen en weer leesbaar te maken. In tegenstelling tot tools als PGP is het niet nodig om de publieke sleutels op te slaan: miniLock kan dankzij elliptic curve cryptography de privésleutel genereren op basis van de gekozen passphrase. Hierdoor moet de plug-in door iedereen op elke computer bruikbaar worden en vereist het weinig computerkennis, zo stelt de ontwikkelaar tegenover Wired.

De plug-in stelt wel eisen aan de passphrase: er dienen minimaal dertig tekens te worden gebruikt. Tevens zijn cijfers en symbolen vereist. De afgeleide privésleutel wordt gewist zodra de browser wordt afgesloten. Bovendien is er geen account nodig en in tegenstelling tot de lange publieke sleutels van PGP is de lengte van de publieke sleutel die miniLock hanteert slechts 44 tekens.

Volgens Wired zal Kobeissi een bètaversie van de plug-in deze maand tijdens een hackersconferentie publiek maken. De code wordt opensource en zal op GitHub zijn te vinden. Kobeissi maakte eerder het chatprogramma Cryptocat dat ook leunde op versleuteling. Daar bleken aanvankelijk de nodige beveiligingsgaten in te zitten, maar in latere versies zou Cryptocat veilig zijn geworden.

Reacties (50)

Ben heel benieuwd naar de mening van cryptografen over de gebruikte techniek.

Nu ben ik geen crypto specialist, maar ik snap er wel het e.e.a. van.

Het genereren van RSA sleutels leunt zwaar op de kunst van het genereren van een echt random string. Daarvoor wordt dus gebruik gemaakt van een randomizer.
Het voordeel daarvan is dat je dus nooit dezelfde sleutel zal genereren.

In dit geval is de random input vervangen door user input wat dan altijd dezelfde sleutels op moet leveren. Als de sleutel gelijk is, dan kan de data ook ontsleuteld worden. De input die minimaal verwacht wordt is 30 tekens. Mensen zijn niet goed in het verzinnen van echt random strings dus ik zie daar een potentieel lek in verband met hergebruik van strings.

Verder is het gebruik van ECC veel minder belastend voor de systemen. ECC maakt gebruik van veel kortere sleutels wat de versleuteling alleen maar minder traag maakt. (ik durf hier nog niet sneller te zeggen)
Wat ik echter niet begrijp is dat het artikel schrijft dat er een asymmetrisch algoritme wordt gebruikt voor het versleutelen van de data. Dat wordt over het algemeen gedaan middels een symmetrische sleutel. Dat is vele malen sneller. Ik verwacht dus dat dit nog steeds het geval is, en dat de symmetrische sleutel (de Data Encryption Key, DEK) wordt versleuteld met de asymmetrische sleutel (Key Encryption Key, KEK). De versleutelde DEK kan als meta-informatie aan de data worden gekoppeld en is weer toegankelijk na invoeren van de juiste input (wachtwoord)

Mmmmm een randomizer zal zeker wel dezelfde sleutel genereren. Hij kan zelfs 100 identieke sleutels na elkaar maken. De kans is klein, bijzonder klein maar random geeft geen enkele garantie dat alle sleutels uniek zijn.

Zo kan een darter ook 1000 keer exact dezelfde plek raken. De kans is klein, maar hij kan het wel..
Het hele idee van een randomizer is natuurlijk het genereren van echt unieke strings. Dat dit lastig is om echt altijd uniek te zijn doet daar niet aan af.

Zal wel een combi zijn van random en de systeemkloktijd en datum.

Dat is dus niet random ;-)

Misschien kun je een stream van random bits maken door de minimale ruis op de line-in van je geluidskaart softwarematig te versterken. Voor de zekerheid kan je de output nog mixen met de echte random-generator en andere variabele waarden zoals de klok.

Als je al de output van een 'echte' random generator hebt dan ben je klaar. Waarom zou je dat noch gaan mixen met aller lij andere (non random) dingen. Dat lijk wel erg veel op proberen een ketting te versterken door zwakke schakels toe te voegen.

Geen idee eigenlijk maar het lijkt mij dat een random reeks getallen te allen tijde random blijft ongeacht welke bewerkingen je er later nog op doet. Om te voorkomen dat uit die ruis nog bepaalde informatie gehaald kan worden zoals wanneer je wasmachine aan staat kan je het nog verder vertroebelen. Er is misschien een soort 'fingerprint' van de omgeving uit af te leiden en dat willen we natuurlijk niet.

Nochtans geeft (een random reeks getallen) * 0 altijd hetzelfde resultaat

Als je dan nog bezig bent met delingen en afrondingen kan je op een gegeven moment dezelfde resulatten bekomen bij verschillende random getallen.

Als het dus al echt random is, niet meer aankomen

Dat klopt maar dan ben je gewoon de hoeveelheid informatie die die random reeks bevat aan het verkleinen met een functie. Je kan alles wat je met een dobbelsteen gooit met 0 vermenigvuldigen of delen door zichzelf oid maar dan levert die dobbelsteen welke in de praktijk een perfecte random-generator is geen variabele informatie meer op.

Ik stel voor: je haalt een byte uit de ruis en een uit /dev/random. Deze 'rits' je samen tot een 16 bits getal. Je kan daarbij nog varieren in met welke byte je begint door dat bijv. af te laten hangen de van een AND/OR/XOR op die twee keer 8 bits. Zo blijft de hoeveelheid informatie hetzelfde maar knappe jongen die achterhaalt wat gebeurd is lijkt mij.

Ik stel voor: je haalt een byte uit de ruis en een uit /dev/random. Deze 'rits' je samen tot een 16 bits getal. Je kan daarbij nog varieren in met welke byte je begint door dat bijv. af te laten hangen de van een AND/OR/XOR op die twee keer 8 bits. Zo blijft de hoeveelheid informatie hetzelfde maar knappe jongen die achterhaalt wat gebeurd is lijkt mij.

Dat maakt voor de randomness niet uit, en dat is nu net het punt van kenhas en BlackOwl. Het vermenigvuldigen met nul is een wat cryptisch voorbeeld, maar het punt daarvan is dat je door het toevoegen van nodeloos complexe berekeningen het risico loopt om het werkelijk willekeurige gedeelte van je getal door middel van een door jezelf slecht begrepen bewerking teniet te doen.

Verder is het gebruik van een bron van werkelijk willekeurige getallen is om te beschermen tegen een gecompromitteerde PRNG. Als een aanvaller weet wat er uit de PRNG komt rollen is het voor hem of haar niet moeilijker geworden om het uiteindelijke resultaat te ontdekken als jij een getal uit die PRNG combineert met een werkelijk willekeurig getal.

Nu zal je wellicht opmerken (en in zekere zin terecht) dat het er ook niet makkelijker van is geworden, maar je hebt het programma wel complexer gemaakt dan voorheen zonder enig voordeel te behalen. Met die extra complexiteit loop je weer extra risico op bugs.

Ik hoop dus dat je snapt dat het uiteindelijk ongunstig is om dergelijke bewerkingen te doen.

Omdat de ruis op je lijn in werkelijk random is (kan zijn) in tegensteling tot je random generator die slechts een algoritme doorloopt om een waarde te genereren.
Blorf neemt aan dat de ruis op je Lijn In dezelfde is als die op je oude TV waar de antennekabel uit it; Kosmische achtergrondruis, en die is werkelijk random.

Ik vind het een goed idee eigenlijk. Is deze ruis zo te versterken dat dit meetbaar wordt?

Slecht geïsoleerde/geaarde moederborden geven tonnen opneembaar ruis.
vooral goedkopere laptops hebben hier heel merkbaar last van.

Versterken heeft ook geen zin, want de versterking kan enkel meetbare verschillen versterken.
Als het verschil te klein is om meetbaar te zijn, kan de versterking niet magisch de resolutie verhogen.
IPV versterken heb je betere meet aparatuur nodig

Slecht geïsoleerde/geaarde moederborden geven tonnen opneembaar ruis.
vooral goedkopere laptops hebben hier heel merkbaar last van.

Als je goed luistert merk je dat het helemaal geen ruis is maar series pulsen en toontjes. Slechte entropiebron lijkt mij.

Versterken heeft ook geen zin, want de versterking kan enkel meetbare verschillen versterken.
Als het verschil te klein is om meetbaar te zijn, kan de versterking niet magisch de resolutie verhogen.
IPV versterken heb je betere meet aparatuur nodig

Versterken heeft inderdaad geen zin, je haalt uit de sample alleen de bits die van belang zijn, dus de laagste bits.
Wat wel gewoon werkt is hetgeen je naar de line in gooit te versterken (zonder dat je er een signaal op hebt staan). Zo sample je gewoon meer bits aan ruis.
Maar goed, die ruis moet dus nog wel van enige kwaliteit zijn.

Deng! :-)

Misschien kun je een stream van random bits maken door de minimale ruis op de line-in van je geluidskaart softwarematig te versterken.

Grote kans dat dit helemaal niet zo random is.
Je kan dan beter tape-ruis samplen, of een ongetunede radio.

[Reactie gewijzigd door koelpasta op 6 juli 2014 22:33]

Stop 50 rode en 50 blauwe knikkers in een pot schut en haal ze er 1 voor 1 blind uit.

Er is een kans dat je 100x achter elkaar hetzelfde patroon uit de pot trekt.

De enige mogelijkheid om er voor te zorgen dat ze allemaal uniek zijn is kijken of je het patroon al hebt getrokken en net zo lang knikkers terug stoppen en opnieuw trekken tot hij wel uniek is.

Maar het is in dit geval veel meer van belang dat er een kans bestaat dat hij uniek is dan dat hij werkelijk uniek is.

Een wachtwoord wordt onveiliger wanneer je verplicht een leesteken toevoegt ipv de mogelijkheid geeft een leesteken toe te voegen en veel gebruikers van de mogelijkheid gebruik maken.

Het gaat om de kans dat en niet de verplichting tot, in beide gevallen.

Reactie Bruce Schneier mbt elliptic curve cryptology op 6-11-2013:

"Did we have any insight from the Snowden papers if the NSA has identified any vulnerabilities in this?"

We do not -- at least not yet -- but I strongly believe that the NSA has a significant advantage in breaking ECC. This doesn't mean it's bad, but I think we need to 1) make sure we know where our curves come from, and 2) build in a hefty security margin.

(schneier.com)

Meer informatie over ECC, zie: arstechnica.com, 24-10-2013

[Reactie gewijzigd door hieper op 4 juli 2014 10:37]

Er is niks mis met ECC zelf. Het probleem zit hem in het feit dat de NSA backdoors had ingebouwd in de ECC RNG die gestandaardiseerd werd door NIST. En waarschijnlijk zijn sommige standaard curves ook met de hulp van de NSA ontstaan.

Waar ik moeite heb is de volgende zin: [...] kan dankzij elliptic curve cryptography de privésleutel genereren op basis van de gekozen passphrase. ECC genereert niks, daar is het niet bedoeld voor. ECC wordt hier gebruikt voor de distributie van (waarschijnlijk) de symmetric key. Hoe de privé sleutel wordt gegenereerd is mij niet helemaal duidelijk.

[Reactie gewijzigd door Safaci op 4 juli 2014 10:51]

Cryptico genereert RSA key pairs op basis van een passphrase. Wat ze daar doen is gewoon de passphrase hashen en dat als seed van de PRNG gebruiken (zie code). Dat zou voor het genereren van een ECC key pair natuurlijk net zo goed werken.

Ik ben heel benieuwd hoe 'veilig' deze plug-in is. Zitten er veel bugs in; Wat voor data wordt er verzameld. Het feit dat de plugin gratis is zegt vaak ook genoeg.

Linux is ook in de meeste distributies gratis. Gratis wil niet (altijd) zeggen dat het niet veilig of goed getest is.

Als je Wilt weten welke data word verzameld, bekijk de broncode! Het word Open source!

De passphrase is dus de privesleutel. Tamelijk lastig als die sleutel ergens een keer onderschept is. Er is dan geen andere optie dan op een compleet nieuwe sleutelpaar over te stappen.

De passphrase is dus de privesleutel.

Nee, de geheime sleutel wordt gegenereerd met een passphrase. Een subtiel verschil. 'Gelijk aan' is namelijk anders dan 'afgeleid van'.

Tamelijk lastig als die sleutel ergens een keer onderschept is.

Dat is altijd zo met geheime sleutels.

[Reactie gewijzigd door The Zep Man op 4 juli 2014 10:42]

De passphrase is gewoon te onderscheppen door een onveilige browser of besturingssysteem. Kan gewoon via malware of het wordt zo geleverd door de leverancier met hun gratis software.
Veilige communicatie is niet mogelijk met eenzijdige encryptiemethoden.

Klopt, maar dat probleem is per definitie niet op te lossen; als je OS malware bevat, dan is elk proces dat erop draait ook niet meer te vertrouwen. Of dat een browser plugin is of een standalone-draaiende PGP maakt niet uit

Wat bedoel je met "eenzijdige" encryptie?

Met eenzijdige encryptie bedoel ik een enkele private sleutel voor encrypten en decrypten, wat hier volgens mij het geval is. De kreet heb ik inderdaad wat onzorgvuldig gekozen.

Ehm... wat stel jij dan voor als alternatief?

Een andere privé-sleutel gebruiken voor encrypten en decrypten!?

Of wil je twee sleutels na elkaar gebruiken (het versleutelde bericht, met een andere key, nogmaals versleutelen)? Dat is zinloos; als de ene laag te kraken is, dan is de andere dat ook.

Nee, hij bedoelt gewoon symmetric key encryption.

Die sleutel gaat dan ook maar 1 browser sessie mee.

Gemak en het niet nodig hebben van computerkennis zijn wat dit betreft wel twee afzonderlijke zaken. Bovendien is het volgens mij niet nodig om korte publieke sleutels te hebben (want die stuur je toch mee) - lijkt mij dus niet echt geschikt voor serieus gevoelige informatie. Maar goed, eerst zien.

Waarvoor is dit bruikbaar? Afgezien van die chat app?

Overal waar jij data versleuteld wilt versturen en daarbij ook nog wilt kunnen bewijzen dat het van jou komt. Het grote voordeel hiervan is dat je niet bijvoorbeeld een USB-stick met je privesleutel hoeft mee te nemen maar elk systeem die de plugin heeft kunt gebruiken.

Dit zou bijvoorbeeld ook kunnen worden gebruikt in GMail om PGP eenvoudig mogelijk te maken. Dan kan javascript client-side de versleuteling doen zonder dat ooit de passphrase verstuurd hoeft te worden.

Het probleem met de Public Key Infrastructure is dat je nooit 100% kunt bewijzen dat de persoon die achter een public key zit ook echt de juiste persoon is. Het is, bijv. zoals bij PGP, gebaseerd op een Web Of Trust. Bij PGP kon je andermans keys signen om aan te geven dat de key aan de juiste persoon is gekoppeld. Ben eerlijk gezegd benieuwd hoe dit hier is opgelost. [Wired + documentatie maar raadplegen.]

Ik verwacht dat je op deze manier een bestand versleuteld kunt versturen via mail (vanuit webmail) of uploaden naar een cloud dienst.
Als je zelf het bestand weer wilt openen, dan moet je het juiste wachtwoord weer opgeven. Wil je een ander het laten openen zal je via een ander kanaal (telefoon, sms, whatsapp) de code door moeten geven.

Je vraagt wat het nut is van het encrypten van gegevens?

Een eenvoudige(re) en gebruiksvriendelijkere manier voor encrypten is alsnog beter dan helemaal niet encrypten. Ik zal het niet veel gebruiken, maar toch wel eens.

Bovendien is er geen account nodig en in tegenstelling tot de lange publieke sleutels van PGP is de lengte van de publieke sleutel die miniLock hanteert slechts 44 tekens.

Is dit niet een vorm van bedrog?
Zoals ik het zie wordt er uit die set van 44 tekens altijd slechts een beperkte subset gekozen omdat het afgeleidt wordt van een passphrase.
Daarmee wordt volgens mij de uiteindelijke set van mogelijke combinaties van die 44 tekens ernstig beperkt.
En ik denk dus dat je helemaal niet mag kijken naar de lengte van de publieke sleutel om de veiligheid te bepalen.

Nee, de publieke sleutel wordt gegenereerd aan de hand van de private sleutel, die op zijn beurt weer gebaseerd is op (een hash van de) passphrase.

Ja, maar de hoeveelheid combinaties binnen de private key wordt beperkt door de kleine subset van combinaties in de passphrase.
De private key moet opnieuw kunnen worden gegenereerd uit de passphrase. Daarmee zijn die twee, als je het generatiealgoritme kent, eigenlijk equivalent qua entropie.
Ik zou dus zeggen dat je niet veiliger bent dan de lengte van de passphrase en dat de uitspraak over '44 tekens voor de key' helemaal niks zegt.
Of zie ik dit verkeerd?

Je hebt gelijk als je zegt dat de uitspraak over 44 tekens niets zegt over de veiligheid. Daar staat tegenover dat die opmerking ook helemaal niets over de veiligheid tracht te zeggen. Het was een opmerking over gebruiksgemak, omdat de publieke sleutels van PGP veel langer zijn. Om een voorbeeld te stellen: deze sleutel past in een tweet, een PGP sleutel niet.

Wat ik nu denk dat je bedoelt, is dat het uiteindelijke aantal mogelijke sleutels beperkt is door het aantal mogelijke passphrases en dat is in principe natuurlijk waar. Maar dat is enkel relevant als je de boel wilt kraken door te bruteforcen en als je dat doet staat de sterkte van de encryptie sowieso buitenspel.

Je kunt de encryptiemethode niet beoordelen op het feit dat je het kunt bruteforcen, want dat kan met iedere methode.

"Maar dat is enkel relevant als je de boel wilt kraken door te bruteforcen en als je dat doet staat de sterkte van de encryptie sowieso buitenspel. "

Niet als je die lange keys gebruikt die dit product probeert te omzeilen.

"Je kunt de encryptiemethode niet beoordelen op het feit dat je het kunt bruteforcen, want dat kan met iedere methode. "

Je hebt gelijk, maar er is (volgens mij) wel een veband tussen moeilijkheid van brute forcen en de hoeveelheid te proberen combinaties en geldt dit voor alle goede encryptiealgoritmes. Door het gebruiken van een passphrase als key zou je een brute force aanval direct op een heel kleine subset van keys voor het achterliggend algoritme kunnen richten. Het maakt het dus een heel stuk onveiliger.
Het enige dat minder tekens zou goedpraten is als de encryptie veel beter is dan andere methodes, maar daar wordt nergens over gesproken.
Verder wordt, volgens het artiekel van wired, die gast afgebrand om zn eerdere cryptografische werk. Het zou zo lek zijn als een mandje.

"Maar dat is enkel relevant als je de boel wilt kraken door te bruteforcen en als je dat doet staat de sterkte van de encryptie sowieso buitenspel. "

Niet als je die lange keys gebruikt die dit product probeert te omzeilen.

Alleen als je ook langere passphrases gebruikt natuurlijk, de passphrase is nog altijd te bruteforcen.

"Je kunt de encryptiemethode niet beoordelen op het feit dat je het kunt bruteforcen, want dat kan met iedere methode. "

Je hebt gelijk, maar er is (volgens mij) wel een veband tussen moeilijkheid van brute forcen en de hoeveelheid te proberen combinaties en geldt dit voor alle goede encryptiealgoritmes. Door het gebruiken van een passphrase als key zou je een brute force aanval direct op een heel kleine subset van keys voor het achterliggend algoritme kunnen richten. Het maakt het dus een heel stuk onveiliger.

Je hebt het nu opeens over het gebruiken van een passphrase als key, waar komt dat vandaan? Want dat is niet eens mogelijk, en hier ook zeker niet het geval.

Verder is er uiteraard een verband tussen de tijd die nodig is om te bruteforcen en de lengte van de key, maar met 44 tekens is de key helemaal zo kort nog niet hoor. Dat is gewoon 44*8 bits (even uitgaande van het gebruik van ascii).

Het enige dat minder tekens zou goedpraten is als de encryptie veel beter is dan andere methodes, maar daar wordt nergens over gesproken.
Verder wordt, volgens het artiekel van wired, die gast afgebrand om zn eerdere cryptografische werk. Het zou zo lek zijn als een mandje.

Nouja, een steeds maar langere key is leuk maar op een gegeven moment ook nutteloos. Als je op een gegeven moment duizenden jaren nodig hebt om de boel te ontcijferen kun je daar wel miljoenen van maken, maar wat schiet je daar precies mee op?

En ik wil verder ook niet zeggen dat ik weet of de cipher in kwestie wel sterk is, alleen dat je ook niet mag concluderen dat de cipher niet sterk is omdat de public key 44 tekens lang is.

Je hebt het nu opeens over het gebruiken van een passphrase als key, waar komt dat vandaan? Want dat is niet eens mogelijk, en hier ook zeker niet het geval.

Ik bedoelde het niet letterlijk als de key van het achterliggend encryptiealgoritme. Ik noemde het gemakshalve alleen zo omdat het punt was dat de lengte van de passphrase veel invloed heeft op de te behalen entropie in de set van keys.
Minder tekens in een passphrase betekent een kleinere set mogelijke keys.
En voor brute forcen IS de passphrase eigenlijk de key, inzover je toch blind alle combinaties af moet gaan. Heb je de passphrase gevonden dan heb je toegang tot de key.

Verder is er uiteraard een verband tussen de tijd die nodig is om te bruteforcen en de lengte van de key, maar met 44 tekens is de key helemaal zo kort nog niet hoor. Dat is gewoon 44*8 bits (even uitgaande van het gebruik van ascii).

Het is een passphrase dus ik neem aan dat het een subset van de ascii characters is (ascii is overigens 7 bits en niet 8 )
Dat betekent dat er ongeveer 5.5 bits aan entropie per teken in die passphrase zit.
Dit komt ongeveer uit op zo rond de 256 bits aan entropie voor de hele passphrase.

Verder is het natuurlijk niet praktisch om ook werkelijk een passphrase van precies 44 tekens te onthouden dus wordt dat in de praktijk wat minder.
Ook zullen mensen niet gauw random tekens gebruiken voor zo'n lange passphrase en zullen dus bestaande woorden gebruiken. Dat neemt weer een zooi entropie af van de passphrase en maakt het geschikter voor dictionary attacks.

"Nouja, een steeds maar langere key is leuk maar op een gegeven moment ook nutteloos. Als je op een gegeven moment duizenden jaren nodig hebt om de boel te ontcijferen kun je daar wel miljoenen van maken, maar wat schiet je daar precies mee op?

Het gaat hier om een key die in feite korter wordt (minder bits aan entropie gaat bevatten). Ik vraag me af hoe ze dat kunnen verantwoorden.

[Reactie gewijzigd door koelpasta op 6 juli 2014 22:12]

Ik bedoelde het niet letterlijk als de key van het achterliggend encryptiealgoritme. Ik noemde het gemakshalve alleen zo omdat het punt was dat de lengte van de passphrase veel invloed heeft op de te behalen entropie in de set van keys.
Minder tekens in een passphrase betekent een kleinere set mogelijke keys.
En voor brute forcen IS de passphrase eigenlijk de key, inzover je toch blind alle combinaties af moet gaan. Heb je de passphrase gevonden dan heb je toegang tot de key.

Dat is bij encryptie altijd zo en staat los van de lengte van de keys. Je kunt wel een key van 2048-bits hebben maar als je gekozen passphrase "aap" is dan ben je inderdaad de lul. Dat staat echt compleet los van de lengte van de key.

Daarnaast zorg je ervoor dat het genereren van de private key gewoon veel moeite kost, dat doe je namelijk helemaal niet vaak. Dan duurt dat 100ms en dan is het toch opeens een onpraktische aanval geworden (omdat simpelweg alle mogelijke keys generen dan toch nog sneller is).

Verder is het natuurlijk niet praktisch om ook werkelijk een passphrase van precies 44 tekens te onthouden dus wordt dat in de praktijk wat minder.
Ook zullen mensen niet gauw random tekens gebruiken voor zo'n lange passphrase en zullen dus bestaande woorden gebruiken. Dat neemt weer een zooi entropie af van de passphrase en maakt het geschikter voor dictionary attacks.

Je haalt weer de key en de passphrase door elkaar. De public key is 44 tekens lang, de passphrase moet minimaal 30 tekens lang zijn en is hoogstwaarschijnlijk niet gelimiteerd tot ASCII.

Het gaat hier om een key die in feite korter wordt (minder bits aan entropie gaat bevatten). Ik vraag me af hoe ze dat kunnen verantwoorden.

Korter dan wat? Ieder systeem wat werkt op basis van een zelfgekozen wachtwoord heeft volgens jou redenering dezelfde entropie.

Dat is bij encryptie altijd zo en staat los van de lengte van de keys. Je kunt wel een key van 2048-bits hebben maar als je gekozen passphrase "aap" is dan ben je inderdaad de lul. Dat staat echt compleet los van de lengte van de key.

Nee, het is gerelateerd aan de totale lengte van de mogelijke combinaties van tekens.
Als dat woord 'aap' 1 mogelijkheid is uit een hele grote set passphrases dan is het alsnog veilig.

En het staat niet los van de key want als je de passphrase kent heb je de beschikking over de juiste key. De passphrase is gewoon een index naar een subset van keys. Dat betekent dat het grootste deel van de keys bewijsbaar niet gebruikt kan worden en dat je die dus niet hoeft te brute forcen. Heel sterke relatie dit.

Je haalt weer de key en de passphrase door elkaar. De public key is 44 tekens lang, de passphrase moet minimaal 30 tekens lang zijn en is hoogstwaarschijnlijk niet gelimiteerd tot ASCII.

Oeps, dat las ik inderdaad verkeerd. Maar het is dus nog veel dramatischer dan ik dacht.
Ik denk dat die 44 tekens lange key inderdaad 8 bits gecodeert is dan en dat de 30 tekens lange passphrase een subset is van leesbare ascii tekens. De entropie die overblijft in de 44 tekens van de key is dus best wel klein.

Ieder systeem wat werkt op basis van een zelfgekozen wachtwoord heeft volgens jou redenering dezelfde entropie.

Als de maximale lengte gelijk blijft en de tekens random worden gekozen dan blijft de entropie gelijk, ja.
Entropie in deze is niks anders dan de hoeveelheid mogelijke combinaties uitgedrukt in bits. In dit geval bepaalt de lengte en inhoud van de passphrase de hoeveelheid mogelijk te genereren keys.
De set van mogelijk te genereren keys kan niet groter zijn dan de mogelijke combinaties die je met de 30 tekens lange passphrase (die dus maar ong. 5 bits aan entropie bevat per teken) kunt indexeren.
Als de passphrase slechts 128 bits aan entropie (mogelijke combinaties) bevat dan hoef je in de key set ook maar 2^128 combinaties af te gaan. Afhankelijk van het encryptiealgoritme kan dat veel of weinig werk zijn, maar met brute forcen betekent elke bit extra een verdubbeling (?) van de hoeveelheid werk dat je moet doen om het antwoord te vinden.

Korter dan wat?

Dan de keyset grootte van andere gangbare encryptiealgoritmes.
Deze kerel heeft ofwel een compleet nieuw en superveilig algoritme bedacht (zo lijkt het te worden gebracht maar ik geloof er niks van) OF hij brengt een product uit dat pretendeerd veilig te zijn en dat in de praktijk makkelijk te kraken zal zijn.

[...]

Nee, het is gerelateerd aan de totale lengte van de mogelijke combinaties van tekens.
Als dat woord 'aap' 1 mogelijkheid is uit een hele grote set passphrases dan is het alsnog veilig.

Nouja, wat is dan het probleem volgens jou? De gekozen passphrase kan in dit geval zo lang zijn als de gebruiker zelf wil.

En het staat niet los van de key want als je de passphrase kent heb je de beschikking over de juiste key. De passphrase is gewoon een index naar een subset van keys. Dat betekent dat het grootste deel van de keys bewijsbaar niet gebruikt kan worden en dat je die dus niet hoeft te brute forcen. Heel sterke relatie dit.

Er is geen limiet op de lengte van de te kiezen passphrase. Er zijn veel meer mogelijke passphrases dan mogelijke keys.

[...]

Oeps, dat las ik inderdaad verkeerd. Maar het is dus nog veel dramatischer dan ik dacht.
Ik denk dat die 44 tekens lange key inderdaad 8 bits gecodeert is dan en dat de 30 tekens lange passphrase een subset is van leesbare ascii tekens. De entropie die overblijft in de 44 tekens van de key is dus best wel klein.

Dat valt op zich wel mee, althans, voor zover we nu weten. De keys PGP zijn meestal RSA keys, die moeten lang zijn omdat ze anders snel te kraken zijn (een gemiddelde PC heeft enkele minuten nodig om van een 256-bit public PGP key de private key te vinden). Deze plug-in gaat ECC (ellyptic curve cryptography) toepassen en daar is, voor zover we weten, geen snelle oplossing voor.

[...]

Als de maximale lengte gelijk blijft en de tekens random worden gekozen dan blijft de entropie gelijk, ja.
Entropie in deze is niks anders dan de hoeveelheid mogelijke combinaties uitgedrukt in bits. In dit geval bepaalt de lengte en inhoud van de passphrase de hoeveelheid mogelijk te genereren keys.

De set van mogelijk te genereren keys kan niet groter zijn dan de mogelijke combinaties die je met de 30 tekens lange passphrase (die dus maar ong. 5 bits aan entropie bevat per teken) kunt indexeren.

De 30 tekens is een minimum, de passphrase is niet de limiterende factor hier.

Als de passphrase slechts 128 bits aan entropie (mogelijke combinaties) bevat dan hoef je in de key set ook maar 2^128 combinaties af te gaan. Afhankelijk van het encryptiealgoritme kan dat veel of weinig werk zijn, maar met brute forcen betekent elke bit extra een verdubbeling (?) van de hoeveelheid werk dat je moet doen om het antwoord te vinden.

Nouja, buiten het feit dat dat hier dus niet van toepassing is, wil het zeggen dat je dan hooguit 2^128 keypairs hoeft te genereren. Zoals ik al zei: Dat geef je een hoge computational cost, en dan is de 2^128 opeens meer dan genoeg omdat dat alsnog een paar quadriljoen jaar kost om te genereren.

[...]

Dan de keyset grootte van andere gangbare encryptiealgoritmes.
Deze kerel heeft ofwel een compleet nieuw en superveilig algoritme bedacht (zo lijkt het te worden gebracht maar ik geloof er niks van) OF hij brengt een product uit dat pretendeerd veilig te zijn en dat in de praktijk makkelijk te kraken zal zijn.

Dat is het verschil tussen RSA en ECC. Voor ECC is nog geen makkelijke oplossing gevonden, dus kunnen de sleutels daarvoor korter zijn.

Nouja, wat is dan het probleem volgens jou? De gekozen passphrase kan in dit geval zo lang zijn als de gebruiker zelf wil.

Grr.. note to self: bril poetsen DAN lezen.
Ik las over het woord minimaal heen. Dacht dat die 30 tekens het maximum was.

Dat geef je een hoge computational cost, en dan is de 2^128 opeens meer dan genoeg omdat dat alsnog een paar quadriljoen jaar kost om te genereren.

Dat neem ik dan maar aan ;P

Ik hou maar op want ik heb het blijkbaar gewoon niet goed gelezen.