Hey there! My name is Ravi, and I am an independent advisor. I am happy to help you. :) I understand you're trying to log into your laptop but it's locked by BitLocker. If a user doesn't have a BitLocker Key, there's no way to bypass it. The only option is to do a clean Windows installation that will delete everything. A user can find the BitLocker Key from the same account used to activate it. Open a web browser on another device. Go to https://account.microsoft.com[...] to find your recovery key. If your device was ever signed into an organization using a work or school email account, your recovery key may be stored in that organization's Azure AD account. You can check all possible places to find a BitLocker Key here: https://support.microsoft.com[...] Important: Microsoft support is unable to provide, or recreate, a lost BitLocker recovery key. Feel free to get in touch again if you have any additional questions. Cheers, Ravi måske forsøget værd? https://www.partitionwizard.com[...]
--
jep jep
--

Sidst redigeret 02-07-2024 15:03

Hvis der ikke findes en recovery key, så kan du godt glemme at få adgang til drevet.
--
http://xlinx.dk[...] i7 2600K, 16GB PC3-12800, GA-Z68XP-UD4 R1, GTX 560Ti HAWK, 250GB 840 EVO

okay tak for svar, var desværre det jeg var bange for :(
--
life is guuut :D

Jeg plejer at bruge Bitlocker til at rense diske med, hvis jeg ikke har en Dban boot usb i nærheden.
--

Du kan prøve at skrive til NSA. De har en bagdør i Bitlocker ;) Spøg til side, har du mulighed for at sætte disken en anden maskine? Eller hvordan opføre den sig?
--

Hej. Hele pointen med bitlocker er at kryptere din harddisk for a beskytte din data mod F.eks at nogen stjæler din laptop og vil kopiere data ud fra disken. havde der været en “smutvej” til at slå bitlocker fra ville funktionen være meningsløs. hvis du ikke har recovery Keys til bitlocker må du desværre se det data som slettet/forsvundet, det kan ikke genskabes uden. de har ikke tilfældigvis OneDrive vel? Normalt laver dem backup af standard bruger foldere nutildags
--

#OP Hvis ikke du kan faa liv I den gamle TPM chip og ikke har en recovery key saa er der ikke mget at goere. men hvis du kan faa liv i den gamle TPM chip kan koden hentes ud med diverse sjove programmer #4 dumb metode Brug diskpart clean all I stedet for. Mere sikkert. #6 Hvis nogen stjaeler en laptop er det muligt at hive key ud af TPM chip og afkode disken. Det er mere til naer HDD bliver separate fra harddisk. Det er natuligvis ikke her og fru jensen der kan goere det.
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury

Det lyder helt tosset at der skal en recovery key til, som er genereret af Microsoft. Havde det nu været en kode kendt af brugeren, som var kørt igennem en hash algoritme (sha512 etc), så var problemet løst. Så kunne den blot aflæses på en nye computer. Så er #0, out of luck. Han kan evt. tage computeren til reperation. Det kan være nogle simple og billige komponenter der er brændt af/kortsluttet.
--

#8 Hvad er det du mener helt praecist er tosset? En bruger kan ikke indtaste en noegle til bitlocker foer OS er loadet. Os kan ikke loades naar disken er krypteret saa for en OS disk bliver krypteringsnoeglen lagt I TPM chip og BRUGEREN faar en recovery key. Denne recovery key kan blive backet up automatisk paa din Microsoft konto. I dette tilfaelde er OP loebe ind i en del daarlige vaener 1: Bruger har ikke gemt deres noegle 2: Bruger har ikke lavet backup af deres noegle 3: TPM chip er I udu Der ville ikke vaer forskel om bruger havde et kode ord (hvilket jo storset er det samme som den gevet recovery key. noeget du skal huske) Hvis de har valgt at gemme og ikke tage backup af et kodeord ville det vaere det samme. Derefter saa ville du ALDRIG koer et kodeord igennem sha512 alene for at skabe en kryptreings noegle. Der er simpelthent for hurtigt og der er ikke bruge for 512bits til en 128/256 bit noegle Det virker altsaa lidt som om du laver lidt buzzword dropping uden at vide hvordan kryptering virker
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury
--

Sidst redigeret 03-07-2024 05:41

Jeg kender overordnet og grundlæggende til hvordan kryptering virker, men dykker du ned i de matematiske algoritmer, kommer jeg til kort. Jeg kender ikke det helt store til Bitlocker, men derimod Cryptsetup på Linux. Jeg køre selv med aes-xts-plain64 og 512 bit cipher key (derfor jeg bruger sha512 til password). Jeg har 2 keyslot aktiveret, en med kode og en med nøgle-fil. Hvis en fejler, kan jeg altid falde tilbage. Jeg har lige indsendt min bærbar til reparation og derfor flyttet min krypteret OS disk over i en anden bærbar. Jeg indtaster koden ved boot og køre videre. Det er netop det #0 ikke kan og derfor mener jeg det er helt tosset, at miste data på den måde. Microsoft kunne vælge at gøre det samme for deres Bitlocker, ved at oprette en kendt kode brugeren kan falde tilbage til. Et keyslot med TPM key kan samtidig godt eksistere. Designet med Recovery key ser jeg mere gavne Microsoft, der åbner op for at høste Bitlocker adgang og brugerdata i form af en Microsoft konto (giver en key, profilering kan samles omkring). Jeg er bekendt med Recovery filen kan gemmes lokalt på andet medie eller printes ud. Men det er nu besværligt og ikke ret brugervenligt kontra en kode brugeren kender. Koden kunne dog endda køres igennem sha256/512 (for at undgå cleartekst) og gemmes på medie/printes ud for maksimalt sikkerhed. Med tanke om at Microsoft gerne vil tvinge Bitlocker ned over brugerne med den kommende Recall funktion, åbner det op for store datatab for den uopmærksomme bruger. Jeg synes godt nok det er helt ude i hampen og ja et tosset system :)
--

Sidst redigeret 03-07-2024 09:32

Kan se man By-pass TPM og i stedet oprette et password der skal tastes ind hver gang systemet startes. Så Bitlocker har funktionaliteten, men ikke noget der er let tilgængeligt. Det kræver Gpedit. Men der oprettes stadig en Recovery key, så går der noget galt, er man stadig prisgivet i den situation såfrem man ikke har backup af nøglen. Kan se recovery key kun består af tal. Gad vide om den kan bruteforces. Det skal da undersøges nærmer :)
--

Men som sagt tidligere, så ligger kodeord også på ens MS profil under https://myaccount.microsoft.com[...] så der kan man være heldig at den står der.
--

#12 You can't sign in here with a personal account. Use your work or school account instead.
--

#7 kører disk part clean all en zero på hele disken? #8 Bitlocker understøtter også en valgfri kode ved boot uden brug af TPM chip og andet, der låser den til et specifikt system.
--

#14, det fandt jeg ud af. Der skal du ind i Gpedit :)
--

#10 hvad du siger et hellt 100% ikke korrekt. "Jeg køre selv med aes-xts-plain64 og 512 bit cipher key (derfor jeg bruger sha512 til password" lad os bbryde denn her ned AES - du bruger AES synkron cyrpterings metode. ogsaa har kun en key cipher size paa 128,192,og 256bits. Saa dette her passer altsaa ikke "512 bit cipher key" du kan ikke vaer AES hvis du har en 512bit cipher eller omvend AES har ikke en 512bit Cipher key mulighed. XTS - dette er din metode til hvordfna krypterings bleve lagt paa data og XTS er ganske fin til HDD kryptering. samme som bitlocker bruger i windows after 7. (win 7 bruger CBC mode med elefant diffuer extra lgtin) XTS bruger halvedlen af den gevets bits til din AES cipher key i dit setup. Det er her du forveklser 512 bits med hvad du har a cipher keys. din cipher key er 256bits men din XTS "key" er 512bits SHA512 kan blive brugt til at genere dine key fra et password men det re et elendig valg. SHA512 er hashing og ikke en keyderivation function. forskellen ligger i formaal og ressource brug en hashging algortime er til at verificer dette og en formaal ydover god entropy spredning er at den skal vaere "hurtigt" jo hurtiger (uden tab af andne funktionalitet) jo bedre end KDF er omvendts. en KDF skal vare saa langsom og ressource kravende som muligt for netop at goer det svaere at bruge password baseret bruteforcing samt dens accelered version sasom dictionary sizes Gode KDF idag er argon2 eller PKDB hvis du du er et sted der skal audites efter standar soem DOD og NIST. hvis ikke kan du evt ogsaa bruge Brcrypt og Scypt. jeg vil personligt altid anbefale argon2 pga den er isaer robust imod GPU hardware som f.eks sha2 absolut IKKE er. SHa 2 blierr du brugt flitte som message digest for digital signature i f.esk TLS kort opsumering 1 Det er ikke din cipherkey der er 512 bits. AES tager kun op til 256bits. 2: hvis du bruger sha2 til key generation goer du noget temmeligt elendigt setup. Jeg vil tro du bruger noget bedre men har mistforstaet hvor du bruger sha512. og det er din hash/digets key og ikke din til cipher key generation "Det er netop det #0 ikke kan og derfor mener jeg det er helt tosset, at miste data på den måde" Hvad sker hvis du har glemt din password ? og ikke har gemt din noeglefil Det er simpelhent det der er sket her. OP's kunde har ikke gemt ders passwor/noegle fil. om det er en recovery key eller et password er helt 100% det samme. om det er noegelfil eller gemt den recovery fil de faa saa er det igen det samme saa igen hvad er du du mener eder er tosset ved at man ikke kan komme til sine kryptere data naar man ikke har sin "secret"? Den eneste forskel er her at OP's kunde OGSAA har en ders key gemt i en TPM som en EXTRA mulighed ud over password og noegelfil. du har saa valgt udelukkende at bare afhaenging af TPM til at haandter krypterings noeglen saa hvis man lige faor at ojebliek stopper med *nix fanatikken. sa vil du see at det er intet tosset i hvad microsoft har lavet her og hvad du snakker burtde foreggar er praecist hvad der foregik. blot bruger fejl og intet med haandtret af kryptering der er galt. "Men det er nu besværligt og ikke ret brugervenligt kontra en kode brugeren kender. Koden kunne dog endda køres igennem sha256/512 (for at undgå cleartekst) " Det er svaert mere brugevenligt end at lade TPM haandter det hele og ikke skulle taenke over haandtering i det hele. det faktum at du skal indtaste dit krypterings password i din egen sitatuion er mere bruger uvenligt. spoegs hr og fru jense om det helst vil havde det automatisk eller skal huske et kode ord hvergang. og igen sha512 burde ikke bruger som KDF. Det er en skidt metode for at undgaa cleartext SHa512 kan simpelt "brydes" med rainbow tables saa er det irrelevant om det var brugt i clear text text eller ej "Med tanke om at Microsoft gerne vil tvinge Bitlocker ned over brugerne" Hvor gommer denne nye ting fra. OP's bruger havde helt frihed ove det. igen lyder dette her some mere nix fanatism en noget der har hold i den virkelige verden
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury

#11 Du kan brute force alting du har offline adgang til Igen det lyder som om du virkelige proeve at hakke paa microsoft over *nix fanatisme #14 JA og fordelen er her at du ogsaa tager MB/GPUID med i svinget Ved bitlocker kyrptering goer du det langsommere (flaskehalse vil udligne dette) da du skal bruge extra cpu krafter paa krypteringen. og ved bitlocker har du ren matemetistk 1/128^2 chance for at gaette krypterings noeglen med mdirne du koer med din aes paa 56bit saa er det naturligvis 1/256^2 I begge tilfaelde er det det hoejre end 0 chance ved overskrivning opsumering: mindre ressource brug. lidt bedre sikkerhed
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury

#10 Jeg glemte disse 2 " Jeg har 2 keyslot aktiveret, en med kode og en med nøgle-fil. Hvis en fejler, kan jeg altid falde tilbage." Igen det er jo NETOP hvad de har via deres microsoft bruger konto. Saa ALLE de ting du naevner mangler... ER til stede. "en kode brugeren kende" Jeg gaa ud fra her du mener her lavet som er nemt at huske.. fordi de kender jo koden hvis de havde husket at gemme den. Problemmet her med idn loesniing er et bruger generet koder er typeisk elendig entropy maessigt. hvilket netop er grunde til at vi bruger dictionary attacks. Dette er NETOP grunde til at vi bruger KDF som tidligere naevnt for at sloeve kodeord til key generations tiden. saa hvis vi tager dine anbefalinger her som angievet saa vil vi havde 1: et risiko for at svagt password 2: en elendig KDF function 3: intet salt ( du naevnte det aldrig) Det er en perfekt opskrift for elendig kryptering der er nemt af lave password brute forcing paa. absolut ikke en god maade at haandtere data sikkehed paa
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury

#16, jeg tror gerne du vil misforstå det jeg skriver. Jeg bruger Cipher key på 512bits ved aes-xts-plain64. Jeg har på intet tidspunkt skrevet jeg bruger mere end AES256, som er begrænsningen for algoritmen. By default a 512 bit key-size is used for XTS ciphers. Note however that XTS splits the supplied key in half, so this results in AES-256 being used. https://wiki.archlinux.org[...] Min password er genereret ud fra et saltet SHA512, dvs. matchende bits og dermed maksimal sikkerhed og ingen svage punkter. Jeg kan let generere det +100 karakter password, ud fra et mindre kompliceret password. Header fra Cryptsetup luks: Data segments: 0: crypt offset: 16777216 [bytes] length: (whole device) cipher: aes-xts-plain64 sector: 512 [bytes] Keyslots: 0: luks2 Key: 512 bits Priority: normal Cipher: aes-xts-plain64 Cipher key: 512 bits PBKDF: argon2i Time cost: 18 Memory: 1048576 Threads: 4 Salt: ea 7e d2 81 4e 46 20 e2 b5 43 f3 e5 15 86 1e 40 28 9d aa 29 26 da 44 e1 78 b3 ed 59 90 1d 14 8e AF stripes: 4000 AF hash: sha512 Area offset:32768 [bytes] Area length:258048 [bytes] Digest ID: 0 (...) om det er en recovery key eller et password er helt 100% det samme. Det bliver vi ikke enige om. Password har du tilknytning til (noget du ved), kontra en recovery key (noget du har). Jeg vil altid foretrække password da det kan genskabes. Det andet kan mistes uigenkaldeligt - både nøgle-fil, TPM, Recovery key etc. Igen det lyder som om du virkelige proeve at hakke paa microsoft over *nix fanatisme Jeg er kritisk overfor Microsofts valg og synes det er med rette. Det er #0 desværre eksempel på. Der er plads til klar forbedring. Omvendt virker du meget beskyttende overfor alt hvad der hedder Microsoft :)
--

#0 Hvis bitlocker recovery koden ikke ligger i brugerens egen MS konto, så er der god chance for at den ligger enten i Azure/Entra, eller på en AD server ved hans firma. Det er de to steder jeg ville grave eller rette en forespørgsel. Hvis altså det er en firma bærbar, eller han på noget tidspunkt har logget ind med sin 365 arbejdskonto/joinet den til AD domæne. Kan selvfølgeligt også være han har oprettet det med en usb pind, som så er forsvundet, men det kunne han evt. lede efter
--
Du er altid velkommen til at sende en besked hvis jeg ikke ser din kommentar
--

Sidst redigeret 03-07-2024 17:18

Hvor gommer denne nye ting fra. OP's bruger havde helt frihed ove det. igen lyder dette her some mere nix fanatism en noget der har hold i den virkelige verden Windows 11 24H2 will enable BitLocker encryption for everyone — happens on both clean installs and reinstalls https://www.tomshardware.com[...]
--

Sidst redigeret 03-07-2024 17:18

#10 Glemmer du ikke hele idéen med root of trust. Du tager din harddisk og sætter i en ny pc, indtaster password for at dekryptere og køre videre. Fint og alt vel - hvis du ikke vil have hardware root of trust. Jeg synes du kigger på problematikken ud fra et "forkert" synspunkt, når du kommer med din kritik. Skal man f.eks. indtaste et password, kan krypteringssoftwaren jo ikke umiddelbart stole på, hvem der indtaster koden. Fra krypteringssoftwarens synspunkt, kan det jo være en bandit, der har fået fat i passwordet f.eks. via Keylogger. Eller harddisken er blevet installeret i en pc med noget mellemliggende hardware/software, som manipulere med passwordet. Så fra harddiskens synspunkt kan den hverken stole på dit password eller på den hardware, du har installeret din harddisk i. Når du gør, som du gør og opfatter det som sikkert, er det fordi du ved at du indtaster det rigtige password. Det ved harddisken/krypteringssoftwaren bare ikke. Den eneste måde harddisken/krypteringssoftwaren kan være (noget nær) sikker på noget, skal der ikke komme noget "udefra" f.eks. password fra brugeren, men fra et sted i et "lukket" system" Et "lukket system" du som bruger ikke er en del af. Når jeg skrev tidligere skrev forkert i anførselstegn, skyldes det, at jeg synes din kritik er forkert ud fra en sikkerhedsmæssigt synspunkt, men rigtig ud fra en bruger-synspunkt. Hvilket vel egentlig skitsere en fundamental problematik mellem 2 konkurrerende behov: for sikkerhed og brugervenlighed. I OPs eksempel er problematikken jo så opstået grundet manglende kendskab til at bruge systemet og den funktionalitet, den tilbyder. F.eks. lave en recovery-key. Havde vedkommende haft sin recovery-key, havde der ikke været noget problem, vel? Skal man så også kritisere en løsning, der baserer sig på f.eks. password, hvis brugeren glemmer sit password? P.S. Jeg ved ikke specielt meget om den slags, så det er bare et par strø-tanker jeg giver.
--

#22 Det ene er ikke nødvendigvis mere sikkert end det andet, da sikkerheden ligger i implementeringen. En harddisk er "dum", og derfor kan den ikke se, hvad der forsøger at få adgang til den. En hardware-baseret RoT (eks. TPM), kræver et software-lag, som kan manipuleres. Uanset om en drev er krypteret med eller uden RoT-hardware, så kan det falde for et "brute force" angreb. Hvis et drev er krypteret med hardware-baseret RoT, og denne hardware går kaput, så mister man den legitime adgang til sine krypterede data, med mindre man har en recovery-nøgle. Har man en recovery-nøgle, som kan omgå RoT, så er RoT jo i og for sig allerede sat ud af kraft. RoT = Root of Trust.
--
http://xlinx.dk[...] i7 2600K, 16GB PC3-12800, GA-Z68XP-UD4 R1, GTX 560Ti HAWK, 250GB 840 EVO

#23 Skulle det have været mere sikkert, skulle der naturligvis ikke have været muligt at lave en recovery-key. Så det viser jo konflikten mellem sikkerhed og brugervenlighed. Jeg bruger harddisken som illustration af synsvinkel.
--

Sidst redigeret 04-07-2024 15:17

#22, jeg er enig med dig i, at sikkerhed strækker sig meget længere end password og recovery-key. Der er mange scenarier der skal tages stilling til og der er forskellige use-cases. Mit kritikpunkt hos Microsoft går hovedsageligt på at der kun er to indgange til deres kryptering default. Begge er "noget du har" (TPM/Recovery-key). Det gør krypteringen yderst sårbar, kontra et password "noget du ved". Bitlocker har dog mulighed for password+recovery-fil, men er ikke default - som du rigtig nok siger, brugervenlighed vinder over sikkerhed hos Microsoft. Ved at kombinere password og key-file så har du begge indgange: "noget du ved" og "noget du har", som er muligt i Linux verdenen. Luks har mulighed for op til 8 keyslot - dvs. du også kunne koble TPM på. 3 indgange giver 3 angrebsvektor, så det skal naturligvis opvejes i forhod til sikkerheds risiko. Fra krypteringssoftwarens synspunkt Jeg kan ikke helt følge dig her. Kan du prøve at uddybe? TPM'en ved heller ikke hvem der trykkede på start-knappen. Det kan være banditten har fået fysisk adgang til maskinen. Har du først fysisk adgang til en TPM maskine er løbet kørt, kontra et password giver en ekstra sikkerhed i den henseende.
--

#25 Jeg bruger krypteringssoftwaren som repræsentant for et sikkert, lukket system, der ikke er afhængig af eller kan by-pass´ noget udefrakommende, f.eks. password eller som Nitroblast jo så rigtigt skriver - en recovery-key. Og det er et lukket system qua RoT.
--

#26, det forstod jeg ikke så meget af :)
--

#27 Man skal vel indtaste det password, du ønsker dig, ind et eller andet sted. Så der skal et password ind i et lukket system, bestående af del-elementer, der stoler på hinanden. Et password, der kan være indtastet af dig eller en bandit, der har set dig over skulderen eller har haft en key-logger o.s.v. Sværere er min pointe sådan set ikke :)
--

#28, okay jeg forstår din pointe. Det du omtaler handler ikke så meget om krypteringen, men derimod sikkerheden omrking krypteringen. Der er der fordele og ulemper ved begge dele. Tyven kan også stjæle dit lukket system (bærbar etc) og have adgang, kontra ingen adgang ved password. Men der er omvendt risiko for brugeren bliver udsat for adpresning, vold, trusler mv. for at tilegne sig password'et. Men så er vi over i en anden snak, end det min kritik gik på :)
--

#29 Ja, Bitlocker reducere ikke alle risici som den ikke har lovet :)
--

#30, hvilke risici har Bitlocker lovet at reducere?
--

#31 Risicien for uautoriseret adgang til data.
--

#32, hvilket også har resulteret i en autoriseret bruger har mistet sin adgang til data ved simpel hardwarefejl. Recovery key kunne vel have været genereret på baggrund af noget brugeren kender ;)
--

#19 nej du goer ikke. jeg proeve ikke at misforstaa. Jeg forstar bare de ord du siger "Jeg bruger Cipher key på 512bits ved aes-xts-plain64" I dit AES-XTS-Plain64 der eer der kuin EN ting som er din ekcryptions chiper og det er AES. XTS er en blockmode at haandter block encryption paa. det ikke en cipher i sig selv. saa t sige du bruger en chiper key paa 512bit er forkert naar din cipher kun bruger en key paa 256? det kan godt avre du mente noget andet. men igen som jeg sade du bruger en masse ord forkert. Grunden til at du har en 512bit key/pool et sted er fordi XTS skal have sine egen 256 bits til at stare sine ini vectors d alle krytpre block modtager data fra en tidliger me nforste block har ikke en tidliger block saa dne skal have en ini vector det er ikke mig der deinre order chipherkey det har en hel special defination og du kan checke mig her https://www.velocenetwork.com[...] "At its core, a cipher key is a unique piece of information that is utilized by encryption algorithms to transform plaintext data into ciphertext and vice versa. " Dvs den 256key der gaar til din AES som er din cyrpterings aglortim dine restend 256bit bliver reelt set kun brugt paa din foerste block hvis du vil checke om jeg har ret kan du se her Itps://en.wikipedia.org/wiki/Disk_encryption_theory#XTS As a result, users wanting AES-256 and AES-128 encryption must supply 512 bits and 256 bits of key respectively. The two keys (i.e., both halves of the XTS key) must be distinct for XTS to be CCA-secure. saa igen din XTS fulde key er 512 bit din IV key er 256bits og din chiper key er og bliver nu kun 256bits Bemaerk at din egne liked documentatio nfortae3ller det samme og fortaeller IKKE at din CIPHER key er 512bits. du har valgt selve at kalde tingene noget andet end din documentation og det er det navn du har valgt at kalde det som er forkert Order "cihper key" eller "chipkerkey" bliver aldrig brugt i din documentation. Du har brugt en forkert term. "Min password er genereret ud fra et saltet SHA51" Jeg tror du mener din key er generet ud fra SHA512 over dit password. Det ville vaere underlig at geenre et password ud fra SHA512, isaer nar du siger du selv vaelger dit eget password. Disse to ting kan ikke vaere det samme. "matchende bits og dermed maksimal sikkerhed og ingen svage punkter" Jeg forstaar simpelhehen ikk hvad du proever at sige med matchend bits her, og maksimal sikkehed bliver det ikke at bare du erklaer edet. "Jeg kan let generere det +100 karakter password" Jeg gaar igen ud fra at du bruger ordet password her og mener key? Igen det er vigtige at kalde ting de rigtige navne. hvis jeg antager at du har vroevlet lidt rund her og har ment hvad jeg skrev du nok mener saa iver det lidt mening af hvad du skriver men du har igenmisforstaaet hvad der bruges til SHA512 i dit eksempel paa dit password bruger som skrevet oven for til at genre en IV key for din XTS mode og 256bits for din AES krypterings noegel... Ciphert Key., men det er ikke helt saadan det foregaar. som jeg skrev tidliger saa ville det alene vare temmeligt usikkert. Hvilekt ogsaa ewr hvorofr at DM-crypt bruge PKDF2 i foelge din dopcumentation altsaa praecist hvad jeg sagde de boer bruges og ikke blot SHA512 --iter-time -i 2000 5000 Number of milliseconds to spend with PBKDF passphrase processing. Release 1.7.0 changed defaults from 1000 to 2000 to "try to keep PBKDF2 iteration count still high enough and also still acceptable for users." Jeg kan saa se du har valt at koer plain so du har efter hvad jeg kan lease ( og tager fejl) ikke en KDF efter din SHA512. saa jo det er en usikker made at bruge sha512 alene til genering af din 256bit chipher ker er IKKE anbefalets or encryption da det simpehelt er for hurtigtg at t udfoere for offline attackers laes evt here https://security.stackexchange.com[...] "SHA-512 is not a key derivation function, it is a hash, it is the wrong kind of thing to use." mere tydelig bliver det vel ikke
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury

#19 "Det bliver vi ikke enige om. Password har du tilknytning til (noget du ved), kontra en recovery key (noget du har)" Du blander igen forskellige ting sammen Noge du ved og noget du har et mhen til authentication hvilket er en hel ande del af CIA pyramiden. I begge tilfaede aler vi om hvad vi kalder en "secret" laes evt NIST 800-63B publication. I begge tilfalde er der tale om noget et kort stykke information som du kan vaelge at huske eller gemme som en fil dvs det kan vaere et password eller en noeglefil. Hvad enten du mener jeg har ret eller ej goer ikke nogen forskel paa hvordan tinge relt set virker. det er korrekt at hvis folk selve kan definer deres password saa kan de lave noget de nemmer kan huske. men har skal vi huske paa at bitlocker er lavet til serioest/enterprise rug og ikke blot hobby/hjemmebrug. dvs vi kan ikke tole paa at folk kan lave gode password. der er tit og oftr at password har langt mindre entropy. Hvilket NETOP er aarsange til vi burger en KDF som tager tid og ikke blot SHA512 hvis jeg har adgang il kryptered dat direkte dvs et offline attack sa er min hastighed udelukkende nestemt hvor hurtigt kan kan a: afprove en noelge B: genere en noelge fra password Ved er er min genennmsits afbrydning tid 2^255 Ved at password paa f.eks 12 bogstaver tore/sma/tal tager "kun" ~2^71 forsoege derved kal der bruges X tid per gang det boer vare nemt at se at 2^255 * x > 2^71 *x med fler milliarer af milliarder i stoerrelse orden Det er derfor vir burger en KDF som tager Y tid for at goerd det svare at afprove password i brute forcing nu er det 2^255 * x md 2^71 * (x+y) Hvis Y er god nok saa er det ikke laengere hurtiger at bruteforce password over keys jeg haaber et kan forklare vigtighed i n god KDF SHA512 er IKKE en god KDF. det er ikke beregent il det. SHA%12 er beregent il at verificario vor af hastighed en fordel. ved KDF er hastighed en bagdel. praecist som jeg skrev foer so opsummerings - Du burger ordet Cipherkey fortket om noget der ikke er din cipherkey - Din SHA512 key generation er ikke den sikkerhed du tror den er. Jeg havde ret i begge tilfaelde selv naar man lease dit eget "bevis"
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury

#21 OK jeg traekker den tilbage der. Og giver dig helt ret. Det er satme noget svineri for microsoft at force bitlocker ned over deres bruger paa den maade.
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury

#22 Du rammer faktiskt nogle gode punkter men der er lidt mere til historien i OP tilfaelde er hen der et problme med dat confidelity hvis nogen stjaeler hele laptopppen da der er mulighed for at hive key ud af TPM. bitlocket bskytte imod nogen stajeler HDD'en men ikke helt saa godt hvis de stjaeler hele laptoppen. Anox metode som udelukkende har password/saa er det ikke forskel paa om HDD elelr hele laptop bruge brugt. Secret et helt vaek fra laptop. I dette pespektiv er Anox loesning en bet bedre mht til sikkerhed. Hvis noge stjaeler hans kdoeord ved at kigge over skuldrende eller lignen saa er TPM liesning bedre de shoulder surfign ikke virker her (key er i TPM) saa der er nogle forskellige perpsective/angrebs vinkler som er lidt forskellige her men i OP's bruger tilfaelde er det heller ikke noget der stopep dem fra ta tage ders hdd over i en ny maskine og bruge recovery key... sa hvidt jeg husker ( der maa folk rette mig hvis jeg tager fejl) saa problemmet her mht til sikkerhed er det samme og ikke en fordel for bitlocker mht til sikkerhed\ #29 Enig her paa alle punkter Det er ligemget hvor langt dit password er. an 5 dollars gummi slange og et bil batteri skal nok faa det ud af dig
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury
--

Sidst redigeret 04-07-2024 19:18

@anox Give mige lige et stykke tid her. jeg er ved at prove at lave en flowchart til bedre at vise hvad jeg mener omkring ciphey ikek er 512bits. jeg tror det kan vise hvad jeg forklare lidt bedre end et have af ord
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury

#34, jeg mener ikke jeg blander noget sammen. Det er direkte copypast fra den krypterings header jeg bruger: Cipher: aes-xts-plain64 Cipher key: 512 bits Som jeg citerede, bruger XTS 512 bit key. Den deler key'en i 2x 256bit, som den bruger til at kryptere. På den måde skulle det give en ekstra sikkerhed mod krypterings analyse. Igen, når det kommer til det matematiske, er det uden for min rækkevidde. Mit password bliver genereret således (password: helloworld): mkpasswd -m sha-512 -S "husksalt" helloworld $6$husksalt$1sMbl/a.HQHGFZtetCDaGdhDlcG6Q2i1hSad9rpHObB5qxFWi/JXXq5fnou9s5stH9jL0.DLskwqKb5tehIca. Det er en 512 bit streng + lidt mere, som er tilsvarende den key size: "Cipher key: 512 bits". Krypterings algoritmen køre den igennem adskille iteration. Jeg har eksempelvis valgt 5000 millisekunder som er relativt højt, jeg er også lidt paranoid når det kommer til kryptering ;) Passworded bliver typisk kun brugt som ekstra indgang til mine data, da jeg gerne bruger en genereret nøgle-fil. dd if=/dev/random of=/root/key.file bs=1 count=4096 4k er overkill, men igen, better safe than sorry :)
--

Sidst redigeret 04-07-2024 19:46

#35, jeg er lidt usikker på om du i det hele taget har læst min header i #19? Der står direkte: PBKDF: argon2i Mit password er genereret via saltet SHA512, som gives videre til krypteringsalgoritmen. Jeg tænker det er der misforståelsen ligger? :) Digests: 0: pbkdf2 Hash: sha512 Iterations: 190235 Salt: bd 6c 67 ae 24 ff 9f 93 ea 10 4f 32 64 80 f9 d7 fa 8e d9 e1 6c b7 62 6a da 5d d1 93 9b 5f e8 8a Digest: 25 53 8e c5 31 f7 0e ad 0b e9 ab ef 6a df 48 25 a4 0f 34 29 cc d4 08 7a b0 5d 66 a4 88 70 52 0f 25 53 f8 13 a0 59 29 99 59 db 39 dc f6 b8 dc 0d 9f 19 be 91 8a fd 15 bf f2 2d 15 63 c9 37 15 70 Som du kan se er det pænt mange iterations :)
--

Sidst redigeret 04-07-2024 19:55

@Sven Bent: AES er per standard rigtigt nok begrænset til 256bit nøgler, men diskkryptering med AES-XTS bruger 256bit nøgler til 128bit kryptering og 512bit nøgler til 256bit kryptering: https://en.wikipedia.org[...]
--
http://xlinx.dk[...] i7 2600K, 16GB PC3-12800, GA-Z68XP-UD4 R1, GTX 560Ti HAWK, 250GB 840 EVO

#9 ok jeg laeste lige din header igen. Her er vores problematik saa. Enhver documentation jeg har least om det er fra DOD eller NIST og andre 3-4 bogstaver organisation saa er cipher keyt den del er gaar ind til AES. De andre 256bits er ikke anset som cipher key Billed https://i.postimg.cc[...] Jeg tro vi er enige om hvad der sket rent bitmaessigt men om hvor termen cipher key bruges er hvor vi er uenig. jeg vil paasta at DM-crypt bruger termen forkert. Punkt 2 mht til sha512 saa er den IKKE sikker en god implementation ville see saaledes ud https://postimg.cc[...] Hvor Argon2 eller PKDF er sat til at tage omkring 1s tid Det sjove er at du faktisk har skrevet det selve men ikke er klar over det. kig paa din header info igen PBKDF: argon2i Det er ARGON2I der giver dig sikkerhed paa dit password til key IKKE sha512 som du paastaar din implementation er fin. du kigger blot paa de forkerter termer Argon 2 er utallige mange gange mere vaerd som key generator end sha512 er. SHa512 kan nemt paralleliseres over flere xPU'er dvs GPU kan nemt bruges i massevis til at skabe hurtige SHA512 brydninger Argon2 bruger en "masse" ram og er ram storrelse afhaengig. dvs det er ikke nok bare et smide FPU med tusindsvis af begregning enheder after jobbet nu skal du ogsaa have ram nok og opgaven kan slet ikke parallelizes paa samme maade Saa du har hele tiden gjort som jeg har sagt tingene boer goere. du blot kigge paa og brugte de forkerte terme mht til sikkerhed af din noegle Mere noerderi Du bruger Argon2I hvilket jeg normalt ikke ser anbefale til kold data som netop din HDD er Argon2I bruges typisk hvis du er bekymret om side channel attack Argon2D er mere robust imod brute forcing da den gennemgår ram i et password afstemt moenstre. dvs du er noed til at have alt den ram. Argon2ID kore foerste iteration i argon2I for at faa side channel attacks beskyttelse og resten i Argon2D for at faa beskyttelsen imode massive sma PU'er som f.esk en GPU farm Bare lidt oplysning Opsummering Vi bliver nok enige om hvor CipherKEy begrebet er. Mine documentation siger andeledes en hvad din DM crypt header goer Jeg havde ret i at SHA512 alene er ikke god nok til at genre key. ny opdagelse viser at det er heller ikke hvad du goer paa trods af din paastande. Argon2i er involveret mellem password indtastning og final AES key Ny ting. Denne key boer du heller ikke bruge til data kryptering. men det er ikke sammeget sikkerheds grundlang men bare god data hygiene. typisk genre du en "session key" ( bruge ordet forkert her)/personlig key som tager sig af din Master krypterings key). men det er en anden snak
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury
--

Sidst redigeret 04-07-2024 20:09

#41 Jeg har heet tiden sagt XTS bruger dobblet saa mange bit som noegle Det er ordet CIPHER KEY jeg bide i. Cipherkey I alt min dokument de 256 bits der gaar til AES funktioner og IKKE de 256bits der gaar til XTS IV see mit billed ovenfoor. jeg har ikke benaegte der er en 512bit noegle til stedet. blot at navnet Cipherkey ikke daekker over den noegle.
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury

#43 Det er IMO flueknepperi.. AES-XTS algoritmen kræver en 256/512bit nøgle, hvor meget af den der reelt går til block-transformering, og hvor meget der går til input vektor, er IMO underordnet da begge dele er nødvendige for at XTS cipher fungerer.
--
http://xlinx.dk[...] i7 2600K, 16GB PC3-12800, GA-Z68XP-UD4 R1, GTX 560Ti HAWK, 250GB 840 EVO
--

Sidst redigeret 04-07-2024 20:24

Vil du logge på din netbank alene med password? Jeg synes det er underligt at tale om, at dekryptere en hdd alene med et password, når den offentlige diskussion omkring sikkerhed går mod Flerfaktorautentifikation (MFA) og man taler netop om MFA i en erkendelse af, at passwords i sig selv ikke er nok. Man taler om passwords, der skal være mindst 15 karakter lange eller passphrases, der skal være min. 20 karakter og bestå af min. 5 ord. Kilde: https://www.cfcs.dk[...] I den verden skal MS lave et system, der sikrer brugernes data. Undskyld, men så synes jeg da, de har fundet en ret god balance. Kan kan få sikret sine data, man skal ikke huske/gemme/genbruge et password/phrase og man kan genskabe sine data med en recovery-key, man selvfølgelig skal gemme - her er der tydeligvis et kompromis på spil. Men alligevel - jeg har svært ved at se problemet med bitlocker. Problemet - for mig at se - er at brugeren ikke har været bekendt med hvordan man generere en recovery-key eller at bitlocker var aktiveret eller konsekvenserne af dette. Det kan være, butikkerne, der sælger pc´erne skulle informere deres kunder bedre? Det kunne være interessant at vide, hvor mange sælgere i elgiganten, Power, Proshop og deslige, der faktisk siger til deres kunder: Hør, du har købt denne windows-pc. Du skal liiige være opmærksom på at generere en recovery-key fordi...o.s.v. Microsoft har bestemt også en oplysningsopgave her. Funktionaliteten til at genere en recovery-key er tilstede. Den skulle bare have været brugt.
--

Sidst redigeret 04-07-2024 20:24

#42, SHA512 er en simpel hash algoritme der giver dig en unik værdi på baggrund af det du smider efter den. At generere et password den vej, kan ikke være mere sikkert. I dag kan du ikke bruteforce en streng på så mange tegn som her: $6$husksalt$1sMbl/a.HQHGFZtetCDaGdhDlcG6Q2i1hSad9rpHObB5qxFWi/JXXq5fnou9s5stH9jL0.DLskwqKb5tehIca. Om det er Cryptsetup eller Bitlocker jeg giver overstående password streng går ud på et. Du vil aldrig kunne bryde krypteringen. #45, vi bliver ikke enige og det er også ok. Det er derfor nogle bruger Cryptsetup, mens andre bruger Bitlocker.
--

Sidst redigeret 04-07-2024 20:30

#46 Der er to fejl i det du skriver: 1) "ikke" og 2) "aldrig". ;-)
--
http://xlinx.dk[...] i7 2600K, 16GB PC3-12800, GA-Z68XP-UD4 R1, GTX 560Ti HAWK, 250GB 840 EVO

#47, det må du uddybe :)
--

#46 jeg kan see du bare har valgt at gentage dig selv og ikke laese en op paa nogle af de ting der er lagt frem. hvis du ikke vil lare ting hodle du dig blot slev i den forketer opfattelse SHA512 er IKKE god til genering af en krypterigns key. lige meget hvor mange gange du paastar det uden nogen forklaring Du kan brute force alting med nok tid. igen du sige ting som bare ikke er sandt #43 det er muligt det er flue knepperi m,en det er nu det debatten gik paa mellme mig og anox OK jeg proeve at forklare XTS og de extra 256 bits en smule Hvis du bare bruger AES pa en data block igennem din disk saa vil de samme data see ens ud efter dekryptering. det gaelderr for storset alle BLock basere krypterings metoder Dvs selv om vi ikke har noeglen kan vi see et moenster I de krypterede data. ved ved fra dengnag vi broed simple substitution ciphermed papir og blyent i folkeskolen at data moenstre er en svaghed til at bryde kodet information. Hvis vi sammenligner en block data med et bogstave saa kan vi jo se det nemt hvordna det virker ved at bryde denne krypteret text https://jumpshare.com[...] De boer ikke tage lang tid me papir og blyant Saa for at undgaa den slags sstatistik analyse kan hjaelpe paa at bryde krypteringen saa har vi udviklet forskellige maadet at handter disse data blocke paa saa de bliver unikke. XTS er temmelig ny og en del komplex saa min forklaringe vil mangle noget. XTS er en overbygning paa XEX og min forklarinv vil vare mer ebbasret pa XEX da den er simplier og forskellen ikke har betydning for argumentationen Foer foeste block af data skal krypterer skal vi forst have lave en Initialization vector det skylde vi ikke har data fra en tidliger block IV bliver generet ved at tage de 256 extra bit (Fra sha 512) og krypter det med aes 256 dvs AES256( 256ovenstande bits) = IV1 Forste block af data bliver saa XOR med denne IV1 derefter bliver det Xored DAta krypteret med AES med dens 256 key Derefter bliver det krypteret data sp XOR'et igen med IV1 Nu har du saa Cipher Text der bliver skreve til mediet Naeste Block De tager vi saa den tidliger IV XOR den med den block2's Counter/ID det giver og saa IV2 Clear text bliver XOR'et med IV2 XORet text bliver saa Krypteret med AES og desn 256 key Krypteret data bliver saa XOR'et med IV2 Nu har vi Cipher Text som bliver skrevet til mediet Block 3 Vi tage igen tidliger IV2 og XOR den med ny counter/ID for at faa IV3 Clear text bliver XOR'et med IV3 XORet text bliver saa Krypteret med AES og desn 256 key Krypteret data bliver saa XOR'et med IV3 Nu har vi Cipher Text som bliver skrevet til mediet ogsaa vider og saa videre Bemark at de eneste 256bits som bliver brugt over alle blocke er AES 256 Key'en De extra 256bit der blev generet fra SHA512 blev kun brugt ved at skabe IV1 og derefter ikke brugt mere med andre ord det er KUN de 256 bits der gar ind i din krypterings cipher for dine data. Derfor din CipherKey er kun 256bit. Din blockmode key er 512 Din IV key er 256
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury

#45 Jeg blive noed til at sla lidt haard ind her. du taler om nogel ting du ikke helt forstaar og blander forskellige ting sammenog netop MFA oh HDD kryptering ser jeg den samem misforstaaele komme igen og igen mht til 2 factor krypterings Lad mig sige det kort. ved en HDD kryptering beskyttes du imod offline attacks. MFA kan ikke laves ved offline attacks. Det er saa simpelt. Der er UTROLIGT stor forskelle paa offline attacks of online attacks MFA er noget der bliver brugt mht til Online Attacks hvis du er interest i detaljer giver jeg det gerne. men jeg kan sem med Anox har det vare lidt spild af tid at forklare hvorfor SHA512 ikke er nok til at genere en krypterings noegel fra password
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury

#48 Det blev forklaret i et af mien tidligere indlaege hvor jeg gik over hvad formalet med en KDF er. Du kan brute force alle ting med nok tid. SHa512 tage mget kort tid saa det tager kor tid at prove all password igennem sha512 Det tage lang tid er gaa igennem argon2I ssaa det tager lang tid er gaa all password igennem argon2 Det er saa nemt. spoergmaal er TID. Det er blevet forklaret 4 gange nu kig evet her https://stackoverflow.com[...]
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury
--

Sidst redigeret 04-07-2024 20:57

#49, jeg tror ikke du forstår hvad jeg skriver og derfor køre du i cirkler. SHA512 bliver kun brugt til at generere det password, algoritmen sender igennem tusindvis af iterations. Du kan godt bruteforce, men det vil tage længere tid end jorden har eksisteret :)
--

#52 "generere det password, " nej SHA512 genere en KEY ikke et password. Det er dig som ikke forstaar forskelle mellem en key og password og igen du bruge ARGON2 ti lat genere dint krypterings noegle ikke sha512. det har du selv skrevet I dit eget indlaeg. men du forstaar for lidt til at vide du skrev det Det er Key = SHA512(password) Det er ikke som du skriver Password = SHA512(key)
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury
--

Sidst redigeret 04-07-2024 21:01

#53, jeg bruger en hash algoritme til at generere en string, som bruges som password. Hvis du ikke forstår dét, må jeg give fortabt.
--

#50 Jeg skriver at man idag taler om MFA fordi passwords ikke længere er nok. Der forskelle mellem en krypteret hdd og f.eks. en netbank, men svagheden ved passwords er den samme.
--

#54 hvis du ikke forstaar at dit password et det som du taster ind og en key bliver afledt af dit password maa jeg give fortabet. Dit password er ny engang det input du giver din SHA512 algoritme Det enes du har formaet med din sha512 er evt at lave et extra "KDF" agtig lag hvor SHA512 bruges. Hvis det er tilfaeldet er det endnu et ekemspel paa at gore noget udfra en misforstaaelse Hvis jeg skal brute force password sdaa brute force jeg hvad du bruger som input fra dine haender. Alt der efter er set som et key attack. Forskellelen ligge i ressource omkostninget et bruteforce angreb og hvilket accelration metoder der kan tages i brug. Igen du blandet termer og funktioner sammen
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury
--

Sidst redigeret 04-07-2024 21:20

#55, Både og. Når du er online opstår der helt nye angrebsvektor. Password har altid været en udfordring. Du kan sagtens have et ubrydeligt langt password der ikke kan bruteforces. Men fordi en webside du har brugt er komprimeteret og har ringe sikkerhed, figurere dit password nu i clear tekst i en wordlist. Bruger du samme password andre steder er du sårbar. MFA kan klart afhjælpe. Men at skulle bruge 2 authentification metoder til disk kryptering er nok i overkanten imo :)
--

#56, super, så stopper vi her. Jeg kan ikke forklare dig det på andre måder :)
--

#55 Password er nok for kryptering fordi der typsik er tale om offline attacks Jeg proevet at forklre her med nogle eksempler her og forklare hvorofr MFA ikke virker med FDE. Ved login a bank er der 2 dele det er et problem med password. ligemeget hvor lange og sikre de er 1: Det er det samme hvergang 2: de bliver brugt mange stedet 1: Er saarbar overfor hvad vi kaldet et replay attack. dvs hvis der er nogen der lytter med paa linien saa kan de tage dit password og bruge det igen senere til at logge ind med MFA er der en extra ting til stedet der an agriber skal have ejerskab over ud over at kunne lytte med paa linine. paa linine vil han blot se et unikt engangs kodeor sammen med det normale kodeord . og naar han prove at logge ind igen saa virker det ikke. 2: Er saarbar over for leaks. Dette her er nok en af det meste brugte angrebs metode i dag og noget jeg sider med ret tit. En sever har daarlig sikkehed og en bruges password leakes,. angriber bruger ny brugersn fleaked password alle mulige stedet og faa adgang. igen med MFA er det ikke muligt blot at vide det normale password MFA funktioner skal aver unde angribes kontrol lige saa Hvis du ligger marke til ngoet her veil de se der er begge gange tale om adggns kontrol gevet af 3. part dvs hverken bruger eller angriber. Det er den 3' part some kontrollere din MFA er ok Vdd diskkrypterings er der ikke nogen 3.part. Hvis jeg stjaler anox Computer og hiver hans disk ud og smide den i saa er der ikke noget system der sige "det har maa du ikke" der er ikke nogen til at verificer min MFa. Jeg har fri adgangs til AnoX kryptered data og intet star imellme mig og dem. Det er hvad vi kaldet et offline attacks eftersom jeg har fuld kontrol ove disse data skal jeg blot bryde en af to ting 1: hans password 2: hans krypterings noegle Hvis vi antager Anox kun bruger en hurtige SHA512 saa tager det ikke lang tid at koer eet par millioner password igenm SHA515 og afprove detm( det er det som anox ikke forstaar) Meget loese tal her SHa512 kan afvikles paa en skylake 3.5GHZ cpu med omkring 394MiB/s Hvis vi antager at Anoc original Password was 16 bogstaver/tal sa kan vi alsaa afprove okmring omkrin knap 26Million password i sekunded. ikke ligefrem lansghomt og det er med en cpu fra 2015... nye cpy meed flere kerner og GPU acceleration og bum vi afprove milliarder af password i sekundet. Herunde kan vi tillage dictionary attacks. dvs vi afproever ord osv som typisk bliver brugt at mennesker or vaere nemmer at huske og evet en top 10milloomer mest brugte password. (tage under et halt sekundt) saa har vi adgang Vi kan ogsaa tage hans krypterings noegel direkte. men der er MANGE flre combination der skal tages i rug AES256 kraver i gennemsntis vi fprover 2^255 noegle for at finde den ritige vilket er meget mere 16 characters. Det er saa her vi burger en KDF. (anox burger Argon2i han har bare ikke forstaeet et endnu) Lad as antage at Anox har sat sin ARGON2I til 1 sec for den same skylake CPU si vil vi kunne afprove.... 1 password i sekunder, altsaa ca 26 millioner gange langsommer end lot SHA512. Som sagt det er derfor vi ikke bruge 512 til krypterinsg nogle alene. vi bruge den typisk som en key stretch funtkion (hvilekt er hvad Anox ogsaa oer han ved det bare ikke) jeg ved det blev lidt langt men kryptering er noget komplicret omraade vis man skal gore det ordenligt kort fortalt" man kan ikke rigtie bruge MFA ved harddisk krypterings da der ved de typsike offlien attacks ikke er nogen 3.part til stedet til at haandter MFA/naegte dig adgan. Kryptering bruge nar du HAR bypassed adgangs ontrol hvor din MFA hoere hjemme MFA er dejligt men kan bare ikke rgitige bruges til FDE
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury

#57 Enig. Men folk bruger bare ikke vildt lange, komplicerede passwords, der ikke kan (svær) bruteforce crackes. Folk bruger: https://www.geeksforgeeks.org[...] Dertil kommer at password´et skal indtastes på installationstidspunktet (eller deromkring), så hvor mange kan huske det komplicerede password - måske - flere år senere? Det er jo ikke et password, man kommer til at bruge ret mange gange. Bevares - man kan skrive det ned, bruge password-managers m.v., men gør gennemsnitsbrugeren det? De kan jo tilsyneladende ikke lave en recovery-key og gemme den :)
--

#60 laes mig indlaeg Det forklare hvoror du ikke kan bruge MFA paa FDE
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury

#61 Jeg mener ikke man skal bruge MFA på FDE. Jeg beskriver blot at brugen af MFA illustrere at et enkelt password ikke er nok længere og det skyldes bl.a. de iboende svagheder ved passwords, som altid har eksisteret. Beklager hvis jeg ikke har været tydelig nok. Tilføjelse: Man kan vel egentlig sige, at det er lykkedes MS at implementere et lag af sikkerhed, der er så transparent for brugeren, at det næsten er for meget af det gode: De glemmer at lave en recovery-key. Case in point.
--

Sidst redigeret 04-07-2024 22:26

#48 anox: "kan ikke være mere sikkert", "kan du ikke bruteforce en streng på så mange tegn", "Du vil aldrig kunne bryde krypteringen". 1) Det kan altid være mere sikkert. 2) Hvorvidt du kan brute-force en streng af den længde, afhænger af hvilke data den er skabt af. Hasher du "abc" til en 64 byte streng, så skal du maksimalt gennemløbe 256^3 (16,7~ mio) værdier for at knække koden, og dette kan en gennemsnitscomputer klare indefor relativt kort tid. 3) Der findes ikke kryptering, der ikke kan brydes. Det er muligt, at det kan tage lang tid, men "aldrig" er forkert. Stakkels fluer..
--
http://xlinx.dk[...] i7 2600K, 16GB PC3-12800, GA-Z68XP-UD4 R1, GTX 560Ti HAWK, 250GB 840 EVO

#63, 1) du kan naturligvis altid være mere paranoid og ligge flere sikkerhedslagt på. Min pointe er, at mit password ikke kan være mere sikkert efter de krypteringsstandarder vi har i dag. 512 bit password til en 512 bit krypterings key. 2) du kender ikke mit password og hvordan det er skabt som udgangspunkt. Ligeledes tager du ikke højde for SALT. Men vil da tilkendegivet at hvis du har tilegnet dig alle de informationer, kan du målrette dit angreb på selve passwordet. Du skal blot huske på selve krypteringen har en stopklods for hvor mange forespørgelser du kan fyre af sted, netop for at forhindre bruteforce. Så selv hvis du kan generere mange SHA512, kan du ikke afprøve dem i samme tempo. 3 karakter = 3 x 8 bit = 24 bit. 2^24 = 16.7 million. Salt ligger mellem 8 og 16 karakter. (2^128) - (2^56) (fratrækker de første 7 karakter) = 3.4028237e+38. Det tal skal du gange med 2^24. ((2^128)-(2^56))*(2^24) = 5.7089908e+45 kombinationer. Selv med ringe password, kan du ikke bruteforce inden for en menneskealder. 3) Kryptering beror sig på regnekraft og at vi ikke har nok af den i dag. Der eksistere ikke nogen teknologi, der vil kunne bruteforce AES256 inden for en menneskealder. Det er hele pointen :)
--

Sidst redigeret 05-07-2024 13:35