Apple opent zijn cryptografische bibliotheek voor ontwikkelaars

Apple heeft zijn beveiligingsframework, common crypto-bibliotheken en de corecrypto library voor zowel iOS als OS X opengesteld voor derde partijen. De fabrikant zegt dat het openstellen ontwikkelaars helpt geavanceerde beveiligingsfuncties in te bouwen.

Het beveiligingsframework bevat de services en api's voor onder andere het uitlezen en valideren van certificaten, het beheer van Keychain-items en random number generators. De common crypto library bevat daarnaast api's voor symmetrische en asymmetrische encryptie en hashing-doeleinden.

Zowel het raamwerk als de bibliotheken maken gebruik van het onderliggende 'corecrypto'. Dit is een low-level-bibliotheek die applicaties niet direct moeten aanspreken, maar die Apple desondanks vrijgeeft voor verificatie en beoordeling over correct functioneren.

Niet alle informatie uit de corecrypto-bibliotheek is even bruikbaar voor het veiliger maken van applicaties. De library bevat niet alleen routines voor standaarden als aes, rsa, Curve25519 en sha256, maar ook implementaties van verouderde technieken als md2, md4, md5, des, rc2 en rc4.

Apple gaf eerder dit jaar al de broncode van zijn programmeertaal Swift vrij.

Reacties (85)

[jonab1]

maakt dit niet de software van apple zelf gevoeliger voor hackers aangezien ze dan enigzins weten hoe het is opgebouwd? of kijk ik kan verkeerd?

[Maurits van Baerle]

Ja en nee. Aan de ene kant kun je hopen dat niemand ontdekt dat er misschien ergens een fout in je Closed Source code zit. Aan de andere kant weet je nooit zeker dat een kwaadwillende dat niet al stiekem heeft ontdekt. Daarom kun je dus ook beargumenteren dat als de code Open Source is de kans groter is dat een goedwillend persoon het ontdekt en het netjes bij het bedrijf meldt.

Overigens moet je van dat laatste niet al teveel verwachten. Vorig jaar werd er een bug gevonden in een Apple crypto library. En ondanks dat alle relevante code gewoon van OpenSource.Apple.Com te downloaden was heeft het 18 maanden geduurd voordat iemand het ontdekte. De beruchte bug in de GNUTLS library heeft er zelfs negen jaar (!) ingezeten voordat iemand aan de bel trok, ondanks dat het gewoon Open Source was.

Maar goed, in dit specifieke geval zal het deze libraries alleen maar veiliger maken omdat er zeker tegenwoordig veel meer aandacht is voor lekken in crypto libraries dan twee jaar geleden. Reken maar dat een paar mensen deze libraries aan een grondige inspectie gaan onderwerpen.

[Reactie gewijzigd door Maurits van Baerle op 23 juli 2024 05:16]

[Verwijderd]

Overigens moet je van dat laatste niet al teveel verwachten. Vorig jaar werd er een bug gevonden in een Apple crypto library. En ondanks dat alle relevante code gewoon van OpenSource.Apple.Com te downloaden was heeft het 18 maanden geduurd voordat iemand het ontdekte. De beruchte bug in de GNUTLS library heeft er zelfs negen jaar (!) ingezeten voordat iemand aan de bel trok, ondanks dat het gewoon Open Source was.

Dat is waar maar als het niet Open Source geweest was zat de fout er nog steeds in . Neemt natuurlijk jouw punt niet weg dat je er inderdaad niet al te veel van mag verwachten.

[tijnvw]

Bovenstaande klopt zonder meer, hier is echter wel iets op aan te merken:

Een API is een Application Programming Interface. Dit betekent dat een API een schakel vormt tussen een gebruiker (of telefoon/browser) en de 'echte' software die het werkt doet; laten we dit de 'moederserver' noemen.
Je kunt een API dus zien als een soort doorgeefluik waar allerlei intelligente functies in zijn verwerkt zodat je apparaat van alle mogelijkheden die de moederserver biedt, gebruik kan maken. Toegegeven, in een API kunnen natuurlijk ook fouten zitten waardoor een gebruiker bij meer informatie kan dan eigenlijk zou mogen, maar het is dus niet zo dat door de broncode van een API te kunnen bekijken, de broncode op de moederserver inzichtelijk wordt.

Desalniettemin een goede stap dat ze de API open source maken, zoals Maurits al aangeeft, zullen er vast mensen zijn die foutjes gaan ontdekken en netjes aangeven

[valvy]

Natuurlijk kan een cracker nu bekijken of er zwaktes in de library zitten. En er zullen altijd zwaktes erin zitten.

Maar je moet het eigenlijk op een hele andere manier zien. Een cracker werkt vaak in kleine groepen. En door dat limiet zullen ze maar beperkt schade kunnen doen.

Als je iets gesloten houdt heb je ook maar een beperkte groep dat je software kan verdedigen (apple heeft echt geen 1000 man op deze library staan) en zijn er in de praktijk meer mensen die inbreken dan verdedigen.

Als je iets open stelt kan iemand meehelpen tot verdedigen van deze software. (Hij gebruikt het immers ook). En die 100 man aan de development team krijgt ondersteuning van een hoop andere bedrijven/studenten/ethische hackers/hobbyisten.

En dan heb je opeens dat elke regel code wordt gecontroleerd door tien andere mensen. En tien mensen weten meer dan een.

Natuurlijk heb je ook de beroemde verhalen zoals shellshock en hearthbleef. Opensource is geen enkele garantie.

Maar vergelijk het eens met windows onder xp service pack 1. (En mac os 9 en minder). Die waren echt heel lang heel onveilig. Terwijl berkeley unix en nextstep relatief goed beveiligd waren. (Beide open source(

[TheMak]

Dat hangt er helemaal van af, wie de fout als eerste ontdekt natuurlijk. Maar je kan er wel mee voorkomen dat andere ontwikkelaars hun eigen versies gaan ontwikkelen van de beveiligingsroutines. Als iedereen zijn eigen versie gaat ontwikkelen, dan kan je wachten op kwetsbaarheden.

[hardwareaddict]

Nee want hacken doe je toch op assembler nivo en zulke libraries heb je tenslotte wel een binary van, dus kun je de geproduceerde assembler van zien.

[zzzzap]

Snel even door de .c files gewandeld, maar zie niet dat er gebruik wordt gemaakt van de cryptoprocessor die in een iphone/ipad zit.
Iemand ervaring hiermee?

[Maurits van Baerle]

Zouden die niet door 'het onderliggende corecrypto' worden aangesproken? Het lijkt me best logisch dat deze APIs en bibliotheken allemaal een abstractieniveau hoger liggen dan de hardwareaansturing.

[zzzzap]

Ik had dan op zn minst een pkcs#11 interface verwacht, zodat je ook eigen cryptohardware zou kunnen gebruiken.

[SPee]

Kun je die dan wel aansluiten op je iPhone?
En ondersteund Apple wel die hardwareondersteuning?
Mij lijk het antwoord: "nee"
Dit biedt Apple aan en daar moet je het maar mee doen. Wil je meer, dan zul je zelf de code daarvoor moeten schrijven. En het is dan enkel voor jouw applicatie beschikbaar.

[zzzzap]

Er bestaand anders wel een aantal hardware smartcard-add-ons voor iPhones, bv: http://www.thursby.com/products/pkard-reader, alleen deze hebben vaak een proprietry interface, of een door leverancier geleverde (browser-)app.

[GekkePrutser]

Ja dit mis ik ook erg op iOS! Op Android heb je tenminste nog een open NFC implementatie zodat je de Yubikey Neo kan gebruiken als hardware token.

[mindcrash]

Uit de Security Guide voor iOS 9:

On mobile devices, speed and power efficiency are critical. Cryptographic operations
are complex and can introduce performance or battery life problems if not designed
and implemented with these priorities in mind.
Every iOS device has a dedicated AES 256 crypto engine built into the DMA path
between the flash storage and main system memory, making file encryption highly
efficient.

De crypto engine wordt dus specifiek gebruikt voor het versleutelen van bestanden i.v.m. performance en stroomverbruik

Overigens waren deze crypto libraries al eerder geschreven voor OSX (en dus voor macs zonder hardwarematige crypto acceleratie) en is het niet zo bijster verstandig om dit soort libraries, indien ze correct werken, wat te optimaliseren voor een nieuwe feature op een nieuw platform...

[Reactie gewijzigd door mindcrash op 23 juli 2024 05:16]

[Rukapul]

Curve25519 is natuurlijk verre van een standaard. Idem voor enkele andere algoritmen die populair zijn bij apple, Google, etc.

[CAPSLOCK2000]

Heel fijn dat ze ook een beetje naar de toekomst kijken en niet alleen de oude algoritmes gebruiken.
Overigens heeft SSH al een tijdje ondersteuning voor ED25519. Wat mij betreft heeft dit algoritme het daarmee tot mainstream geschopt.

Ik kan zo snel geen lijstje vinden met alle ondersteunde ciphers maar het lijstje uit het artikel is allerminst controversieel en imho zelfs erg bescheiden, maar er zijn er vast wel meer.

[Jerie]

Gezien recente ontwikkelingen met NSA zegt standaard niet zo veel meer. ECDSA en de NIST curves zijn allemaal lek.

Geloof vooral mijn woord er niet op en lees de volgende bronnen.

http://safecurves.cr.yp.to/
http://blog.cr.yp.to/20140323-ecdsa.html
https://projectbullrun.org/dual-ec/vulnerability.html
https://stribika.github.i.../secure-secure-shell.html

[uiltje]

Ik ben nu al jaren bezig op StackOverflow op het gebied van cryptografie. Common Crypto heeft één van de slechts beschreven crypto API's - slechter nog dan OpenSSL. Zo slecht dat als je een cryptografische functie in google in voert dat je over het algemeen eerder een vraag op stackoverflow tegen komt dan de officiele documentatie.

Het vrijgeven van broncode voor cryptografische bibliotheken zie ik als een positief iets. Maar in dit geval was het echter noodzakelijk om uberhaupt te achterhalen wat de verschillende functies precies doen. In dit geval zie ik het eerder als een gevalletje noodzaak dan een erg positieve move van Apple.

Ik hoop dat dit niet een sluwe methode is om de verantwoordelijkheid voor deze biblotheken te ontlopen. Iets wat naar mijn mening wel vaker gebeurd als een bibliotheek als open source wordt bestempeld.

[page404]

Toevallig was ik hier de afgelopen dagen in gedoken, vooral de keychain services. Helaas zitten er wel wat rare verschillen tussen iOS en OS X. Delen van de library werken alleen onder iOS, zoals bv het genereren van een password uit Keychain. Erg raar.
Ik wist trouwens niet dat het nog maar onlangs was vrijgegeven.

[kalikatief]

Het artikel geeft de verkeerde indruk. Dit is zeker niet voor ontwikkelaars bedoelt, en legaal gezien heeft het geen praktisch nut voor hen. Apple probeert juist beveiligingsonderzoekers een hart onder de riem te steken. Zie de EULA:

... Apple grants you, for a period of ninety (90) days from the date you download the Apple Software, a limited, non-exclusive, non-sublicensable license under Apple’s copyrights in the Apple Software to make a reasonable number of copies of, compile, and run the Apple Software internally within your organization only on devices and computers you own or control, for the sole purpose of verifying the security characteristics and correct functioning of the Apple Software ...

[Durandal]

Om de mass-surveillance discussie nog maar eens aan te slingeren: Waarom zou je op die library vertrouwen? Closed source en amerikaanse wetgeving heeft als resultaat dat je niet weet of hier backdoors zijn ingebouwd.
Het zal iig niet de optie zijn die ik zal kiezen.

[hydrargyrum]

Waar haal jij closed source vandaan? http://opensource.apple.c.../CommonCrypto-60061.30.1/

[Durandal]

Misschien is closed source niet juist maar het punt is dat je het niet zelf compileert en dus niet weet of die source ook hetgene is dat draait als je die library gebruikt.
Je kunt Apple (of enig ander bedrijf, zeker de Amerikaans op dit vlak) niet op hun mooie blauwe ogen vertouwen.

[valvy]

Waarschijnlijk gebruikt apple dezelfde tools die jij op je mac hebt. Dus de gecompileerde binary zal niet extreem van jouw eigen binary verschillen. En dat kan je dan vergelijken.

Vertrouw je het nog niet? Dan kun je de .dylib vervangen met je eigen.

[xChOasx]

Ik ben het helemaal met je eens hoor, maar dan nog loop je dit risico: https://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html

De compiler kan ZELF code injecteren die je niet in de source-code van de compiler ziet.

[Reactie gewijzigd door xChOasx op 23 juli 2024 05:16]

[valvy]

Clang (de default compiler van apple) is ook open source. Vertouw je dat nog niet kun je zelfs die zelf compileren (bijv gcc) en gebruiken.

zoiezo moet je een bedrijf/organisaties toch op een bepaald niveau vertrouwen anders kun je beter helemaal niks (inclusief gnu/linux) gebruiken.

De hardware zelf kan in de theorie ook backdoors hebben

[xChOasx]

Nogmaals, ik ben het met je eens. Maar wanneer je welke compiler dan ook vertrouwt. Loop je tegen het issue aan waarvan ik de link postte.

HW backdoors is nog erger, inderdaad.

[Blokker_1999]

Iemand die zo paranoïde is kan beter van een computer wegblijven. Tenzij je je computer volledig zelf kunt bouwen en je software volledig in assembler kunt schrijven ga je toch altijd vertrouwen in een externe partij moeten plaatsen.

[robvanwijk]

Iemand die zo paranoïde is kan beter van een computer wegblijven. Tenzij je je computer volledig zelf kunt bouwen en je software volledig in assembler kunt schrijven ga je toch altijd vertrouwen in een externe partij moeten plaatsen.

Nee hoor, je hoeft "alleen maar" zelf een assembler te schrijven. En die hoeft niet eens heel geavanceerd te zijn, als ie maar goed genoeg is om een rudimentaire compiler te assemblen. En die compiler hoeft alleen maar goed genoeg te zijn om GCC te kunnen compilen (nadat je die regel-voor-regel hebt doorgelezen en alle bugs (elke bug is een mogelijke backdoor; bedoeld of onbedoeld) eruit gehaald hebt). Daarna is elke programma (waarvan je de source doorgelezen hebt) te compileren.

En dan draai je dat op een computer met een CPU van AMD of Intel (die beide onder de Patriot Act vallen en dus niet te vertrouwen zijn) en dan valt al je harde werk in duigen...

// Sent from my computer with an Intel CPU and Windows OS.

[hardwareaddict]

Nee dat is geen paranoia - compilers injecteren heel veel simpelweg. Kijk maar eens hoeveel XML code de visual c++ compiler al sinds begin deze eeuw injecteert in elke executable

[rboerdijk]

@Blokker_1999

Zo Paranoide is dat niet hoor - zoek eens op XCodeGhost...
Dat was 1-2 maanden geleden....

[Reactie gewijzigd door rboerdijk op 23 juli 2024 05:16]

[hydrargyrum]

Je kan zelf die library hartstikke goed compileren. En hoe weet je dat een willekeurige library van bijvoorbeeld pypi geen backdoors bevat? Je kan misschien zelfs zeggen dat dit veiliger is, omdat het van een bedrijf afkomt dat een reputatie hoog te houden heeft, in tegenstelling tot een anonieme ontwikkelaar op, zoals eerder genoemd, bijvoorbeeld pypi

[Durandal]

Ik heb het niet over welkeen library die je zelf kan kopieren, ik heb het over de gecompileerde versie die Apple meelevert.

[hydrargyrum]

Als je zo wantrouwig bent dan compileer je hem gewoon zelf, simpel genoeg zou ik zeggen? Wel vraag ik me af of we nou tegenwoordig niks meer moeten vertrouwen. Ik weet dat het gevaarlijk is om dit te zeggen op de t.net frontpage, maar niet alles bevat een backdoor o.i.d.

[Verwijderd]

Dan heb je hem gecompileerd en kan je hem alsnog niet op je iOS device zetten, want dat is afgeschermd.

[Verwijderd]

Gevalletje "Zoals de waard is..."? Kennelijk wordt er bij jou op het werk flink gesjoemeld als je zo over bedrijven denkt.

[robvanwijk]

Gevalletje "Zoals de waard is..."? Kennelijk wordt er bij jou op het werk flink gesjoemeld als je zo over bedrijven denkt.

Dat heeft er niks mee te maken; die waard en zijn gasten kunnen zelf kiezen hoe ze handelen (eerlijk of liegen), omdat er in hun tijd nog geen Patriot Act was die eerlijke mensen kan dwingen om oneerlijke dingen te doen.
Hij zegt niet dat de mensen zelf evil zijn, alleen dat een Amerikaans bedrijf een black box is; hoeveel betrouwbare mensen je er ook in stopt, je zult nooit weten of wat eruit komt betrouwbaar is.

[Aaargh!]

Dan compile je de code zelf en vergelijk je de resulterende binary met de binary die Apple meelevert (moet het uiteraard wel een repeatable build zijn).

[CAPSLOCK2000]

Het is open source en zelfs Free Software volgens de definite van de Free Software Foundation. Het is helaas niet compatible met het GPL maar verder is er op de licentie niet zo veel aan te merken.

[valvy]

Ik denk dat de gnu public license alleen maar als een molensteen aan de nek van een bedrijf hangt.

Het is zeer goed dat je vrije en open source software afgeeft. Maar het is niet altijd goed om de bron code op dezelfde moment als de binary te verstrekken. (Wat wel moet bij gpl)

En zeg nou zelf, is software echt vrij als je iemand verplicht het te open sourcen?

[CAPSLOCK2000]

Het is zeer goed dat je vrije en open source software afgeeft. Maar het is niet altijd goed om de bron code op dezelfde moment als de binary te verstrekken. (Wat wel moet bij gpl)

Waarom niet? Wat is het praktische bezwaar? In de tijd dat software via tapes werd uitgewisseld kon het lastig zijn. Tegenwoordig gaat alles via internet. Hoeveel moeite is het nu om een zipje met de source te mailen als iemand daar om vraagt? Verder gaan de verplichtingen van het GPL wat dat betreft niet.

En zeg nou zelf, is software echt vrij als je iemand verplicht het te open sourcen?

Je trapt in een klassieke valkuil door te denken dat het GPL voor programmeurs is. Dat is het niet. Ik vergeef het je graag want het is een beetje misleidend. Het GPL is geen gewone softwarelicentie. Andere softwarelicenties zijn er om de programmeur te beschermen en de rechten van de gebruiker ondergeschikt te maken aan die van de programmeur. Dat is normaal, de meeste bedrijven doen zo iets (of het nu of software gaat of niet). Het GPL is er juist op de gebruiker te beschermen en de rechten van de programmeur ten opzichte van de gebruiker in te perken.

Nu vraag je je af waarom een bedrijf dat zou willen. Het antwoord is dat er veel meer gebruikers dan programmeurs zijn. Als gebruiker is het heel gunstig om software onder het GPL te gebruiken. Er zijn dus ook klanten die eisen dat alle software die ze gebruiken onder het GPL wordt uitgegeven. Ze weten dan dat ze de software altijd kunnen blijven gebruiken zonder geniepige licentievoorwaarden en ze weten dat ze niet afhankelijk zijn van de oorspronkelijke programmeur. Als die niet meer wil of niet meer kan dan huren ze gewoon een andere programmeur in om verder te werken.
Als je met een paar bedrijven samenwerkt om software te maken waaar jullie allemaal van profiteren dan is het GPL de manier om iedereen eerlijk te houden en te voorkomen dat iemand het project kaapt.
Dan zit je misschien nog steeds met de vraag waarom programmeurs daar aan meewerken. Programmeurs zijn ook gebruikers, iedereen gebruikt meer software van anderen dan hij zelf ooit kan schrijven. Programmeurs snappen goed wat voor gebruikers de voordelen van het GPL zijn boven andere licenties. Sterker nog, juist programmeurs kunnen er het meeste voordeel bij behalen. Daarom zijn het vaak juist de programmeurs die het GPL willen voor software die ze zelf gebruiken

[valvy]

Het is handig om soms te wachten, als er bijvoorbeeld eerst een overeenstemming bereikt moet worden met een klant of third party middleware.

Het mooie van vrije broncode is dat iedereen er aan kan meewerken. alleen als het onder de gpl licentie komt worden programmeurs en bedrijven huiverig. Ze kunnen na toevoegen van code het niet meer gebruiken in een gesloten vorm(voor een klant dat misschien niet zo ver is als ons)

Dit is de reden dat sommige bedrijven geen gpl software (durven) te gebruiken. Waardoor bedrijven minder innoverende dingen toevoegen aan gpl projecten daarnaast moeten zij het wiel opnieuw uitvinden.

Je hebt ook vrije software dat niet afdwingt, bsd licentie bijvoorbeeld. Dan ben je ook niet afhankelijk van de leverancier.

ik ben 200% procent voor vrijheid en opensource. maar niet dat iemand zijn wil oplegt hoe ik met mijn broncode moet omgaan(en mij dus beperkt als programmeur en gebruiker)

[Reactie gewijzigd door valvy op 23 juli 2024 05:16]

[CAPSLOCK2000]

Als Ze dan iets willen toevoegen wat zij hebben ontwikkeld kunnen ze niet meer gebruiken in een gesloten vorm(voor een klant dat misschien niet zo ver is als ons)

Je denkt als een commerciele software developer. Dat is begrijpelijk want alle software in de winkel komt van commerciele developers en het kiezen van een licentie is ook vooral iets voor programmeurs die werken voor anderen.
99% van de bedrijven die software schrijven is echter geen softwarehuis. Ze gebruiken uiteraard een hoop software en ze hebben ook programmeurs in dienst maar de software die ze maken is niet voor de verkoop. Die is er alleen om het bedrijf te helpen bij het uitvoeren van de kerntaak van dat bedrijf. In die wereld is er maar weinig concurrentiedrang. Concurreren doen ze op het gebied waar ze goed op zijn, niet op software. Ze concurreren ook niet op wie de dikste waterleiding heeft of de snelste bedrijfswagens. Die gebieden zijn ter ondersteuning. Het moet goed en goedkoop zijn, exclusiviteit is niet belangrijk.
Misschien dat 1% van de ontwikkelde software in een doos op een plank in een (virtuele) winkel komt te staan. 99% van de software is niet voor de verkoop.

[valvy]

Verder moet je je ook afvragen waarom veel van de cryptografische code zo onnodig ingewikkeld gemaakt worden dat zelfs onnavolgbaar is waar welke functie aangeroepen wordt, terwijl een vrij goed versleutelende (RSA) library die je zelf pent - die is nog geen 150 kilobyte aan C code.

Omdat cryptografie ingewikkeld is. Doe jezelf(en voornamelijk je klanten) een lol en ga niet je eigen crypto libs schrijven.

http://www.moserware.com/...re-guide-to-advanced.html

[hardwareaddict]

Iedereen die security serieus neemt zou zijn eigen crypto lib moeten pennen, met als startalgoritme RSA. Zeg een bit of 8192 bits. Dat is eitje voor de hedendaagse mobieltjes nog.

Dat voorkomt in elk geval dat je RSA sleutel niet onveilig is, terwijl je bij de huidige libraries die garantie niet hebt. Zelfs een gcd nemen van de onderlinge RSA sleutels was al genoeg voor factorisatie van veel van die sleutels... ...5% factoriseerde alleen al op grond van een GCD nemen

[Maurits van Baerle]

Sorry hoor maar je eigen crypto library schrijven betekent dat je vrijwel zeker zo lek als een mandje bent.

Sterker nog, crypto is een taak voor wiskundigen, niet voor developers. Daarom gaat het zo vaak mis als developers denken zelf wel even hun crypto te ontwerpen. Je moet het design overlaten aan wiskundigen (wat crypto experts eigenlijk zijn), developers moeten het alleen uitvoeren. Dan onafhankelijk laten testen en inzien door andere wiskundigen en developers. Het is praktisch onmogelijk om in je eentje een crypto functie te schrijven die ook maar een beetje veilig is.

[hardwareaddict]

RSA was toch al uitgevonden heel wat jaartjes geleden.

Dacht jij dan dat er public key encryptie is nu die BETER is dan RSA?

[InsanelyHack]

Public key encryptie bestaat niet. Wat wel bestaat is asynchrone encryptie wat gebruik maakt van een private en een public key. Dit is het fundament hoe RSA werkt en hoe ook bv AES werkt. Deze twee verschillenden sleutels die ieders een Prime zijn waarbij ook de Private X Public een Prime zijn. Dus je voorgaande bewering van, 8192 bits encryptie wat een eitje zou zijn voor een mobiel, weerleg ik hiermee. De 3 primes laten bepalen door je mobiel op basis van 8192 bits encryptie is niet haalbaar doordat de keys simpelweg niet te berekenen zijn alvorens er ook maar 1 byte encrypt kan worden.

P.S. misschien toch wat beter je huiswerk doen.

[Reactie gewijzigd door InsanelyHack op 23 juli 2024 05:16]

[CAPSLOCK2000]

Je bent niet de eerste die dat denkt maar de ervaring leert dat het niet waar is. De wiskunde achter cryptografie is nog wel te overzien maar daarmee ben je er nog niet. Bij een praktische library moet je rekening houden met alle randgevallen en uitzonderingen en er van uitgaan dat je code wordt aangevallen door slimme krakers. Dat is oneindig veel meer werk dan de kern van het algoritme uitschrijven. Zelfs daarbij gaat er nog genoeg mis, 10 regels echte code zonder programmeerfouten zijn helaas zeldzaam, de meeste programmeurs kunnen dat niet consistent leveren.

De afsluiter is dat je niet zelf moet proberen je crypto te schrijven. Dat is een leuke oefening voor studenten maar niet iets wat je in productie wil gebruiken.

[InsanelyHack]

Ik snap werkelijk niet waarom dit Off-Topic wordt gemod. Het lijkt wel of men hier op tweakers een beetje klaar is met de opmerkingen als het gaat over backdoors en alls omvattende zaken onder de patriot act. Voor mij is dat "kop in het zand steken" en niets anders. We gaan toch ook niet promoten om weer XP te gebruiken wat zo insecure als wat is? Waarom mag men hier niet gewoon attenderen? Encryptie-methodes / api's / software, beschikbaar gesteld door een Amerikaans bedrijf, zou per definitie niet gebruikt moeten worden om bovenstaande redenen, althans niet met idee dat de encryptie voor "iedereen" geldt. Dat je het niet meer horen wil ok maar het is alles behalve off-topic.

[Reactie gewijzigd door InsanelyHack op 23 juli 2024 05:16]

[BastiaanCM]

Zouden we dan eindelijk app-passwords niet meer elke keer handmatig in hoeven vullen ? Zou fijn zijn. Sommige apps hebben ook nog wel de gewoonte daar opnieuw om te vragen na een update... Kom je aan zetten met je 16+ random karakters....

[ZpAz]

Sinds iOS 8 is er al een API welke het mogelijk maakt om applicaties wachtwoorden uit de keychain te laten halen.

[Firefly III]

Dat heeft er echt helemaal niets mee te maken.

[BastiaanCM]

Volgens mij wel, gezien de zin

Het beveiligingsframework bevat de services en api's voor onder andere het uitlezen en valideren van certificaten,het beheer van Keychain-itemss en random number generators.

Maar misschien heb ik het fout hoor.

[Aaargh!]

Je hebt het idd fout. Dit zijn als het ware de 'legoblokjes' waarmee die services gebouwd zijn. Ze zijn niet direct geopensourced om gebruikt te worden (is relief standaar spul allemaal) maar zodat mensen kunnen controleren of de implementatie van Apple wel veilig is.

Apps die opnieuw vragen om een password gebruiken waarschijnlijk gewoon geen Keychain voor het opslaan van het password.

[Fermion]

Mooi nieuws zo op een vrijdag middag

[praseodymium]

Apple gaf eerder dit jaar al de broncode van zijn programmeertaal Swift vrij.

Dat is de bedoeling, de broncode is nog nergens beschikbaar.