Security Professionals
- ipfw add deny all from eindgebruikers to any
Comments op PKI Certs en Public Key FAQ
19-08-2012, 13:57 door Erik van Straten, 6 reacties
Correcties en aanvullingen op, en meningen over, mijn "PKI Certs en Public Key FAQ" [1] zie ik graag hieronder! Redenen:
- Dan kan ik, indien nodig, de FAQ zelf met meerdere bijdragen uitbreiden zonder dat er reacties tussendoor staan;
- Jouw reactie "verzuipt" niet doordat deze helemaal ergens onderaan bungelt;
- De verwijzing naar mijn [i]FAQ zelf[/i] (op de security.nl rechtsbovenaan de main page onder "Forum Headlines") mag best snel wegzakken uit de belangstelling, het is een naslagwerk waar anderen en ikzelf naar kunnen verwijzen indien nodig.
Alternatief: mijn voorkeur heeft het niet, maar desgewenst kun je natuurlijk ook een geheel nieuwe thread (of een eigen FAQ ;) beginnen!
[1] via http:
[url]http://www.security.nl/artikel/42740/1/PKI_Certs_en_Public_Key_FAQ.html[/url]
via https:
[url]https://secure.security.nl/artikel/42740/1/PKI_Certs_en_Public_Key_FAQ.html[/url]
Reacties (6)
20-08-2012, 08:32 door
[Account Verwijderd]
[Verwijderd]
21-08-2012, 00:36 door
Erik van Straten
Door Hugo:
Eens! Gecorrigeerd.Q01: Decryptie: ontsleutelen (ook wel decoderen of uitpakken genoemd)
Niet juist. Voor versleuteling/ontsleuteling is een sleutel nodig. Voor coderen/decoderen niet. Dit laatste doe je met bijvoorbeeld Base64.Q06: Public key encryptie is volledig op asymmetrische encryptie gebaseerd
Vergeet hashing niet voor het maken van de handtekening. Daarbij wordt in de praktijk de assymetrische cryptografie voor verbindingen slechts gebruikt om een symmetrische sleutel uit te wisselen. De rest van de verbinding verloopt dus via symmetrische cryptografie. Ja, je kan betwisten of dat dan nog onderdeel is van de PKI.Als je de public key van de webserver hebt -en vertrouwt dat die bij een specifieke FQDN hoort- zie ik geen fundamentele reden waarom je niet uitsluitend met asymmetrische crypto, gevolgd door symmetrische crypto (RC4, AES, etc.) een met SSL/TLS vergelijkbare verbinding zou kunnen maken. Maar toegegeven, certificaten zijn een stuk praktischer dan kale public keys...
Q07: Een digitale handtekening zetten heeft alleen zin als de bezitter van de private key dit doet
Of door een signing server voor het 'vastleggen' van een timestamp.- De Signer is McAfee, Inc.
- De CounterSigner is Symantec Time Stamping Services Signer - G3
Beide conculega's zijn toch "bezitter" van een private key gebruikt voor signing purposes? Het enig verschil is dat McAfee een executable voorziet van een handtekening, en Symantec de handtekening van McAfee + timestamp ondertekent? D.w.z. als ik me niet vergis werkt dit zo, van timestamping ken ik nog niet alle details, maar dat beïnvloedt m.i. mijn stelling niet. Toch?
Q08: Het is fundamenteel onmogelijk om met 100% zekerheid vast te stellen dat een public key "van iemand" of "van iets" is
Dat kan wel, maar dat betekent dat twee mensen elkaar moeten ontmoeten om sleutels uit te wisselen.- Stel Erik van Straten uit http://nl-nl.facebook.com/erik.v.straten geeft zijn public key aan jou, dan zou dat best wel eens echt zijn public key kunnen zijn. Echter, ik heb geen facebook account...
- Maar stel dat je mij van gezicht kent (of imitators met wat PKI vragen+antwoorden kunt ontmaskeren;). Als mijn PC gecompromitteerd is tijdens het genereren van "mijn" keypair, zou het best kunnen dat ik jou (onbedoeld) een public key van een aanvaller geef, en niet die van mijzelf...
Desalniettemin ben ik heel blij met jouw comments, dank voor het lezen en reageren!
21-08-2012, 01:48 door
Erik van Straten
In http://www.security.nl/artikel/42740/1/PKI_Certs_en_Public_Key_FAQ.html schreef Anoniem op 2012-08-18 om 22:54:
Dank je wel! meestal van de RSA methode gebruik gemaakt. In dat geval is de exponent vaak 65537 (2^16 + 1, oftewel hexadecimaal 10001), en de modulus vanzelfsprekend een "willekeurig" en hopelijk uniek getal met meestal een lengte van 1024 of, voor nieuwe sleutels, 2048 bits.
Een goede actie om dit te schrijven. Ik vrees voor je dat het weinig helpt en dat mensen hier evenzeer hun onkunde zullen blijven etaleren, maar het is een goede poging.Klein beetje commentaar op bovenstaande formulering : Het woord 'willekeurig' suggereert dat een RSA modules een 'random' getal is. Dat is zeker niet het geval;
Het is een getal wat het product is van twee priemgetallen van ongeveer gelijke grootte.
Die priemgetallen horen inderdaad willekeurig gegenereerd te zijn , maar noch de losse priemgetallen, noch hun product zijn een 'willekeurig' getal in de normale (cq wiskundige) betekenis van het woord.
Je hebt helemaal gelijk. Maar ik probeer deze FAQ zo eenvoudig te houden dat beweerders niet afhaken op (voor hen) onnodige complexiteit. Ingewikkelde FAQ's zijn er al genoeg.Het is een getal wat het product is van twee priemgetallen van ongeveer gelijke grootte.
Die priemgetallen horen inderdaad willekeurig gegenereerd te zijn , maar noch de losse priemgetallen, noch hun product zijn een 'willekeurig' getal in de normale (cq wiskundige) betekenis van het woord.
Van primair belang is dat niemand anders ooit een keypair gegenereert dat dezelfde (identieke) public key oplevert als de public key die jij al gebruikt. Hoewel ik regelmatig lees dat de kans hierop ondenkbaar klein is, wijst onderzoek anders uit, zie bijv. https://factorable.net/. In dat onderzoek wordt overigens wel benadrukt dat public keys niet identiek hoeven te zijn om toch risicovol te kunnen zijn, nl. als er gemeenschappelijke factoren bestaan tussen twee public keys. Maar dat is weer erg lastig uit te leggen aan "wiskunde-haters".
Een "goede" random number generator is in elk geval essentieel. Vorige week heeft Dan Kaminsky nog een oude vraag opnieuw "in de groep gegooid", nl. in hoeverre je van clock drift als random source gebruik zou kunnen maken (zie http://dankaminsky.com/2012/08/15/dakarand/). Maar hoe je als beheerder kunt vaststellen of OpenSSL onder Debian en een smartcard voldoende randomness produceren, lees je daar niet, en zou ik je ook niet kunnen vertellen...
Ik zou formuleren : De modulus is het product van twee willekeurig gekozen priemgetallen van 512 of 1024 bit. De modulus is dan 1024 bit (bij priemgetallen van 512 bit). Tegenwoordig kiest men meestal voor moduli van 2048 bit, waarvoor de priemgetallen dus elk 1024 bit lang zijn.
De exponent en de modulus vormen samen het publieke deel van een RSA sleutel.
Ook hier heb je gelijk , maar met getallen goochelen helpt niet.De exponent en de modulus vormen samen het publieke deel van een RSA sleutel.
Een beheerder van een webserver die een sleutelpaar moet genereren moet alleenl weten dat hij, in het geval van RSA, tegenwoordig een (modulus-) lengte van 2048 bits moet aanhouden. Welke (astronomisch grote) priemgetallen daaraan ten grondslag liggen is voor de meeste mensen abacadabra, en het risico bestaat dat ze de lengte van de priemgetallen en de modulus door elkaar gaan halen.
En de beschikbare infromatie is al verwarrend genoeg. Na veel zeuren (zie bijv. http://bugs.debian.org/487152 uit 2008) is, als ik me niet vergis, afgelopen juni eindelijk default_bits in openssl.cnf verhoogd van 1024 naar 2048.
Hoewel de screenshot niet meer klopt, gaan de instructies in http://certificaat.kpn.com/pkioverheidcertificaten/servercertificaat/csr-genereren/apache/ sindsien wellicht toch weer goed. Maar http://certificaat.kpn.com/pkioverheidcertificaten/servercertificaat/csr-genereren/microsoft-iis-6-0/ zou wel moeten worden geüpdate, hierin staat: "The recommended bit length is 1024. Click Next". Wat is nou weer "bit length"? Wat gebeurt er als ik 1357 invoer?
Kortom, je hebt inhoudelijk gelijk. Bij de eerstvolgende review zal ik kijken of ik waht extra links naar meer gedetailleerde beschrijvingen kan toevoegen - voor de mensen die het naadje van de kous willen weten. Het hoeft geen boek te worden waar alle details over cryptografie in staan!
21-08-2012, 02:24 door
Erik van Straten
Door Anoniem:
Het is misschien niet helemaal duidelijk, maar een lengte van "bijvoorbeeld 16 bits" is niet serieus als cryptografische hash, en zelfs als simpele error checksum aan de korte kant.
Ik kan niet terugvinden dat ik ergens 16 bits noem in het kader van cryptografische hashes, mocht dat er tussen het editten door gestaan hebben, dan was dat zeker niet mijn bedoeling.Door Erik van Straten: (Q10) Wat is een hash, en wat is een cryptografische hash?
[..]
Ook hier heb ik een paar opmerkingen :[..]
Het is misschien niet helemaal duidelijk, maar een lengte van "bijvoorbeeld 16 bits" is niet serieus als cryptografische hash, en zelfs als simpele error checksum aan de korte kant.
Voor error-checking is 16 bits toegegeven erg weinig, maar het wordt (vandaag de dag!) wel gebruikt. Bijv. in via VHF verzonden AIS berichten (zie http://en.wikipedia.org/wiki/Automatic_Identification_System als je niet weet wat AIS is; http://www.itu.int/rec/R-REC-M.1371-4-201004-I/en beschrijft de bijbehorende maritieme berichtenstandaard). Daarbij zou wel eens ongeveer 1 op de 65536 beschadigde ontvangen berichten toch een goede checksum kunnen hebben...
De eigenschappen die je noemt voor een cryptografische hash zijn niet compleet.
Dat de hash een vaste output lengte heeft is heel erg normaal, absoluut ook voor error detectie hashes zonder cryptografische ambitie. In bijna alle soorten gebruik ligt de beschikbare ruimte voor de checksum vast (disk blocks, communicatie protocol, ip/tcp headers, format van bv zip archieven).
Ook een input van onbeperkte lengte is geen eis die speciaal voor cryptografische hashes.
Principieel heb je gelijk, maar ik schrijf deze FAQ niet voor Bruce Schneier of Peter Gutmann! Dat geldt ook voor het volgende:Dat de hash een vaste output lengte heeft is heel erg normaal, absoluut ook voor error detectie hashes zonder cryptografische ambitie. In bijna alle soorten gebruik ligt de beschikbare ruimte voor de checksum vast (disk blocks, communicatie protocol, ip/tcp headers, format van bv zip archieven).
Ook een input van onbeperkte lengte is geen eis die speciaal voor cryptografische hashes.
Wat _wel_ bijzondere eisen zijn, zijn de volgende :
1st pre-image resistant : het is "moeilijk" om een input te vinden met een gegeven hash-waarde als uitkomst.
2nd pre-image resistant : het is "moeilijk" om gegeven een input en hash waarde, een andere input te vinden met dezelfde uitkomst
en collision resistant : het is "moeilijk" om twee inputs te vinden met dezelfde hash waarde als uitkomst.
MD5 is gebroken mbt tot collision resistance, en dat is genoeg om te diskwalificeren als cryptografische hash, maar er is geen 1st of 2nd pre-image attack tegen MD5 bekend.
Met alle respect, ik weet dat zulke gedetallieerde verschillen bestaan, maar kan ze zelf niet onthouden... Dit is voer voor cryptografen, niet voor een simpele FAQ. Uit jouw opmerkingen maak ik wel op dat ik de doelgroep bovenaan de FAQ moet verduidelijken!1st pre-image resistant : het is "moeilijk" om een input te vinden met een gegeven hash-waarde als uitkomst.
2nd pre-image resistant : het is "moeilijk" om gegeven een input en hash waarde, een andere input te vinden met dezelfde uitkomst
en collision resistant : het is "moeilijk" om twee inputs te vinden met dezelfde hash waarde als uitkomst.
MD5 is gebroken mbt tot collision resistance, en dat is genoeg om te diskwalificeren als cryptografische hash, maar er is geen 1st of 2nd pre-image attack tegen MD5 bekend.
26-08-2012, 15:02 door
Overcome
Een goed idee om dit te schrijven, al was het maar om veel informatie samen te pakken op 1 pagina. Ik ben benieuwd naar het vervolg. Hieronder mijn op- en aanmerkingen. Wellicht heb je er wat aan.
(Q00) "FAQ (Frequently Asked Questions)". Afkortingen zoals FAQ "uitschrijven" bij het eerste gebruik van de afkorting. Dat gebruik vindt iets eerder plaats.
(Q01) De definitie van CA en CSP is recursief. De ene verwijst naar de andere en vice versa. Beter is het om de definitie van ISO 21188:2006 ("Public key infrastructure for financial services - Practices and policy framework") te gebruiken:
certification authority - CA - entity trusted by one or more entities to create, assign and revoke or hold public key certificates
(Q01) Hoewel er tientallen definities zijn die niet zijn opgenomen in deze FAQ, is het verschil tussen een CA en een RA wellicht iets om te benadrukken. Bij iedere klant waar ik kom kan een auditpunt worden gedefinieerd voor interne PKI's dat de RA rol niet is ingevuld. Wederom de definitie van ISO 21188:2006:
registration authority - RA - entity that is responsible for identification and authentication of subjects of certificates, but is not a CA (3.18), and hence does not sign or issue certificates. NOTE An RA may assist in the certificate application process or revocation process or both. The RA does not need to be a separate body, but can be part of the CA.
(Q01) Je geeft wel de definitie van cryptografie (the art of making things), maar niet van cryptoanalyse (the art of breaking things). Beide maken deel uit van de overkoepelende cryptologie. http://nl.wikipedia.org/wiki/Cryptografie geeft de Griekse woorden waar cryptologie van is afgeleid.
(Q01) Key: sleutel. Ik denk dat veel mensen zover nog wel waren gekomen :). Het is een vertaling, vergelijkbaar met enkele van bovenstaande en onderstaande "definities". Het is geen uitleg van een woord, zoals je wel bij "Algoritme" doet. De vraag is of je termen globaal wilt uitleggen, of dat je alleen een vertaling wilt geven, iets wat voor de leek nog steeds onduidelijk zal zijn.
(Q01) Non-repudiation: het is handiger om de definitie onder het kopje "Non-repudiation in digital security" op de Wikipedia te gebruiken. De Wikipedia pagina geeft ook expliciet aan: "Regarding digital security, the cryptological meaning and application of non-repudiation shifts to mean:". Kortom, non-repudiation in cryptografie betekent iets anders.
(Q01) PKI. Wellicht ook hier handig om wat meer achtergrondinformatie te geven. Om de ISO norm wederom te citeren:
public key infrastructure - PKI - structure of hardware, software, people, processes and policies that employs digital signature technology to facilitate a verifiable association between the public component of an asymmetric public key pair with a specific subscriber that possesses the corresponding private key. NOTE The public key may be provided for digital signature verification, authentication of the subject in communication dialogues, and/or for message encryption key exchange or negotiation.
(Q06) "Public key encryptie is volledig op asymmetrische encryptie gebaseerd, waarbij 1 vrijelijk mag (en zelfs moet) worden verspreid!" 1 wat?
(Q08) en vind op -> en vindt op.
(Q08) misschien handig om het artikel van Bruce Schneier over PKI problemen te citeren: http://www.schneier.com/paper-pki-ft.txt. Goed artikel, met punten die nog steeds valide zijn.
(Q09) berouwbare -> betrouwbare.
(Q09) versteulde -> versleutelde.
(Q10) "Als de hashes overeenkomen, is de kans ongeveer 10% dat er toch iets misgegaan is." Niet waar. De Bit Error Rate (BER) van hedendaagse communicatie is zo laag, dat die kans (gelukkig) heel wat kleiner is.
(Q10) maaht -> maakt
(Q10) Uitleggen wat salted precies wachtwoorden zijn -> typo
(Q10) "Zinvol kan zijn dat je begrijpt dat MD5 hashes, mits goed en random gesalt, best bruikbaar zijn op een (web) server waar gebruikers op inloggen." Je gebruikt een algoritme (MD5), zonder dat dit algoritme hiervoor is uitgelegd. Als ik niet weet wat MD5 is en niet weet wat salting is (wat je bewust niet uitlegt), dan wordt het als leek lastig om deze zin te begrijpen.
(Q10) soor -> voor
(Q10) hasshed -> hashed
(Q10) "Er bestaat wel een goede reden om geen snelle cryprografische hash te gebruiken voor hashed passwords: aanvallers kunnen dan relatief snel rainbow tables maken." Wellicht is het handig om dit iets anders te verwoorden. Het idee achter de genoemde algoritmen zoals PBKDF2 en bcrypt (deze algoritmen kunnen trouwens wel wat extra uitleg krijgen, want in dit zinsverband zullen veel mensen niet begrijpen waarom deze algoritmen en gelieerde algoritmen zoals PBMAC en PBHMAC nu zoveel beter zijn bij password opslag) is dat een snel algoritme op een bepaalde manier veel keer wordt uitgevoerd (zeg 15.000 keer) om tot de uiteindelijke hash te komen. Daarnaast zorgt de salt er ook nog eens voor dat het wachtwoord "qwerty123" dan weer gehashed wordt als de ene string en dan weer als de andere string.
(Q10) colissions -> collisions
(Q10) Het is misschien aardig om te verwijzen naar http://www.win.tue.nl/hashclash/Nostradamus/ voor PDF documenten die dezelfde MD5 hash opleveren. Gebruik de tool op b.v. http://www.microsoft.com/en-us/download/details.aspx?id=11533 om de hashes te berekenen. Voor meer hash algoritmen, zie HashCalc op http://www.slavasoft.com/hashcalc/. Een ander programma dat als crypto learning tool gebruikt kan worden is CrypTool (http://www.cryptool.org/en/), waarvan recentelijk versie 1.4.31 beta 05 is uitgekomen. Aanbevolen voor iedereen die geinteresseerd is in cryptografie!
(Q11) het -> Het
(Q12) handtekeing -> handtekening
(Q12) "Als je als uitgever met digitale handtekeningen aan de gang gaat, is het zeer zinvol om daar ondubbelzinnig op over te stappen, net zoals dat banken nooit in een e-mail om jouw wachtwoord zouden moeten vragen, en websites die overgaan op https, http geheel zouden moeten uitbannen (inclusief automatische redirects van http naar https)." Waarom zouden we alleen pure http of pure https websites mogen hebben en geen combinatie daarvan? Wat is het risico als we wel een combi hebben? Een volledige https site maakt de site alleen maar onnodig trager, terwijl we een risico aan het mitigeren zijn dat geen risico is.
(Q12) screensavertje die -> screensavertje dat
(Q12) toegepasten -> toegepaste
(Q12) "Er is nooit een goede standaard voor digitale handtekeningen onder e-mails tot stand gekomen. Als iedereen e-mails digitaal zou ondertekenen en ontvangers (de gebruikte mail client) de handtekening zou checken, zouden er heel veel minder spam, phishing, malware en identity spoofing mails in omloop zijn." Het een hangt volgens mij niet samen met het ander, doordat ik als spammer al mijn mail kan ondertekenen en zelf iedere dag een certificaat kan (laten) aanmaken. Daarnaast, en zijn toch voldoende goede standaarden te vinden, die prima algoritmen ondersteunen zoals DSA, RSA, ECDSA e.d.? Het probleem zit hem m.i. niet in de standaarden, maar in zaken zoals key management, kennis van cryptografie, schaalbaarheid etc.
(Q12) "Dit staat overigens bekend als non-repudiation, d.w.z. het kunnen weerleggen dat jij niet verantwoordelijk bent voor iets dat jij wel lijkt te hebben ondertekend." Zie ook mijn opmerking over non-repudiation hierboven. Het betekent in de cryptografie net het tegenovergestelde, namelijk dat een bepaalde bewering niet te weerleggen is.
(Q13) Er is geen Q13? Helemaal bovenaan, onder het kopje "Inhoudsopgave", staat daardoor een wat ongelukkige regel: "Helaas kan ik geen hyperlinks maken van onderstaande onderwerpen. Tik Ctrl-F en zoek bijv. naar (Q13)."
Ook in de inhoudsopgave ontbreekt Q13.
(Q14) dialookbox -> dialoogbox
(Q14) "hieruit blijkt dat dit certificaat mag NIET als een CA certificaat gebruikt worden;" -> typo
(Q14) "gemaakt van asymmetrisch" -> "gemaakt van een asymmetrisch"
(Q14) Het Certificaat -> het certificaat
(Q00) "FAQ (Frequently Asked Questions)". Afkortingen zoals FAQ "uitschrijven" bij het eerste gebruik van de afkorting. Dat gebruik vindt iets eerder plaats.
(Q01) De definitie van CA en CSP is recursief. De ene verwijst naar de andere en vice versa. Beter is het om de definitie van ISO 21188:2006 ("Public key infrastructure for financial services - Practices and policy framework") te gebruiken:
certification authority - CA - entity trusted by one or more entities to create, assign and revoke or hold public key certificates
(Q01) Hoewel er tientallen definities zijn die niet zijn opgenomen in deze FAQ, is het verschil tussen een CA en een RA wellicht iets om te benadrukken. Bij iedere klant waar ik kom kan een auditpunt worden gedefinieerd voor interne PKI's dat de RA rol niet is ingevuld. Wederom de definitie van ISO 21188:2006:
registration authority - RA - entity that is responsible for identification and authentication of subjects of certificates, but is not a CA (3.18), and hence does not sign or issue certificates. NOTE An RA may assist in the certificate application process or revocation process or both. The RA does not need to be a separate body, but can be part of the CA.
(Q01) Je geeft wel de definitie van cryptografie (the art of making things), maar niet van cryptoanalyse (the art of breaking things). Beide maken deel uit van de overkoepelende cryptologie. http://nl.wikipedia.org/wiki/Cryptografie geeft de Griekse woorden waar cryptologie van is afgeleid.
(Q01) Key: sleutel. Ik denk dat veel mensen zover nog wel waren gekomen :). Het is een vertaling, vergelijkbaar met enkele van bovenstaande en onderstaande "definities". Het is geen uitleg van een woord, zoals je wel bij "Algoritme" doet. De vraag is of je termen globaal wilt uitleggen, of dat je alleen een vertaling wilt geven, iets wat voor de leek nog steeds onduidelijk zal zijn.
(Q01) Non-repudiation: het is handiger om de definitie onder het kopje "Non-repudiation in digital security" op de Wikipedia te gebruiken. De Wikipedia pagina geeft ook expliciet aan: "Regarding digital security, the cryptological meaning and application of non-repudiation shifts to mean:". Kortom, non-repudiation in cryptografie betekent iets anders.
(Q01) PKI. Wellicht ook hier handig om wat meer achtergrondinformatie te geven. Om de ISO norm wederom te citeren:
public key infrastructure - PKI - structure of hardware, software, people, processes and policies that employs digital signature technology to facilitate a verifiable association between the public component of an asymmetric public key pair with a specific subscriber that possesses the corresponding private key. NOTE The public key may be provided for digital signature verification, authentication of the subject in communication dialogues, and/or for message encryption key exchange or negotiation.
(Q06) "Public key encryptie is volledig op asymmetrische encryptie gebaseerd, waarbij 1 vrijelijk mag (en zelfs moet) worden verspreid!" 1 wat?
(Q08) en vind op -> en vindt op.
(Q08) misschien handig om het artikel van Bruce Schneier over PKI problemen te citeren: http://www.schneier.com/paper-pki-ft.txt. Goed artikel, met punten die nog steeds valide zijn.
(Q09) berouwbare -> betrouwbare.
(Q09) versteulde -> versleutelde.
(Q10) "Als de hashes overeenkomen, is de kans ongeveer 10% dat er toch iets misgegaan is." Niet waar. De Bit Error Rate (BER) van hedendaagse communicatie is zo laag, dat die kans (gelukkig) heel wat kleiner is.
(Q10) maaht -> maakt
(Q10) Uitleggen wat salted precies wachtwoorden zijn -> typo
(Q10) "Zinvol kan zijn dat je begrijpt dat MD5 hashes, mits goed en random gesalt, best bruikbaar zijn op een (web) server waar gebruikers op inloggen." Je gebruikt een algoritme (MD5), zonder dat dit algoritme hiervoor is uitgelegd. Als ik niet weet wat MD5 is en niet weet wat salting is (wat je bewust niet uitlegt), dan wordt het als leek lastig om deze zin te begrijpen.
(Q10) soor -> voor
(Q10) hasshed -> hashed
(Q10) "Er bestaat wel een goede reden om geen snelle cryprografische hash te gebruiken voor hashed passwords: aanvallers kunnen dan relatief snel rainbow tables maken." Wellicht is het handig om dit iets anders te verwoorden. Het idee achter de genoemde algoritmen zoals PBKDF2 en bcrypt (deze algoritmen kunnen trouwens wel wat extra uitleg krijgen, want in dit zinsverband zullen veel mensen niet begrijpen waarom deze algoritmen en gelieerde algoritmen zoals PBMAC en PBHMAC nu zoveel beter zijn bij password opslag) is dat een snel algoritme op een bepaalde manier veel keer wordt uitgevoerd (zeg 15.000 keer) om tot de uiteindelijke hash te komen. Daarnaast zorgt de salt er ook nog eens voor dat het wachtwoord "qwerty123" dan weer gehashed wordt als de ene string en dan weer als de andere string.
(Q10) colissions -> collisions
(Q10) Het is misschien aardig om te verwijzen naar http://www.win.tue.nl/hashclash/Nostradamus/ voor PDF documenten die dezelfde MD5 hash opleveren. Gebruik de tool op b.v. http://www.microsoft.com/en-us/download/details.aspx?id=11533 om de hashes te berekenen. Voor meer hash algoritmen, zie HashCalc op http://www.slavasoft.com/hashcalc/. Een ander programma dat als crypto learning tool gebruikt kan worden is CrypTool (http://www.cryptool.org/en/), waarvan recentelijk versie 1.4.31 beta 05 is uitgekomen. Aanbevolen voor iedereen die geinteresseerd is in cryptografie!
(Q11) het -> Het
(Q12) handtekeing -> handtekening
(Q12) "Als je als uitgever met digitale handtekeningen aan de gang gaat, is het zeer zinvol om daar ondubbelzinnig op over te stappen, net zoals dat banken nooit in een e-mail om jouw wachtwoord zouden moeten vragen, en websites die overgaan op https, http geheel zouden moeten uitbannen (inclusief automatische redirects van http naar https)." Waarom zouden we alleen pure http of pure https websites mogen hebben en geen combinatie daarvan? Wat is het risico als we wel een combi hebben? Een volledige https site maakt de site alleen maar onnodig trager, terwijl we een risico aan het mitigeren zijn dat geen risico is.
(Q12) screensavertje die -> screensavertje dat
(Q12) toegepasten -> toegepaste
(Q12) "Er is nooit een goede standaard voor digitale handtekeningen onder e-mails tot stand gekomen. Als iedereen e-mails digitaal zou ondertekenen en ontvangers (de gebruikte mail client) de handtekening zou checken, zouden er heel veel minder spam, phishing, malware en identity spoofing mails in omloop zijn." Het een hangt volgens mij niet samen met het ander, doordat ik als spammer al mijn mail kan ondertekenen en zelf iedere dag een certificaat kan (laten) aanmaken. Daarnaast, en zijn toch voldoende goede standaarden te vinden, die prima algoritmen ondersteunen zoals DSA, RSA, ECDSA e.d.? Het probleem zit hem m.i. niet in de standaarden, maar in zaken zoals key management, kennis van cryptografie, schaalbaarheid etc.
(Q12) "Dit staat overigens bekend als non-repudiation, d.w.z. het kunnen weerleggen dat jij niet verantwoordelijk bent voor iets dat jij wel lijkt te hebben ondertekend." Zie ook mijn opmerking over non-repudiation hierboven. Het betekent in de cryptografie net het tegenovergestelde, namelijk dat een bepaalde bewering niet te weerleggen is.
(Q13) Er is geen Q13? Helemaal bovenaan, onder het kopje "Inhoudsopgave", staat daardoor een wat ongelukkige regel: "Helaas kan ik geen hyperlinks maken van onderstaande onderwerpen. Tik Ctrl-F en zoek bijv. naar (Q13)."
Ook in de inhoudsopgave ontbreekt Q13.
(Q14) dialookbox -> dialoogbox
(Q14) "hieruit blijkt dat dit certificaat mag NIET als een CA certificaat gebruikt worden;" -> typo
(Q14) "gemaakt van asymmetrisch" -> "gemaakt van een asymmetrisch"
(Q14) Het Certificaat -> het certificaat
27-08-2012, 01:36 door
Erik van Straten
Door Overcome: Een goed idee om dit te schrijven, al was het maar om veel informatie samen te pakken op 1 pagina. Ik ben benieuwd naar het vervolg. Hieronder mijn op- en aanmerkingen. Wellicht heb je er wat aan.
Dank voor jouw uitstekende opmerkingen en grondige leeswerk!(Q00) "FAQ (Frequently Asked Questions)". Afkortingen zoals FAQ "uitschrijven" bij het eerste gebruik van de afkorting. Dat gebruik vindt iets eerder plaats.
In 1e bijdrage opgenomen.(Q01) De definitie van CA en CSP is recursief. De ene verwijst naar de andere en vice versa. Beter is het om de definitie van ISO 21188:2006 ("Public key infrastructure for financial services - Practices and policy framework") te gebruiken:
[...]
(Q01) Hoewel er tientallen definities zijn die niet zijn opgenomen in deze FAQ, is het verschil tussen een CA en een RA wellicht iets om te benadrukken.
Ik ben wat in verwarring gebracht door de ETSI. Bijv. in http://www.etsi.org/WebSite/Technologies/CertificationAuthoritiesandCertificationServiceProviders.aspx is sprake van CA's and other CSP's. De ISO standaard die je noemt heb ik niet in mijn bezit (en hoewel dat document wellicht zeer interessant is, wil ik me niet beperken tot financial services). Ik ga me zoveel mogelijk aan http://www.logius.nl/nc/begrippenlijst/, http://www.etsi.org/deliver/etsi_ts/101400_101499/101456/01.04.03_60/ts_101456v010403p.pdf en https://www.cabforum.org/faq.html houden, maar wel zaken vereenvoudigen waar m.i. mogelijk. Daarnaast zal ik naar die webpages/documenten verwijzen.[...]
(Q01) Hoewel er tientallen definities zijn die niet zijn opgenomen in deze FAQ, is het verschil tussen een CA en een RA wellicht iets om te benadrukken.
(Q01) Je geeft wel de definitie van cryptografie (the art of making things), maar niet van cryptoanalyse (the art of breaking things). Beide maken deel uit van de overkoepelende cryptologie. http://nl.wikipedia.org/wiki/Cryptografie geeft de Griekse woorden waar cryptologie van is afgeleid.
Eens maar dit valt buiten de scope van wat ik voor deze FAQ in gedachten had.(Q01) Key: sleutel. Ik denk dat veel mensen zover nog wel waren gekomen :). Het is een vertaling, vergelijkbaar met enkele van bovenstaande en onderstaande "definities". Het is geen uitleg van een woord, zoals je wel bij "Algoritme" doet. De vraag is of je termen globaal wilt uitleggen, of dat je alleen een vertaling wilt geven, iets wat voor de leek nog steeds onduidelijk zal zijn.
Informatie toegevoegd.(Q01) Non-repudiation: het is handiger om de definitie onder het kopje "Non-repudiation in digital security" op de Wikipedia te gebruiken. De Wikipedia pagina geeft ook expliciet aan: "Regarding digital security, the cryptological meaning and application of non-repudiation shifts to mean:". Kortom, non-repudiation in cryptografie betekent iets anders.
Hmm, dan ben ik het niet eens met wat er op die Wikipedia pagina staat! Vreemd genoeg verwoordt http://en.wikipedia.org/wiki/Digital_signature#Non-repudiation exact wat ik bedoel. Echter mijn tekst was onjuist, gecorrigeerd.(Q01) PKI. Wellicht ook hier handig om wat meer achtergrondinformatie te geven
Done!(Q06) "Public key encryptie is volledig op asymmetrische encryptie gebaseerd, waarbij 1 vrijelijk mag (en zelfs moet) worden verspreid!" 1 wat?
(Q08) en vind op -> en vindt op.
(Q09) berouwbare -> betrouwbare.
(Q09) versteulde -> versleutelde.
Nice finds. Fixed!(Q08) en vind op -> en vindt op.
(Q09) berouwbare -> betrouwbare.
(Q09) versteulde -> versleutelde.
(Q08) misschien handig om het artikel van Bruce Schneier over PKI problemen te citeren: http://www.schneier.com/paper-pki-ft.txt. Goed artikel, met punten die nog steeds valide zijn.
Dat is het zeker. Het was voor mij, jaaaaren geleden, reden om flink aan digitale handtekeningen te gaan twijfelen. Niet lang daarna heb ik besloten dat ik nooit e-mail digitaal zou willen ondertekenen, zodat als iemand ooit zou claimen een door mij gesigneerde mail te hebben ontvangen, ik naar eer en geweten zou kunnen zeggen nooit e-mail digitaal te hebben ondertekend. Ondertussen heb ik me voor een bepaalde klus genoodzaakt gevoeld om die stap toch te zetten. Ontkennen wordt nu lastiger voor mij (sort of eens een dief, ...;). Echter een verwijzing naar dat artikel hoort bij PKI, niet bij public key crypto.(Q10) "Als de hashes overeenkomen, is de kans ongeveer 10% dat er toch iets misgegaan is." Niet waar. De Bit Error Rate (BER) van hedendaagse communicatie is zo laag, dat die kans (gelukkig) heel wat kleiner is.
Zoals het er stond klopte het inderdaad niet. Gefixed.(Q10) maaht -> maakt
(Q10) soor -> voor
(Q10) hasshed -> hashed
Fixed!(Q10) soor -> voor
(Q10) hasshed -> hashed
(Q10) Uitleggen wat salted precies wachtwoorden zijn -> typo
(Q10) "Zinvol kan zijn dat je begrijpt dat MD5 hashes, mits goed en random gesalt, best bruikbaar zijn op een (web) server waar gebruikers op inloggen." Je gebruikt een algoritme (MD5), zonder dat dit algoritme hiervoor is uitgelegd. Als ik niet weet wat MD5 is en niet weet wat salting is (wat je bewust niet uitlegt), dan wordt het als leek lastig om deze zin te begrijpen.
Tekst en verwijzingen naar Wikipedia toegevoegd.(Q10) "Zinvol kan zijn dat je begrijpt dat MD5 hashes, mits goed en random gesalt, best bruikbaar zijn op een (web) server waar gebruikers op inloggen." Je gebruikt een algoritme (MD5), zonder dat dit algoritme hiervoor is uitgelegd. Als ik niet weet wat MD5 is en niet weet wat salting is (wat je bewust niet uitlegt), dan wordt het als leek lastig om deze zin te begrijpen.
(Q10) "Er bestaat wel een goede reden om geen snelle cryprografische hash te gebruiken voor hashed passwords: aanvallers kunnen dan relatief snel rainbow tables maken." Wellicht is het handig om dit iets anders te verwoorden. Het idee achter de genoemde algoritmen zoals PBKDF2 en bcrypt (deze algoritmen kunnen trouwens wel wat extra uitleg krijgen, want in dit zinsverband zullen veel mensen niet begrijpen waarom deze algoritmen en gelieerde algoritmen zoals PBMAC en PBHMAC nu zoveel beter zijn bij password opslag) is dat een snel algoritme op een bepaalde manier veel keer wordt uitgevoerd (zeg 15.000 keer) om tot de uiteindelijke hash te komen. Daarnaast zorgt de salt er ook nog eens voor dat het wachtwoord "qwerty123" dan weer gehashed wordt als de ene string en dan weer als de andere string.
Interessant maar valt buiten de scope. Voor digitale handtekeningen is uitleg van cryptografische hashes noodzakelijk. Ik ga wel even in op wachtwoordhashes omdat md5 voor dat doel nog niet gebroken is, en ik daar op wil wijzen.(Q10) colissions -> collisions
(Q10) Het is misschien aardig om te verwijzen naar http://www.win.tue.nl/hashclash/Nostradamus/ voor PDF documenten die dezelfde MD5 hash opleveren. Gebruik de tool op b.v. http://www.microsoft.com/en-us/download/details.aspx?id=11533 om de hashes te berekenen. Voor meer hash algoritmen, zie HashCalc op http://www.slavasoft.com/hashcalc/. Een ander programma dat als crypto learning tool gebruikt kan worden is CrypTool (http://www.cryptool.org/en/), waarvan recentelijk versie 1.4.31 beta 05 is uitgekomen. Aanbevolen voor iedereen die geinteresseerd is in cryptografie!
(Q11) het -> Het
(Q12) handtekeing -> handtekening
Fixed!(Q10) Het is misschien aardig om te verwijzen naar http://www.win.tue.nl/hashclash/Nostradamus/ voor PDF documenten die dezelfde MD5 hash opleveren. Gebruik de tool op b.v. http://www.microsoft.com/en-us/download/details.aspx?id=11533 om de hashes te berekenen. Voor meer hash algoritmen, zie HashCalc op http://www.slavasoft.com/hashcalc/. Een ander programma dat als crypto learning tool gebruikt kan worden is CrypTool (http://www.cryptool.org/en/), waarvan recentelijk versie 1.4.31 beta 05 is uitgekomen. Aanbevolen voor iedereen die geinteresseerd is in cryptografie!
(Q11) het -> Het
(Q12) handtekeing -> handtekening
(Q12) "Als je als uitgever met digitale handtekeningen aan de gang gaat, is het zeer zinvol om daar ondubbelzinnig op over te stappen, net zoals dat banken nooit in een e-mail om jouw wachtwoord zouden moeten vragen, en websites die overgaan op https, http geheel zouden moeten uitbannen (inclusief automatische redirects van http naar https)." Waarom zouden we alleen pure http of pure https websites mogen hebben en geen combinatie daarvan? Wat is het risico als we wel een combi hebben?
Met name via publieke wifi netwerken zijn http hosts eenvoudig te spoofen. Op bedrade netwerken is dit lastiger, maar daar bestaan nog steeds verschillende aanvallen voor. Op sites waarop je moet inloggen zal vaak naar https worden overgeschakeld. In zo'n situatie is social engineering zeer simpel: de gebruiker krijgt niet de https site te zien, maar http. Omdat hij of zij al in http zat, zal het slotje niet worden gemist. Maar ook als dat goed gaat, en na inloggen de site terugschakelt naar http, gaat het authentication cookie unencrypted over de lijn. Firesheep is gepubliceerd om aam te tonen hoe onveilig dat is.Een volledige https site maakt de site alleen maar onnodig trager, terwijl we een risico aan het mitigeren zijn dat geen risico is.
Als je nu ziet dat alle major sites over gaan naar https kan dat toch niet meer zo'n grote issue zijn.(Q12) screensavertje die -> screensavertje dat
(Q12) toegepasten -> toegepaste
Done!(Q12) toegepasten -> toegepaste
(Q12) "Er is nooit een goede standaard voor digitale handtekeningen onder e-mails tot stand gekomen. Als iedereen e-mails digitaal zou ondertekenen en ontvangers (de gebruikte mail client) de handtekening zou checken, zouden er heel veel minder spam, phishing, malware en identity spoofing mails in omloop zijn." Het een hangt volgens mij niet samen met het ander, doordat ik als spammer al mijn mail kan ondertekenen en zelf iedere dag een certificaat kan (laten) aanmaken.
PKI valt of staat ermee dat CA's certificaten signeren na het controleren of de aanvrager is wie hij zegt te zijn. CA's die dat niet doen zouden niet vertrouwd moeten worden (dus root cert uit webbrowser/OS verwijderen). Spammers die hun identiteit niet spoofen zijn veel makkelijker te vinden, en spamme is strafbaar in veel landen.(Q12) "Dit staat overigens bekend als non-repudiation, d.w.z. het kunnen weerleggen dat jij niet verantwoordelijk bent voor iets dat jij wel lijkt te hebben ondertekend." Zie ook mijn opmerking over non-repudiation hierboven. Het betekent in de cryptografie net het tegenovergestelde, namelijk dat een bepaalde bewering niet te weerleggen is.
Gecorrigeerd.(Q13) Er is geen Q13? Helemaal bovenaan, onder het kopje "Inhoudsopgave", staat daardoor een wat ongelukkige regel: "Helaas kan ik geen hyperlinks maken van onderstaande onderwerpen. Tik Ctrl-F en zoek bijv. naar (Q13)."
Ook in de inhoudsopgave ontbreekt Q13.
Je hebt gelijk. Of ik Q13 nog ga tussenvoegen slaap ik nog een nachtje over ;)Ook in de inhoudsopgave ontbreekt Q13.
(Q14) dialookbox -> dialoogbox
(Q14) "hieruit blijkt dat dit certificaat mag NIET als een CA certificaat gebruikt worden;" -> typo
(Q14) "gemaakt van asymmetrisch" -> "gemaakt van een asymmetrisch"
(Q14) Het Certificaat -> het certificaat
Gecorrigeerd.(Q14) "hieruit blijkt dat dit certificaat mag NIET als een CA certificaat gebruikt worden;" -> typo
(Q14) "gemaakt van asymmetrisch" -> "gemaakt van een asymmetrisch"
(Q14) Het Certificaat -> het certificaat
Nogmaals hartelijk dank voor jouw uitgebreide en grondige review!
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
