Software berekent 223.000 Truecrypt-hashes per seconde met AMD-gpu's

De ontwikkelaars van Hashcat, een populaire tool om wachtwoordhashes door middel van brute force te kraken, hebben een module gebouwd om Truecrypt aan te vallen. De tool zou met twee AMD Radeon 6990-kaarten 223.000 hashes per seconde kunnen berekenen.

De Hashcat-developers bouwden de module voor het aanvallen van Truecrypt-hashes nadat het een poll onder zijn gebruikers had gehouden. Truecrypt is een populaire en opensource-encryptietool, en kan onder andere versleutelde containers aanmaken om data voor derden onleesbaar te maken. Net als veel andere encryptiesoftware maakt de software gebruik van hashes voor de versleutelde opslag van het benodigde wachtwoord.

De nieuwe Truecrypt-hacktool voor Hashcat gebruikt de gpu bij het uitvoeren van brute force-aanvallen. De developer, Atom geheten, wist met twee AMD Radeon 6990-kaarten, goed voor vier gpu's, 223.000 hashes per seconde te verwerken als de Truecrypt-container gebruikmaakt van het standaard geselecteerde RipeMD160-encryptiealgoritme. Bij het aanvallen van sha512-containers weet Hashcat 95.000 hashes per seconde aan te vallen, terwijl bij het Whirlpool-algoritme de snelheid terugzakt naar 49.000 hashes per seconde. Volgens de developer kunnen de prestaties nog verder omhoog als AMD een bug in zijn Linux-drivers dicht.

Reacties (97)

[Bananenplant]

Hoe moet ik deze getallen in perspectief plaatsen?

[Giesber]

Als je een paswoord van 8 letters (hoofd- en kleine letters) en cijfers zou nemen zijn daar (26 + 26 + 10) 52 tot de 8e macht combinaties mogelijk.

Dat zijn er 218340 miljard. Om die allemaal af te lopen zou de tool bijna 30 jaar bezig zijn.

Deze tool probeert geen paswoorden maar hashes, maar dat maakt volgens mij geen noemenswaardig verschil.

[BasieP]

Zeker wel,
Hashes hebben collisions, wachtwoorden niet.

Dat houd in dat je een ENORM complex wachtwoord kunt hebben, maar dat de hash ervan overeenkomt met de hash van 'hoi'.
Dit betekend dat je met het wachtwoord 'hoi' ook toegang hebt

Een goed password is dus getest of er geen collisions zijn met simpelere wachtwoorden.
(btw: een goed hashing algorime heeft een ZEER kleine kans op collisions)

[CARLiCiOUS]

Wat een kul.
Hashing algorithmes worden zo gemodelleerd dat bij een bitflip in de input de kans op een bitflip voor elke output bit 1/2 is. Daarom komen ze ogenschijnlijk uit een random verdeling (hashes zijn an sich niet te onderscheiden van random data).
Aangenomen dat ze uit een uniform random verdeling komen (rekent makkelijker),
betekent dat bij een algorithme als whirlpool, per wachtwoord 512 bits = een kans van 2^-512 op een collision met, jouw voorbeeld, het wachtwoord 'hoi'.
Laten we aannemen dat het wachtwoord van het volume 20 tekens telt - dan heb je, om de hele keyspace langs te gaan 96^20 pogingen nodig (veel te veel - totaal niet realistisch).
De kans dat je een collision vindt is dan 2^(2log(96)*20-512) = 2^-380.3. nadat je de HELE keyspace hebt doorgeploegd. Onzin dus.

Maar zelfs ALS je een collision vindt dan krijg je nog geen toegang tot het volume omdat de hash enkel wordt gebruikt om te verifieren of het wachtwoord goed was. Vervolgens wordt het wachtwoord - niet de hash - door een key derivatie algorithme gehaald (eigenlijk gewoon een andere hashfunctie) waarvan het resultaat wordt gebruikt als key voor het decryptie algorithme. De collision moet dus in beide hashfuncties optreden. Aangenomen dat je AES256 gebruikt is het tweede hashing algorithme 256 bits - wat neerkomt op een kans van 2^-636.3.

[Reactie gewijzigd door CARLiCiOUS op 24 juli 2024 03:12]

[robvanwijk]

De collision kan ook afkomstig zijn van een string even lang als de lengte van de hash, en/of tekens bevatten die niemand in zijn wachtwoord gebruikt. Strikt theoretisch heb je gelijk en zou je voor de zekerheid een dictionary attack op de hash van je sterke wachtwoord kunnen doen. In de praktijk kan ik me niet voorstellen dat dit ooit voorkomt.
Je stelling dat een goed password getest moet zijn op collision ben ik het niet mee eens; de kans dat het password tijdens die test op de een of andere manier uitlekt is waarschijnlijk aanzienlijk groter dan de kans dat je inderdaad een collision vindt.

[bogy]

ik gebruik bestanden als wachtwoord, en ik gebruik whirlpool omdat ik bij het aanmaken effe de opties heb doorgelezen en whirlpool het modernste en veiligste leek ...

Ik gebruik trouwens AES+Twofish omdat die combinatie nog vrij snel bljift op mijn pc (424MB/Sec gemiddeld)

[_Pussycat_]

Als de kans op collisions "ZEER" klein is, dan betekent het toch dat hashes i.p.v. wachtwoorden proberen bijna geen verschil maakt? Zodoende heeft Giesber toch wel gelijk, of niet?

[Fermion]

52^8=53.459.728.531.456

Hoe kom je aan 218340 miljard?

[Anoniem: 513523]

Als je dus een wachtwoord hebt met 12 of meer tekens dan is het gewoon onmogelijk om die ooit te kraken met de huidige techniek.

Deze 53.459.728.531.456 mogelijkheden bij 8 tekens betekend dus 239.729.724 seconden. Dit betekend dat een systeempje als hierboven in het artikel wordt genoemd er ruim 7,5 jaar over doet om alle wachtwoorden te proberen.

Echter wil dit natuurlijk niet zeggen dat zo'n systeem er ook zo lang over doet. De kans is dus aanwezig dat een bepaalde combinatie per ongeluk veel sneller wordt gevonden.

De vraag is dus hoe begint het script met het nagaan van deze hashes? als deze met de a begint en eindigt bij * bijvoorbeeld dan is een wachtwoord met 12 tekens waarin een * of meer voor komt op het einde dus het meest veilig. deze wordt dus pas geprobeert na 7 jaar

[Reactie gewijzigd door Anoniem: 513523 op 24 juli 2024 03:12]

[Beroemdheid]

Je hebt zo'n 95 tekens die je kan gebruiken voor een wachtwoord. Dat betekent dat je hiermee in 4 seconden alle wachtwoorden van 3 tekens kan proberen (95^3/223.000 = 3,8 sec). Voor 4 tekens heb je 6 minuten nodig, 5 tekens 10 uur. Voor 6 tekens bijna 40 dagen, dus vanaf dan is het niet echt meer te doen.

[scsirob]

Alleen is een Hash een afgeleide van dat wachtwoord, waarbij er veel meer lettercombinaties mogelijk zijn dan hashes. Met andere woorden, je hoeft niet alle mogelijke wachtwoorden te proberen om alle mogelijke hashes te testen

[Pete]

Dit klopt niet. Er zijn wel meer letter combinaties dan hashes, maar er is nog nooit een hash-collision gevonden voor RipeMD160, sha512 of whirpool.

Zowel theoretisch als in de praktijk betekent dit dat je inderdaad alle letter combinaties moet proberen.

Één ding dat Beroemdheid niet meetelt is dat veel wachtwoorden voorspelbaar zijn; woorden bevatten of afgeleiden van woorden. Door slim wachtwoorden te proberen kun je een hoop wachwoorden eerder kraken dan de genoemde tijd. Als je een echt goed random passwoord hebt, dan kloppen de berekeningen van Beroemdheid.

[PhoeniX1992]

Dan is het alleen geen pure Brute Force aanval meer, maar eerder een Dictionary Attack .

[JayVee]

Een ander perspectief is hoe "laag" het aantal hashes/second is. Hashes gemaakt met snelle hashalgorithmen (md5, sha1) kunnen enkele miljard keer per seconde getest worden. Vandaar dat je die ook absoluut niet moet gebruiken voor wachtwoorden.

Hier trouwens een artikel waarin beschreven wordt hoe crackers te werk gaan om wachtwoorden te kraken.

[hardwareaddict]

@bananenplant, alles wat je uitrekent op meer bits nauwkeurigheid dan de registers aankunnen loopt altijd trager dan je hoopt.

An sich zijn 223k hash afdrukken per seconde niet zoveel.

2 Radeon 6990 kaarten hebben bij elkaar 4 x 1536 cores = 6144 cores
Die zijn geklokt op rond de 830Mhz.

Dat is dus om het technisch uit te rekenen voor je: 6144 * 830 miljoen instructies per seconde.

6144 * 830M / 223k = 6144 * 830M / 0.223M = 6144 * 830 / 0.23 clocks = 22.9 miljoen instructies per hashafdruk.

Dat is toch wel een beetje inefficient hoor.

Ter vergelijking de factorisatie hier van priemgetallen, heel wat groter dan dit, de TRIAL factorisatie, wat ook een brute force aanval is, die vreet op de Nvidia GPU's zo rond de 2000 clocks per aanval.

Dit is maar 512 bits dus echt slim lijkt deze implementatie niet.

De vraag is overigens of hij slim moet wezen.

Wat op amateurnivo zit moet je echter er niet beter uit laten zien dan het is.
Op iets hogere security nivo's mag je je helemaal niet beveiligen met alleen een password natuurlijk.

Dan heb je bijvoorbeeld een USB stick nodig met daarop een 2048+ bits key

[ritsaert]

Voordat je dat soort conclusies trekt check even wat de hash betekend. Bij herberekend de hash 2000x voordat je de header key kan testen. Dit is juist gedaan om bij het starten een kleine investering te hebben van enkele ms maar BF zoekers het leven een flinke factor zuurder te maken.

Om op jouw berekening in te haken: 22.9M instr/sec voor 2K hashes is dus ongeveer 11K instructies per hash. Dit lijkt me nog steeds veel maar komt wel heel anders over.

<snip>
1000 iterations (or 2000 iterations when HMAC-RIPEMD-160 is used as the underlying hash function) of the key derivation function have to be performed to derive a header key, which increases the time necessary to perform an exhaustive search for passwords (i.e., brute force attack)
</snip>

[robvanwijk]

Het vergelijken van wachtwoord bruteforcen en priemgetallen factoriseren slaat als een tang op een varken; dat heeft niks met elkaar te maken (behalve dan dat de "strategie": alle mogelijkheden proberen, maar dan kan ik ook gaan smijten met TSP en dan lijkt het opeens wel gigantisch snel).

Een USB stick met een key van 2048 bits is niks anders dan een wachtwoord van 2048 bits; iedereen heeft wel een USB stick om dat ding op te zetten, dus de stick zelf voegt niks toe (dat zou anders zijn bij een key generator).

[teddysleep]

http://lastbit.com/pswcalc.asp

[Kaasbroodje]

even hé:

Ik heb een truecrypt computer los van het net met klant gegevens en die is beveiligd met een wachtwoord van 16 tekens, ( Hoofdletters, kleine letters, cijfers en leestekens en minsten een speciaal teken. ) Ik heb zo eens uitgerekend dat een dergelijk wachtwoord niet te kraken is, echt niet. Zelf al zouden alle moleculen van dit zonnestelsel 1 hash per seconden maken, dan nog niet.

95^16 = 44012666865176569775543212890625 combinaties, laten we de helt weghalen omdat er misschien random gewerkt wordt:

22006333432588284887771606445313

En laten we ze 100 jaar de tijd geven:

100*365 = 36500 dagen * 24 uur = 876000 uur * 3600 seconden = 3153600000 seconden, zo lang krijgen ze om mijn wachtwoord te kraken.

22006333432588284887771606445313 combo's delen door het aantal seconden =
13.956.325.109.454.772.252.519 wachtwoorden per seconden. Nou dat gaat nog even duren.... En als dat zo is gooi ik er een extra letter bij, zijn ze weer even extra bezig

[hardwareaddict]

helaas Kaasbroodje. Je praat alleen over de brute force algoritmes nu.

Het gros van de passwords van alle dames is toch of de naam van hun baby of kat en erachter hooguit een jaartal en een uitroepteken.

Dus dan heb je al ineens waanzinnig minder combinaties te doorzoeken.

Dus stel je hebt een lijstje met alle petnames en alle namen en plaatsnamen en evenementnamen. Gewoon de bestaande dictionary dus.

Dan vervolgens als je ook nog weet wiens password je kraakt ga je op internet spitten wat de persoon ooit te vertellen had en waar hij interesse in had. Dus dan is dictionary nog beperkter en ga je dictionarynamen combineren met wat uitroeptekens en soortgelijke ervoor of erachter of zelfs middenin.

Veel lastiger is al iets in de orde grootte "=MynPa$$woort"

Nog steeds zit hier echter een structuur in. Namelijk vervanging van letters door een synoniem. Dus ook hier kun je veel meer letters kraken met die paar biljoen pogingen per seconde die je hebt.

Pardon, ik bedoel natuurlijk 223k met deze software.

[gerwim]

Gaan we weer, comic van XKCD: http://imgs.xkcd.com/comics/password_strength.png

[leuk_he]

Ik denk dat deze meer van toepassing is:

http://xkcd.com/538/

en aangezien hij aangeeft dat er een truecrypt volume is met lang wachtwoord..... Is hij nu de pineut. Je praat niet over de security. Als je roept: er staat een 8 meter hoog hek rond mijn goudvoorraad, dan komt de dief met een ladder van 9 meter.

Enne, zo'n lang wachtwoord moet je inderdaad ergens vastleggen. Truecrypt is heel slecht in het bijhouden van een masterwachtwoord of 2e wachtwoord op een volume. daarom zal het niet zo snel in een standaard configuratie gebruikt worden.

[OMX2000]

Is dat zo? http://en.wikipedia.org/wiki/Deniable_encryption

Maar wat ik begrijp gaat dat niet op voor een truecrypt bestand, maar wel voor een complete schijf die ge-encrypt is, en waarvan niet zeker vast te stellen is of er uberhaupt iets ge-encrypt opstaat. De gemartelde kan dus ontkennen dat er iets op staat, of kan een password opbiechten wat een insignificant onthuld.

[dbzdragon]

Gaan we weer, comic van XKCD: http://imgs.xkcd.com/comics/password_strength.png

Ik had ooit gelezen dat een password die opgebouwd is uit de eerste letters van een woord (evt. in combinatie met hoofdletters, speciale karakters en cijfers) goede passwords zijn. Ze zijn daarnaast ook makkelijk te onthouden.

Dus stel je hebt de volgende zin: "Marie en Peter zijn getrouwd op 31 december 2011 in Rotterdam; Het was een memorabele dag."
Als je iedere eerste letter van ieder woord neemt (inclusief cijfers en leestekens) dan heb je zo je wachtwoord. In dit voorbeeld is het wachtwoord dus: MePzgo31d2iR;Hwemd.

Ik gebruik deze techniek zelf en vraag me af of dit nog steeds veilig is.

[imdoctorbob]

Dat is ook precies de kern van de comic: voor een bruteforce techniek weinig uitmaakt of je aaaaaa als wachtwoord hebt of @L9V{c.

Een goed wachtwoord heeft gewoon veel tekens (dus lang) en is geen naam/woord (of lijkt op een naam woord). Zoals je hier in het topic leest zit je boven de 8 tekens al prima en met 16 tekens hoef je niet te verwachten dat het ooit gekraakt gaat worden. Het is dus veel handiger voor jezelf dat je een wachtwoord hebt die je makkelijk kan onthouden. Ieder heeft daar zijn eigen methode voor, en jou methode is dus ook gewoon prima.

Daarbij is de beveiliging enkel zo sterk als de zwakste schakel. Als je dus ergens papieren briefjes met wachtwoorden hebt, of ze zijn ergens opgeslagen op je hardeschijf dan is de kans veel groter dat iemand er ooit achterkomt dan dat ze het wachtwoord daadwerkelijk kraken.

[hardwareaddict]

Ja wat ook zo'n wonderschone implementatie is in deze om guessing algoritmes te versnellen is naast de bekende methodes ook implementeren wat uit Game Tree Search komt. Bijvoorbeeld Fractional Ply Depth.

Er is geen echt goede wikipagina over, maar het principe is simpel:

http://chessprogramming.wikispaces.com/Depth

Zou interessant zijn om te weten of in de jaren 80 het ook het junior team is geweest die dit hebben uitgevonden (Amir Ban en Shay Bushinsky).

[Reactie gewijzigd door hardwareaddict op 24 juli 2024 03:12]

[Kaasbroodje]

Zoiets moet je dus niet doen bij echt belangrijke of gevoelige gegevens, ik kan je garanderen dat als ik je mijn dagboek zou geven je het wachtwoord als nog niet kan raden. Het is helemaal niet moeilijk om een wachtwoord van 16 echte random tekens te onthouden.

[hardwareaddict]

KaasOpEenBroodje(16) heb je er ook over gedacht om gevoelige gegevens helemaal niet op het internet te poten?

Wat ik hier gebruik is Air gap security.

http://en.wikipedia.org/wiki/Air_gap_(networking)

[Kaasbroodje]

de betreffende computer staat ook los van het internet maar mocht iemand hem willen komen halen dan is die gene even bezig.

en btw, dat is mijn wachtwoord niet

[Travelan]

95 is dan misschien niet heel reëel, in de meeste gevallen kun je met de helft prima aan het kraken gaan.

Maar dan nog heb je wel ergens een punt.

[Kaasbroodje]

95 is het aantal mogelijke tekens per positie, de 16 is het aantal posities van het wachtwoord. en als je bedoelt dat ze een aantal tekens uit kunnen sluiten dan zou je tegen een probleem aan kunnen lopen. Wat nu als je er de helft uitlaat, en één van die weggelaten tekens zit wel in je wachtwoord, dan kun je het nooit kraken.

[Reactie gewijzigd door Kaasbroodje op 24 juli 2024 03:12]

[hardwareaddict]

KaasOpEenBroodje - heh dat zijn er 16

[Kaasbroodje]

toevallig wel, maar gelukkig is dat het wachtwoord niet, ik wil je best de hash geven, kom je toch niet uit

[Lucien Shepherd]

ik denk als je dat doet met de nvidia titan serie dat je dan ook resultaat gaat zien.
volgens de hashcat zou deze versie Multi-gpu ondersteunen.
zelf heb ik altijd een beetje moeite om dit programmatje te draaien.

[Perkouw]

Ik ben bang dat voor dergelijke zaken AMD kaarten beter geschikt zijn. Net zoals NVIDIA kaarten het zwaar afleggen bij het minen van Bitcoins tegenover AMD kaarten. Puur een aanname, maar ik gok dat dit het geval is.

[Rafe]

Op de tweede pagina in de bron staan de snelheden van een Titan:

Hash.Type......: TrueCrypt 5.0+ / PBKDF2-HMAC-RipeMD160 / AES
Speed.GPU.#1...: 81497 H/s

Hash.Type......: TrueCrypt 5.0+ / PBKDF2-HMAC-SHA512 / AES
Speed.GPU.#1...: 38693 H/s

Hash.Type......: TrueCrypt 5.0+ / PBKDF2-HMAC-Whirlpool / AES
Speed.GPU.#1...: 10800 H/s

Hash.Type......: TrueCrypt 5.0+ / PBKDF2-HMAC-RipeMD160 boot-mode / AES
Speed.GPU.#1...: 163.0 kH/s

Is dus inderdaad langzamer.

[Reactie gewijzigd door Rafe op 24 juli 2024 03:12]

[gerwim]

Langzamer, ja -- behalve voor de Whirlpool hashes:

1x 7970:

Hash.Type......: TrueCrypt 5.0+ / PBKDF2-HMAC-Whirlpool / AES
Speed.GPU.#1...: 3572 H/s

1x Titan

Hash.Type......: TrueCrypt 5.0+ / PBKDF2-HMAC-Whirlpool / AES
Speed.GPU.#1...: 10800 H/s

.

Dat is zo'n beetje een factor 3 sneller.

[analog_]

In perspectief betekend dit even berekend voor SHA-512.
Hashlength van sha-512 met best attack is 2e32.5. Met de gepubliceerde snelheid van ~50khashes (uit hoofd, heb exacte getal gebruik in berekening) komt dat per jaar neer op 1.3795423e+12 hashes voor één jaar. Als je denk, ok dan meer kaarten, je hebt er 4.5845316e+20 nodig. Dus vergeet dat dit een potentieel gevaar vormt momenteel maar, dit is wel een versnelling maar verwacht geen rainbox table toestanden momenteel.

[teddysleep]

Is het minen van Bitcoins legaal?

[Anoniem: 390875]

Ja - alhoewel er eigenlijk niet een éénduidig antwoord op is. In sommige landen (geen idee hoe dat in NL zit) mag je bijvoorbeeld niet een algemeen betaalmiddel op de markt brengen, vandaar ook dat je vaak bij 'gift cards' niet cash geld ervoor kunt krijgen, alleen maar een aankoop ermee doen, bij een selecte groep (ook een boekenbon, bijv, is selectief, ook al kan je die dan wel bij bijna alle boekenwinkels inleveren).

De vraag wordt dan echter weer of jij nou de Bitcoin op de markt brengt door het minen, of dat die er al is, en jij 'm alleen maar ontdekt.

Vooralsnog is er omtrent die kant in ieder geval niet echt regelgeving. Voor andere aspecten zal je bijv. bij de belastingdienst aan moeten kloppen

[teddysleep]

Bedankt allemaal voor de reacties, was zeer nuttig
Ik heb juist dit filmpje nog is bekeken en nu snap ik het
http://www.youtube.com/watch?v=GmOzih6I1zs

[Reactie gewijzigd door teddysleep op 24 juli 2024 03:12]

[BLACKfm]

Het lijkt mij niet alleen legaal, het is juist de bedoeling omdat je anders geen coins krijgt...

[Anoniem: 390875]

Dat is niet helemaal juist. Bij een transactie kan ook een fee ingesloten worden. Zeg maar ik maak van mijn 10BTC, 1BTC over naar jou, 8.9BTC over naar mezelf, en 0.1BTC voor de miner die m'n transactie valideert. Ik zou ook 0BTC kunnen insluiten, met als mogelijk probleem dat het een stuk langer gaat duren voordat de boel gevalideerd is.
Als eenmaal 'alle' 21 miljoen BTC die je nu nog als reward kan krigen op zijn, zal juist de fee de manier moeten worden om BTC te 'verdienen' met puur en alleen het 'minen' (op dat moment niet echt 'minen' meer, maar goed).

[koelpasta]

Ja maar er wordt dan ook nergens gesuggereerd dat je alleen aan block reward kan verdienen als je miner bent.
Hoe dan ook zal het minen gewoon door moeten gaan, zelfs als alle coins gemined zijn. Op dat moment wordt alleen de block reward op nul gezet. Je krijgt dan naast de fees niks extras voor het maken van een nieuw block.

Er is technisch dus geen verschil tussen minen voor block reward en minen voor fees.

[Reactie gewijzigd door koelpasta op 24 juli 2024 03:12]

[mcDavid]

Nvidia GPU's schijnen heel slecht te presteren op ditsoort klusjes. Het is niet voor niets dat 95% van de bitcoin-miners voor AMD-kaarten kiest.

[hardwareaddict]

Voor priemgetallen is het weer net andersom - daar is Nvidia stevig sneller.

Zo is bij AMD de 32 x 32 bits multiplicatie takketraag. 24x24 bits gaat dan wel weer snel, maar 32x32 moet je dus alle 4 de processing elements van een compute core gebruiken, terwijl Nvidia dezelfde snelheid is op 1 core op 32x32 bits.

Op het moment dat je dus niet zoveel hoeft te vermenigvuldigen en simpelweg wat XORs kunt nemen en wat bytes verplaatsen dan is AMD heel snel.

De wetenschappelijke wereld heeft voor 99% alleen snelle vermenigvuldiging nodig. Overigens die willen dat dan niet met unsigned integers doen, maar die modelleren dat complex en dat gaat dan weer relatief simpel (niet noodzakelijkerwijze sneller) in double precision floating point. An sich zouden 64 bits integers dus sneller zijn, maar dan moet je ook modulo berekeningen snel kunnen doen (en dat lukt ook op Nvidia niet zo heel fijn, laat staan AMD).

AMD doet allerlei mooie claims daar met betrekking tot de snelheid op haar GPU's, als we kijke nwat per saldo is geimplementeerd, dan heeft Nvidia een voorsprong van lichtjaren op AMD daar.

Nvidia levert een prima library met een snelle fourierimplementatie die je zo kunt transformeren naar een snelle FFT (of in priemgetalwereld wordt veel gebruikt DWT) of wat dan ook.

AMD heeft daar helemaal niets wat zoden aan de dijk zet. Er zijn 2 Pakistani's die wat geprobeerd hebben met een hele trage vorm van FFT, wat gewoon onhandig is om te gebruiken op een grote supercomputer. Dat is dan eigenlijk ook enige wat AMD heeft.

Dus als je grote rekenpartijen wilt gaan doen, en het gros van de rekenkracht van supercomputers gaat naar enorme matrixcalculaties, dan ligt AMD mijlenver achter.

De vraag is of het handig is voor bepaalde organisaties om daar te wachten tot AMD over de brug komt, of dat ze zelf moeten gaan pielen en gewoon proberen iets snels neer te zetten op AMD hardware en dan vergelijken hoe snel het is objectief versus Nvidia.

Hierover zijn de meningen verdeeld (mijn mening is dat je niet moet wachten - maar het feit dat ik dat al neerschrijf moge het duidelijk maken).

Wat voor de einzelgangers het thuis niet eenvoudiger erop maakt is dat AMD al jarenlang allerlei beloftes niet nakomt.

De kritiek die je al in dit artikel leest op AMD's functioneren in deze is compleet alleszeggend. Wetenschappers uiten kritiek niet zo snel.

[Bio1ogics]

En waarom werkt een pincode van 4 cijfers (max. 10000 mogelijkheden)?
En daarom begrijp ik niet goed waarom 'men' zoveel moeite stopt in encryptie, of bv two-factor-authentication, als een oplossing als een toenemende time-out na elke foute inlog-poging veel eenvoudiger is.

[Kaasje123]

Hoe wil je toenemende time-outs voor het berekenen van hashes toepassen dan? Dat kan namelijk helemaal niet.

[i7x]

Een pincode werkt omdat je pas na een paar foute pogingen al wordt geblokkeerd. Dit is onmogelijk in het geval van truecrypt containers. Hier kun je zoveel mogelijkheden op loslaten als je wilt. Overigens is dit ook niet te voorkomen. Er zijn wel wat harde schijven die zichzelf blokkeren na een aantal foute pogingen maar dit is slechts schijnveiligheid als je de techniek erachter bekijkt. Meer iets voor CSI waar ze maar een paar pogingen hebben. Totale onzin en onrealistisch.

Overigens doet dit programma niets af aan de veiligheid. Mensen die truecrypt gebruiken versleutelen waarschijnlijk data die zo belangrijk is dat hun password niet uit 6 letters zal bestaan. Kies een goed random password van 20 tekens en je bent al een paar eeuwen dood voor iemand dat wil kraken.

[Kaasje123]

Kan de Amerikaanse overheid er niet veel meer doen per seconde? Volgens mij schiet je zelfs nu nog niet veel op als je een goed random password met keyfile gebruikt. Of moeten we ons nu ineens zorgen gaan maken?

[JeroendeGroot]

Die vergelijking lijkt me wat zinloos, aangezien dit artikel specifiek op eem set GPU's is gebaseerd en niet op de Amerikaanse overheid met weet jij veel hoeveel gpu/cpu kracht. En je hoeft je natuurlijk niet direct zorgen te maken. Zulke stukken software zijn juist ook heel zinvol bij het verbeteren van hashing algoritmes.

[Reactie gewijzigd door JeroendeGroot op 24 juli 2024 03:12]

[Kaasje123]

Ja maar dat vraag ik omdat als de FBI de boel al niet kan kraken dan hoeven we ons echt geen zorgen te maken over een hobbyist hier wat mee opschiet. Zie ook hier in de eerste uitleg van hun FAQ waarin naar een artikel wordt verwezen waarin staat dat het hun ook niet lukt. http://www.truecrypt.org/faq

[tedades]

Ze kunnen natuurlijk ook een keylogger op je systeem zetten en zo achter je wachtwoord komen. Of ze vragen het je vriendelijk natuurlijk.

[Seal64]

Zo bedoel je?
http://xkcd.com/538/

[TonnyTonny]

Gitmo vriendelijk....

[freaq]

of ze vragen je het te openen, en als je het niet doet ga je de gevangenis in tot je dat wel doet, of de technologie het toelaat om je bestanden wel te openen,
want als je denkt dat het veilig is (want het duurt 30 jaar) dan moet je niet vergeten dat het elk jaar ongeveer 30-40% minder tijd gaat kosten, en dat neemt nog niet eens de mogelijkheid tot betere algoritmes in acht....

kortom, niets is veilig, ook geen 256 bit AES met geheimen van de overheid zoals online geplaatst door Assange, over enkele jaren (mogelijk 10tallen maar toch) zal dat redelijk te kraken zijn, en zal dat (mits er interesse is) ook echt wel gebeuren....

[Adamar]

Inde veronderstelling dat het nog steeds over de FBI gaat. Amerikaanse burgers zijn beschermd door het 5th amendment, meer bepaald het stuk "Self incrimination".

The Fifth Amendment protects witnesses from being forced to incriminate themselves.

http://en.wikipedia.org/w...tution#Self-incrimination

En als ze geen bewijs kunnen vinden kunnen ze je moeilijk vasthouden.

Van de FBI hoef je geen schrik te hebben. Pas als de CIA of NSA zich gaan moeien zit je met een probleem.

[useruser]

The Fifth Amendment protects witnesses from being forced to incriminate themselves.

In Nederland hoef je ook niet mee te werken aan je eigen veroordeling. Toch willen ze in Nederland de verplichting instellen om wachtwoorden af te geven...

[The Reeferman]

De rechten in de ''Bill of Rights" zijn, zeker sinds 9/11, niet meer zo'n zekerheid als ze ooit waren. Engeland heeft al een wet waardoor je in de gevangenis kan komen als je weigert je wachtwoord af te staan. En in een boel landen word je desnoods gemartelt tot je hem prijsgeeft of de dood er op volgt.

De NSA is trouwens een computer centrum aan het bouwen om encrytie te kunnen kraaken, doel is alles aan te kunnen. Ze hebben er 3 milljard dollar voor uitgetrokken. Vraag me af hoe ver ze daar mee komen, maar dat zullen ze voorlopig niet openbaren.

[Atmosphere]

..witnessess..

maw getuigen, het verhaal wordt anders als je verdachte bent!

[_Pussycat_]

De snelheid van CPUs groeit al steeds langzamer en zal ook eens ophouden, bovendien heb je met een iets langer wachtwoord het al over ettelijke duizenden jaren.
Eerder moet je je zorgen maken dat quantumcomputers bruikbaar worden; dan zouden alle wachtwoorden kraakbaar kunnen zijn.

[mrdemc]

Uiteraard krijg je dan ook algoritmes die op basis van quantumtechnologie werken, dus dan heb je dezelfde processingratio als dat je nu hebt met normale computers en de huidige algoritmes. In principe..

[Adamar]

Daar hoeft niet perse iets strafbaar op te staan hoor.

Het is het principe van privacy, dat is PRIVE en daar heeft niemand zakens mee.

[OMX2000]

Wat nu onschuldig is, is misschien morgen enorm verdacht.

[Megamind]

Gebruik een keyfile van 1024bytes en deze tool heeft er alsnog 15 jaar voor nodig.

[Anoniem: 80466]

Een keyfile kan in de handen van eimand anders vallen

[hav0c]

Met 1 kaart heb je gelijk. Met een array van 1000+ kaarten gaat het uiteraard aanzienlijk vlotter.

[GMJansen]

Tss, dacht dat er iets op m'n scherm liep

[engelbertus]

mijn vrienin dacht dat ook eens. ze krab een keer.. en roept. "hij zit er in!"

haha wt moest ik lachen......

[hardwareaddict]

@megamind nee joh, over 15 jaar vinden ze wel weer een truuk om de nieuwe kraaksoftware zo traag te laten zijn dat zelfs een 8 letter password al enige tijd kost om te kraken

Je wilt toch niet dat een dombo die net slim genoeg is om kraaksoftware te draaien, dat hij 't voor elkaar krijgt om 95% van alle passwords te kraken?

Dus wat je doet elke paar jaar is weer nieuwe kraaksoftware uitbrengen die trager werkt om passwords te vinden...

[Ayporos]

Gewoon zorgen dat je 1024 of 2048bit encryptie gebruikt als je echt zo paranoide zijn.. nòg beter is uiteraard je 'gevoelige' data niet aan het internet hangen.

Uiteraard is het niet de bedoeling dat mensen je password hash in hun poten krijgen... maja.

[Dorank]

En hoe wordt die key beschermt? Met een relatief veel zwakkere passphrase!

[Perkouw]

Indrukwekkend, maar zoals hierboven gezegd ben je alsnog jaren bezig wil je het kraken natuurlijk. Wat ik dan wel weer interessant vind, wat als iemand zo handig is om gebruik te maken van cloud-services om dit te gaan kraken. Zoiets is meen ik al eerder gedaan voor WiFi netwerken o.i.d. Twee kaarten stellen niet zoveel voor. Maar let's say, 200, bijvoorbeeld wordt het al een stuk interessanter.

Ik blijf dit soort dingen toejuichen opdat de ontwikkelingen m.b.t. encryptie door blijven gaan en alleen maar beter en zwaarder zullen worden.

[RoestVrijStaal]

Ik blijf dit soort dingen toejuichen opdat de ontwikkelingen m.b.t. encryptie door blijven gaan en alleen maar beter en zwaarder zullen worden.

Dat mag wel leuk zijn, maar op zo'n manier wordt de encryptie enkel toegankelijk voor degenen die het kunnen betalen. En een nieuw en beter encryptie algoritme is ook niet zo in 1 2 3 bedacht.

[Perkouw]

Want TrueCrypt is nu ook betaald ? En diensten als Mega die nu gratis 50GB encrypted en wel leveren gaan dan ook ineens grof geld rekenen omdat ze een zwaardere encryptie gaan toepassen ? Sorry, maar je logica volg ik gewoon niet helemaal.

[hardwareaddict]

Ja joh laat ze vet dokken - zijn toch grotendeels criminelen die 't gebruiken voor illegale FTP -servers en websites...

Wat natuurlijk nog handiger is, is om aan te kondigen dat gehackte versies automatisch ervoor zorgen dat de security heel laag is en dat de stichting Brain weet hoe of ze daar doorheen moeten komen

Sommige van die gasten verdienen daar honderden euro's per maand mee maar zelfs de sofware die ze gebruiken is nog niet legaal

[RoestVrijStaal]

Om dingen te versleutelen is ook rekenkracht nodig.
Nu hebben we nog algoritmes en hardware waarbij encryptie amper een financiële / 'praktisch' nadeel heeft (Al gaat het werken met de pc al trager als je je hele schijf versleutelt met bijv. BitLocker of het openen met vertrouwelijke gearchiveerde documenten).
Echter als al die algoritmes gekraakt zijn en er is niets nieuws meer voor handen, dan is er een probleem.

[Adamar]

Waarom dat? De meeste programma's kosten niet meer dan €100 en zijn gebaseerd op (vrij beschikbare) standaarden zoals oa AES.

Het voordeel is eigenlijk dat zulke ontwikkelingen goed zijn voor de consument. Want stel dat encryptie zoals AES gekraakt wordt moet de Amerikaanse overheid op zoek naar een nieuw veiliger alternatief. Dat wordt tot standaard verheven en daar worden programma's rond gemaakt die eigenlijk weinig kosten omdat ze zelf geen geld hebben moeten steken in het ontwikkelen van de encryptie, enkel maar het implemeneteren. De overheid heeft dat namelijk al betaald of via een wedstrijd gekregen.

En als het voor de Amerikaanse overheid veilig genoeg is, voor mij dan ook.

[Anoniem: 132566]

Dus de les is: voor Whirpool kiezen?
Hoeveel bits is het password dat je in kunt stellen ook alweer?
Dan mag je een behoorlijke Dictionary in elkaar sleutelen met x^y aan mogelijke tekens binnen ASCII 26 en 132, knap dat zo'n setup zoiets kan kraken...
Als hij iets revolutionairs bedacht heeft hiermee, dan is het PDB2K voor WPA2 (wifi) ook zo bloot te leggen, daar is minder firepower voor nodig, qua hashen/salting- TrueCrypt is toch een wat hardere noot, met 512AES lijkt mij.

[ro8in]

Dat is behoorlijk snel. Hoe snel doet hij gemiddeld over een normale md5 hash dan? in dagen/weken/maanden uitgedrukt?

[hardwareaddict]

Dan zet je 5 nullen erachter

[Mathijs1]

servertje @ work doet 8.2+ miljard md5 hashes per seconde met 2 Tesla GPU's, dat gaat dus een heel stuk rapper

[Reactie gewijzigd door Mathijs1 op 24 juli 2024 03:12]

[Biersteker]

Ben benieuwd hoe het werkt tegen Serpent-TwoFish-AES/Whirlpool. Denk dat het alsnog niet veel zoden aan de dijk zet.

[- peter -]

Op Ars Technica hebben ze een aantal goede artikelen gehad over crackers, en t bleek dat ze veel slimmer waren dan gewoon random proberen. Door intelligente regels kraakte men zo 60 procent van een hashlist in 4 uur. En daar zaten heel ingewikkelde passwords bij. Al waren passwords langer dan 10 chars wel idd veel moeilijker.