Toon posts:

Profielwerkstuk cryptografie

Pagina: 1
Acties:

  • Gijs
  • Registratie: Juli 2013
  • Laatst online: 31-01 16:15
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 :P

  • NMe
  • Registratie: Februari 2004
  • Laatst online: 06-01 18:18

NMe

Quia Ego Sic Dico.

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.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.


  • Arie-
  • Registratie: December 2008
  • Niet online
Mij schiet het onderwerp priemgetallen te binnen, waarom zijn deze belangrijk?

  • Rukapul
  • Registratie: Februari 2000
  • Laatst online: 10:07
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 :P

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
  • Registratie: Juli 2013
  • Laatst online: 31-01 16:15
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 :P

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
  • Registratie: Juni 2001
  • Laatst online: 28-01 17:52

deadinspace

The what goes where now?

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
  • Registratie: Januari 2002
  • Laatst online: 31-01 22:04

The Eagle

I wear my sunglasses at night

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 :)

Al is het nieuws nog zo slecht, het wordt leuker als je het op zijn Brabants zegt :)


  • Rukapul
  • Registratie: Februari 2000
  • Laatst online: 10:07
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 :P

  • Arie-
  • Registratie: December 2008
  • Niet online
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
  • Registratie: Februari 2004
  • Laatst online: 06-01 18:18

NMe

Quia Ego Sic Dico.

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. :+

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.


  • farlane
  • Registratie: Maart 2000
  • Laatst online: 09:57
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 :P
Er zijn steeds meer embedded controllers die voor encryptie hardwarematige ondersteuning hebben, met het hele IoT gebeuren en all.

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.


  • bwerg
  • Registratie: Januari 2009
  • Niet online

bwerg

Internettrol

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 :P
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.

Heeft geen speciale krachten en is daar erg boos over.

Pagina: 1


Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee