Profielwerkstuk cryptografie

[Gijs]

Beste tweakers,

Ik ben reeds bezig met mijn profielwerkstuk in 6 vwo. Het onderwerp is cryptografie.
Dit onderwerp is natuurlijk zo breed als de wereld aangezien het overal waar we gaan en staan wordt gebruikt. Ik ben al redelijk ver met mijn onderzoek en de tijdlijn. Nu heb ik echter 2 vragen:

Ik heb in de geschiedenis met vooral uitgewijd over AES, DES, RSA en vervolgens over PGP.
SHA en MD5 zijn onderwerpen die ik nog even moet aansnijden. Ik merk dat er oneindig veel documentatie is en dat je hier je leven aan kan wijden (gelukkig ga ik straks technische wiskunde studeren dus:)). Als ik dit rijtje opnoem, zijn er dan technieken (die ik nu mis)waar ik niet om heen kan, die ik echt op moet nemen in mijn profielwerkstuk?

Een ander ding waarmee ik zit is het volgende: er is natuurlijk altijd een afweging tussen snelheid en veiligheid, overal op de wereld. In de beveiliging van bestanden is het vaak ook erg van toepassing, een nucleaire lanceercode moet vanzelfsprekend beter versleuteld worden dan een ?? (vul zelf in(kan even geen voorbeeld bedenken)) Echter kun je hier heel leuk aan rekenen, ik kan op het moment echter geen goede artikelen vinden die hier mee te maken hebben. Natuurlijk kun je de quote uit Fight Club:
"A new car built by my company leaves somewhere traveling at 60 mph. The rear differential locks up. The car crashes and burns with everyone trapped inside. Now, should we initiate a recall? Take the number of vehicles in the field, A, multiply by the probable rate of failure, B, multiply by the average out-of-court settlement, C. A times B times C equals X. If X is less than the cost of a recall, we don't do one."
prima toepassen. het probleem is echter dat ik de benodigde gegevens (en rekenmethoden) mis om hier een nuttig stuk over te schrijven.

Heeft iemand toevallig op een van mijn 2 vragen antwoord, opmerkingen, aanmerkingen. Schuw niet ze te maken. Ook tips of opmerkingen, die volledig niets te maken hebben met mijn vragen maar wel met het onderwerp en bij kunnen dragen aan het geheel, maak ze!

In ieder alvast bedankt voor het lezen

[NMe]

Je tweede vraag is geen vraag.

Verder zijn er bij encryptie een paar afwegingen wat betreft snelheid die tegen elkaar opwegen. Meestal wil je bij encryptie namelijk juist veel tijd kwijt zijn aan het encrypten. Niet zo zeer omdat je graag staat te wachten, maar omdat 1 seconde nodig hebben om een wachtwoord te encrypten betekent dat een bruteforce-aanval op een willekeurig, volledig alfanumeriek wachtwoord van 8 tekens zonder verdere beveiliging maximaal bijna 90.000 jaar kost. Sommige dingen wil je nog beter beveiligen, andere liever wat minder ten faveure van wat snelheid. Ik geloof niet dat er harde regels of richtlijnen zijn om te bepalen welk niveau van encryptie je moet gebruiken voor welke toepassing, juist omdat er altijd meer toepassingen te verzinnen zijn dan degene die die richtlijnen bedenkt kan verzinnen.

[Arie-]

Mij schiet het onderwerp priemgetallen te binnen, waarom zijn deze belangrijk?

[Rukapul]

MD5 hoort in een museum

Als je iets nieuwers wilt behandelen dan kun je denken aan homomorphic encryption of zero knowledge proofs. Of leg uit waarom Ed25519 zo'n leuke curve is

Overigens is de afweging tussen snelheid en veiligheid nauwelijks meer een issue. Ik ken eigenlijk geen systemen meer waar bewust onveilige oplossingen gekozen worden vanwege een gebrek aan verwerkingssnelheid. Uitzondering is wat legacy meuk die fabrikanten zo lang mogelijk uit proberen te melken.

Wel worden ciphers vervangen door andere omdat ze efficienter zijn, bijvoorbeeld chacha20 ipv AES, of ECC ipv RSA.

In de echt beperkte systemen komt het ook regelmatig voor dat de beperking niet de CPU cycles zijn, maar RAM en flash geheugen.

[Gijs]

NMe schreef op woensdag 05 november 2014 @ 20:36:
Je tweede vraag is geen vraag.

Verder zijn er bij encryptie een paar afwegingen wat betreft snelheid die tegen elkaar opwegen. Meestal wil je bij encryptie namelijk juist veel tijd kwijt zijn aan het encrypten. Niet zo zeer omdat je graag staat te wachten, maar omdat 1 seconde nodig hebben om een wachtwoord te encrypten betekent dat een bruteforce-aanval op een willekeurig, volledig alfanumeriek wachtwoord van 8 tekens zonder verdere beveiliging maximaal bijna 90.000 jaar kost. Sommige dingen wil je nog beter beveiligen, andere liever wat minder ten faveure van wat snelheid. Ik geloof niet dat er harde regels of richtlijnen zijn om te bepalen welk niveau van encryptie je moet gebruiken voor welke toepassing, juist omdat er altijd meer toepassingen te verzinnen zijn dan degene die die richtlijnen bedenkt kan verzinnen.

Ja daar heb je stiekem gelijk, ik denk echter dat het best interresant is. Ik kan er echter niks over vinden, het mag dan misschien waar zijn dat het inderdaad een seconde kost maar we hogen toch de hele tijd de lengte van keys op om de veiligheid te verbeteren. De NSA moest bij DES zelfs de lengte van de code inkorten zodat ze alles makkelijker konden decrypten.

Rukapul schreef op woensdag 05 november 2014 @ 20:46:
MD5 hoort in een museum

Als je iets nieuwers wilt behandelen dan kun je denken aan homomorphic encryption of zero knowledge proofs. Of leg uit waarom Ed25519 zo'n leuke curve is

Overigens is de afweging tussen snelheid en veiligheid nauwelijks meer een issue. Ik ken eigenlijk geen systemen meer waar bewust onveilige oplossingen gekozen worden vanwege een gebrek aan verwerkingssnelheid. Uitzondering is wat legacy meuk die fabrikanten zo lang mogelijk uit proberen te melken.

Wel worden ciphers vervangen door andere omdat ze efficienter zijn, bijvoorbeeld chacha20 ipv AES, of ECC ipv RSA.

In de echt beperkte systemen komt het ook regelmatig voor dat de beperking niet de CPU cycles zijn, maar RAM en flash geheugen.

Thanks voor de tips, en hetzelfde verhaal als hierboven over de veiligheid ten opzichte van veiligheid, het rekenen eraan lijkt me vrij interresant. En MD5 hoort inderdaad in een museum daarom gooi ik hem ook in het geschiedenis stuk.

Arie- schreef op woensdag 05 november 2014 @ 20:45:
Mij schiet het onderwerp priemgetallen te binnen, waarom zijn deze belangrijk?

Thanks, die ga ik uitwerken na de modulo rekenregels!

[deadinspace]

Benoem ook vooral de juiste algemene termen (zoals symmetrische cryptografie, asymmetrische cryptografie, hashing, web of trust) en leg uit waarom die dingen zo heten.

Concepten die je ook goed uit kunt leggen als inleiding zijn identification, authentication, authenticity, en secrecy (ik weet de nederlandse termen niet goed).

NMe schreef op woensdag 05 november 2014 @ 20:36:
Verder zijn er bij encryptie een paar afwegingen wat betreft snelheid die tegen elkaar opwegen. Meestal wil je bij encryptie namelijk juist veel tijd kwijt zijn aan het encrypten. Niet zo zeer omdat je graag staat te wachten, maar omdat 1 seconde nodig hebben om een wachtwoord te encrypten...

Nou haal je encryptie en wachtwoord-hashing door elkaar, en dat zijn echt twee hele verschillende dingen.

Van encryptie wil je juist dat het zo snel mogelijk is (zodat de drempel om het toe te passen laag is). Ook hashing in de algemene zin wil je zo snel mogelijk hebben.

Wachtwoord-hashing is een hele specifieke toepassing, en een van de weinige waarbij je wil dat iets niet te snel is.

betekent dat een bruteforce-aanval op een willekeurig, volledig alfanumeriek wachtwoord van 8 tekens zonder verdere beveiliging maximaal bijna 90.000 jaar kost.

7 miljoen. Vergeet de hoofdletters niet

Rukapul schreef op woensdag 05 november 2014 @ 20:46:
Overigens is de afweging tussen snelheid en veiligheid nauwelijks meer een issue. Ik ken eigenlijk geen systemen meer waar bewust onveilige oplossingen gekozen worden vanwege een gebrek aan verwerkingssnelheid.

Nouja, waarom zijn RSA keys voor https bijna altijd 1024 of 2048 bits dan, en niet 4096 of zelfs meer?

[The Eagle]

Wellicht ook een stukje wijden aan waar men het nu al, mogelijk ongemerkt, in de praktijk tegenkomt. Mooie eyeopener voor mensen en tevens een pakkend eerste stuk in je werkstuk

[Rukapul]

deadinspace schreef op woensdag 05 november 2014 @ 21:41:
Nouja, waarom zijn RSA keys voor https bijna altijd 1024 of 2048 bits dan, en niet 4096 of zelfs meer?

1024 omdat beheerders clueless keys en certificaten genereren
2048 omdat het een redelijke key lengte is
4096 of meer niet omdat het niet nodig is voor de betreffende applicatie. Het draagt dan dus niet/nauwelijks bij aan effectieve veiligheid.

Ik kwam van de week nog een klein embedded apparaat tegen wat niet alleen TLS1.0 bleek te ondersteunen, maar inclusief 2048bit RSA slechts 900ms nodig had voor de hele handshake

[Arie-]

Belangrijkste is dat je wiskunde laat zien! Ik heb op de middelbare school ooit een stuk over kortste pad algoritmen geschreven en daarbij uitgelegd wat de verschillende algoritmen zijn en hoe ze werken met mooie plaatjes erbij. Ik was alleen vergeten de raakvlakken met wiskunde goed uit te werken. Hierbij kun je denken aan complexiteit van algoritmen en bewijzen waarom iets daadwerkelijk het kortste pad is. Hetzelfde zal ook voor jou gelden, alle algoritmen zijn leuk, maar wat heeft de wiskunde er mee te maken, bijvoorbeeld de priemgetallen die ik eerder noemde.

Edit: Ik denk dat je docent het ook mooier vind (maar dat moet je zelf overleggen) als je twee algoritmen vergelijkt en probeert te begrijpen, dan dat je 10 algoritmen noemt zonder dat je daar dan echt wat van leert.

[Voor 16% gewijzigd door Arie- op 06-11-2014 09:32]

[NMe]

deadinspace schreef op woensdag 05 november 2014 @ 21:41:
Nou haal je encryptie en wachtwoord-hashing door elkaar, en dat zijn echt twee hele verschillende dingen.

Van encryptie wil je juist dat het zo snel mogelijk is (zodat de drempel om het toe te passen laag is). Ook hashing in de algemene zin wil je zo snel mogelijk hebben.

Wachtwoord-hashing is een hele specifieke toepassing, en een van de weinige waarbij je wil dat iets niet te snel is.

"Meestal" was inderdaad wat ongelukkig gekozen. Maar het toont wel aan dat er nogal wat verschillende smaakjes zijn. Soms wil je juist dat encryptie lang duurt. Andere keren wil je het snel hebben. Weer andere keren maakt het niet veel uit, maar zoek je juist specifiek extra veiligheid en mag het dus lang duren. Mijn punt dat het dus niet in generieke regels te omvatten valt wanneer je welke afweging maakt blijft wat dat betreft dus staan.

7 miljoen. Vergeet de hoofdletters niet

Vergeten is een groot woord.

[farlane]

Rukapul schreef op woensdag 05 november 2014 @ 21:49:
Ik kwam van de week nog een klein embedded apparaat tegen wat niet alleen TLS1.0 bleek te ondersteunen, maar inclusief 2048bit RSA slechts 900ms nodig had voor de hele handshake

Er zijn steeds meer embedded controllers die voor encryptie hardwarematige ondersteuning hebben, met het hele IoT gebeuren en all.

[bwerg]

Rukapul schreef op woensdag 05 november 2014 @ 20:46:
Als je iets nieuwers wilt behandelen dan kun je denken aan homomorphic encryption of zero knowledge proofs. Of leg uit waarom Ed25519 zo'n leuke curve is

Naast zero knowledge proofs zijn ook concepten als Shamir's secret sharing interessant. Dat geeft wel aan wat er met wiskundige cryptografie mogelijk is, en hoe dat veel uitgebreider en mooier werkt dan de 'security-technieken' in de oude, anologe wereld waar we nog in blijven hangen. Vergelijk bijvoorbeeld een digitale handtekening met een schriftelijke: die laatste wordt gewoon op brieven uitgeprint, wat is hier de meerwaarde nou eigenlijk van? Krijg je een PGP-signed mail, dan zegt dit veel meer.