Leuke video, grappig dat ze dit met kleuren laten zien!

Voor allen die wat meer over cryptografie willen weten: kijk eens naar CrypTool (gratis), versie 2 is recentelijk uitgekomen (zie https://www.cryptool.org/en/cryptool2-en). Als je in "Startcenter" onder "Templates" naar "Diffie-Hellman" zoekt en dubbel-klikt op het eerste resultaat, krijg je een interactieve omgeving waarin je met de waarden van o.a. P en Q kunt spelen.

Een "enorme" DH sleutel van 256 bits is veel te klein (zie bijv. https://bugzilla.mozilla.org/show_bug.cgi?id=583337#c6 uit 2010).

Tenzij het om een hobbyprojectje gaat met gegevens die gerust op straat mogen belanden: ga niet zelf prutsen met crytografie (bijv. door 64 kleine sleutels i.p.v. 1 grote te gebruiken) maar gebruik een goed geteste library.

Je kunt naar Elliptic Curve DHE kijken, dan kunnen de sleutels aanzienlijk kleiner zijn. De laatste tijd is er behoorlijk wat aandacht voor "curve25519", ontworpen door D.J. Bernstein, zie http://cr.yp.to/ecdh.html. Voor een voorbeeld van het gebruik van curve25519 zie https://github.com/kaepora/miniLock. Nb. ik ben geen cryptograaf (kan je inhoudelijk niet helpen met dit soort algoritmes) maar probeer de ontwikkelingen wel te volgen.

Hou er ook rekening mee dat een Diffie-Hellman key agreement niet voor authenticatie zorgt waardoor man-in-the-middle aanvallen mogelijk zijn zonder dat je dit merkt.

De vraag is wat je precies probeert te bereiken; het is niet gebruikelijk om een publiek toegankelijke webserver te bouwen met een microcontroller. Als jouw doel is om een soort tunnel met "forward secrecy" tussen 2 systemen op te zetten die je beide beheert, zijn ook andere oplossingen denkbaar.

Home grown crypto, the NSA loves it.

Hey Cedric,

Nee, verkleinen van een sleutel is niet veilig. Dit komt omdat minder mogelijkheden zijn die gebruteforced hoeft te worden om je private sleutel te achterhalen.

Aantal elementen die erg belangrijk zijn voor Diffie-Hellman is een lange sleutel van minstens 1024 bit. Dit wordt in practijk gedaan door 2 random priem getallen te genereren van 512 bits in dit geval. Daarmee kan de publieke en private sleutels gegenereerd mee worden. Op het einde moeten deze twee random gegenereerde priem getallen verwijderd worden. Vallen ze bij een aanvaller. Dan kan je de private sleutel achterhaald worden.

Verder heeft Diffie-Hellman ook een ander probleem genaamd "blind signing". Dit zorgd ervoor dat een partij die certificaten moet signeren misleid wordt. Ze kunnen het aangepaste bestand niet uit lezen maar wel signeren. Dit komt omdat het mogelijk is om je bestand te vervagen en nadat het bestand gesigned is weer terug te toveren naar het orginele bestand maar nu die gesigned is. Bij geautomatiseren systemen kan hier dus misbruik van worden gemaakt.

Verder moet het in de toekomst makkelijker worden om Diffie-Hellman probleem op te lossen met quantum computers. Dit geeft de mogelijkheid om sneller achter te komen welke twee priem getallen er gebruikt zijn bij het generen van de sleutels.

Wiki: http://nl.wikipedia.org/wiki/RSA_%28cryptografie%29

CrypTool2 ziet er goed uit. Het maakt het een heel stuk makkelijker om te kijken hoe de algoritmes werken. Ook wel fijn dat het een lijst met algoritmes oplevert. Een puntje van kritiek; je moet je muis boven de groene pijltjes houden om de waarden te zien. Ik snp dat het niet veel toevoegt bij grote getallen, maar bij kleine zou het fijn zijn.

Ik heb in calc eens een aantal waarden van secret (q) langsgelopen met p=17 en g=3. Voor iedere waarde heb ik v=g^q mod p bepaald. Wat me opvalt is dat voor oplopende waarden van secret is dat er een regelmatige reeks voor v ontstaat die iedere 16 secrets herhaald wordt. Dat houdt in dat de aanvaller een tabel kan maken, en beide secrets terug kan zoeken. De lengte van de secrets maakt niet uit, aangezien je daar een mod16 overheen kan leggen. Heb ik nou net het principe van een rainbow table (her)uitgevonden?

Ik vraag me af of dit voor grotere priemgetallen ook klopt. In dat geval heeft een aanvaller alleen een tabel nodig die lineair groeit met de sleutellengte.

Ik probeer te snappen hoe cryptografie werkt, en uiteindelijk wil ik via serial over bluetooth een microcontroller besturen, zonder dat een aanvaller het apparaat over kan nemen. Tegen man in the middle wil ik een soort touch to connect feature maken.

Met vriendelijke groet,
Cedric

Het mooie van zelf verzonnen crypto is dat de NSA, of je nieuwsgierige moeder, speciaal voor jouw algoritme een kraak moet opzetten.
een goed geteste library wordt door de halve wereld gebruikt, waardoor de beloning voor een kraak groter is, en daarmee de kans dat het gebeurt groter. Heartbleed is een voorbeeld.

Tijd om nog even verder te leren, want met een enkele youtube video ben je er niet. Het is namelijk wel handig om zelf te kunnen inschatten welke nummers groot genoeg zijn voor het doel wat je in gedachten hebt.

Laat ik deze MOOC even pluggen: http://crypto-class.org. (Relatie: Heb 'm gedaan.) Let wel: Na deze introductie kun je zoiets een beetje inschatten en heb je je eerste breekoefening geproeft. Crypto zelf klussen komt pas veel later om de hoek kijken en ze vertellen je ook precies waarom.

Ja, en de NSA doet dat in 3 seconden.

Een goed getestte library is a flink getest door de hele crypt-analytische gemeenschap en veilig verklaard, daarna is het jaren en jaren onderzocht en zijn er nog steeds geen zwakheden gevonden.

Als je zelf iets ontwikkeld en test wil dat alleen zeggen dat je 'm zelf niet kan kraken... niet dat iemand anders dat niet kan... En als je de arrogantie hebt om te denken dat je beter bent...

Als ik het goed begrepen heb is de Diffie-Hellman key exchange alleen veilig als het met 2 512 bits getallen wordt gedaan. Er is alleen een probleempje als ik dat in een microcontroller wil gaan doen, ik zou niet weten hoe ik in zo'n klein ding een groot getal tot de macht een ander groot getal moet doen, en daarna over dat resulterende getal een deling.

Zijn er andere manieren om tot een gezamelijk geheim te komen? Ik probeer te voorkomen dat ik een voorgemaakte sleutel in de microcontroller moet zetten.

Zo te zien heeft iemand de NaCl library geport naar de ATmega microcontroller. Eens kijken of daar in zit wat ik nodig heb:
http://cryptojedi.org/papers/avrnacl-20130220.pdf

Met vriendelijke groet,
Cedric

Ik weet even niet waarop en hoe je programmeert, machinetaal, assembler, c, etc, maar als je taal waarin je programeert geen ondersteuning voor big numbers heeft en er is geen library dan zal je het zelf moeten doen. Zoek eens op Arbitrary-precision arithmetic.

Wikipedia: In computer science, arbitrary-precision arithmetic, also called bignum arithmetic, multiple precision arithmetic, or sometimes infinite-precision arithmetic, indicates that calculations are performed on numbers whose digits of precision are limited only by the available memory of the host system.

Hey Cedric

Ik zelf heb al eens een script gemaakt. Hiervoor gebruikte ik liberary gmp (https://gmplib.org/). Met deze liberary kan je heel makkelijk je data encrypten/decrypten. Verder heeft het ook functies om random prime getallen te crearen en weer van de getallen je public en private keys te crearen.

Voorbeeld:

//Generate
do {
do {
generate_random_prime(p, seed, 512);
generate_random_prime(q, seed, 512);
} while(mpz_cmp(p, q) == 0);

totient(p, q, product);
generate_random_prime(e, seed, 1024);
} while(mpz_cmp(product, e) < 0 && mpz_cmp_ui(e, 1) > 0);
mpz_mul(n, p, q);
mpz_invert(d, e, product);

//Copy
mpz_init_set(person->modulus, n);
mpz_init_set(person->public_key, e);
mpz_init_set(person->private_key, d);

//Encrypt Data
mpz_powm(output_data, input_data, person->public_key, person->modulus);

//Decrypt Data
mpz_powm(output_data, input_data, person->private_key, person->modulus);

De NSA doet dat inderdaad in 3 seconden, als ze weten welke crypto is toegepast, en als de data die ze denken te vinden interessant genoeg lijkt. Die 3 seconden volgen dus na een aantal dagen of weken van handmatige analyse. Je data wordt iig niet automatisch ontsleuteld en opgeslagen voor latere analyse. Je moet opvallen om meegenomen te worden.
"de crypt-analytische gemeenschap" heeft jaren lang SSL links laten liggen (heartbleed) en ook truecrypt, ontworpen door een onbekende groep, is pas zeer recent gereviewed. Als je een beetje getalenteerde crypto expert bent, werk je wellicht reeds voor de NSA, of je dat nu wel of niet weet. Blind vertrouwen op de integriteit en dedication van anderen, ja, daarmee kom je er wel in crypto-land.

Het is niet de arrogantie te denken dat je beter bent, maar de hoop dat je niet interessant genoeg bent voor de effort.
2 sloten op je deur: de boef loopt een deurtje verder. 10 sloten op je deur: de boef komt morgen terug met een shovel.

Een hele serie leuke educatieve serie van "Art of the Problem"

Voor een traditionele Diffie-Hellman key exchange heb je minstens 1024 bits sleutels nodig, deze zijn nu al aan de zwakke kant. Beter is een 2048 bits sleutel te gebruiken.

Het opdelen in meerdere kleinere sleutels is geen goed idee, een eventuele aanval kan namelijk ook in stapjes gedaan worden. Dit kan je een beetje vergelijken met een sleutel met een waarde tussen 00 en 99 versus twee sleutels van 0-9. Om 2 sleutels met de waarden 0-9 goed te raden heb ik immers gemiddeld genomen 10 pogingen nodig ( 5 voor de eerste sleutel en 5 voor de tweede sleutel), terwijl ik voor de sleutel met een waarde tussen de 00 en 99 gemiddeld 50 pogingen nodig zal hebben.

Is rekenkracht een probleem, vraag je dan eerst af of je asymmetrische encryptie nodig hebt. Als je de sleutel van te voren uit kunt wisselen kan je je namelijk tot symmetrische encryptie beperken (b.v. 128 bits AES encryptie)

Heb je asymmetrische crypto nodig, overweeg dan ook ECC. De wiskunde ervoor is iets lastiger, maar de benodigde sleutellengtes en rekenkracht zijn kleiner (probeer dit niet zelf te bouwen, zoek een library die je kunt gebruiken)

Ter vergelijking een 128 bits AES key is ongeveer even sterk als een 256 bits ECC key of een 3072 bits RSA key (bron NSA / NIST).

N.B. Als je asymmetrische cryptografie gebruikt en je maakt geen gebruik van een van te voren gepubliceerde publieke sleutel, dan wel certificaten, kan iemand makkelijk tussen de communicatie gaan zitten (een zogenaamde man in the middle attack). Hier helpt kale Diffie-Hellman / ECC niet tegen.

Waarbij wel een kanttekening gemaakt moet worden dat die zwakheden die jij nu aanhaalt (heartbleed, truecrypt) weinig met het cryptogedeelte te maken hadden. Voordat cryptografische algoritmes tot standaard verheven worden ondergaan ze wel degelijk de nodige reviews. En blijft daar ook doorlopend onderzoek naar gedaan worden. Helaas geldt dat inderdaad lang niet altijd voor de implementaties van die algoritmes. Al is de kans dat je het zelf beter kan doen nog altijd wel vrij minimaal waarschijnlijk.

Ja, daar zetten ze dan de beginnend stagair cryptografie op in z'n proefperiode. Dan weten ze meteen of hij geschikt is voor het werk.


Daar zetten ze de wat meer gevorderde cryptograaf op. Hoewel iets als die heartbleed bug eerder door een goede hacker dan door een cryptograaf gevonden zal worden, want dat was gewoon een programmeerfout. Met de gebruikte crypto algorithms was niks mis.

Als je een type microcontroller kiest met voldoende geheugen waarvan het geheugen na het programmeren van buiten af
niet meer is uit te lezen (optie "memory protection aan" o.i.d.) dan lijkt me dat het toch geen probleem hoeft te zijn om een voorgemaakte sleutel in de microcontroller te zetten?

Zoals hierboven ook al aangegeven: nooit doen. Ja, het is makkelijker berekenen, maar nee, de veiligheid neemt enorm af. Het voorbeeld hierboven door jmkf geeft het eigenlijk al aan. Stel ik moet een getal onder de 1000 raden. Met jouw methode moet ik, onafhankelijk van elkaar, 3 getallen raden tussen de 10. Oftewel, het maximale aantal gokken per cijfer is 10, hetgeen een totaal aantal van 10 + 10 + 10 = 30 oplevert, beduidend minder dan het maximale aantal gokken van 1000. Ook met een gemiddelde zit je nog steeds op 15 resp. 500. Jij maakt er 64 lineaire stapjes van, terwijl je er 1 grote exponentiele stap van moet maken. Dat doe je niet door een sleutel op te hakken in kleine stukken, hetgeen altijd een slecht idee is bij cryptografie. Het doet me denken aan de oude kreupele Windows implementatie van password encryptie, waarbij een wachtwoord ook in drie stukken van 7 of 8 karakters werd opgehakt in plaats van te werken met de volledige 21 of 24 karakters. Bekijk liever hoe je op een slimme manier die enorme berekening kunt ophakken in stukjes. Daar zijn stellig algoritmen voor, hoewel het misschien eisen stelt aan de generator van de DH berekening.